4.

VERIFICACIN Y VALIDACIN

Una de las tareas ms importantes y difciles a las que se debe enfrentar un desarrollador de modelos de simulacin es la validacin y vericacin de los mismos. Se debe trabajar lo ms prximo posible a los usuarios nales durante el periodo de desarrollo y validacin para reducir (o eliminar, si es posible) el escepticismo de los mismos respecto a los resultados obtenibles mediante el proceso de modelado y simulacin

la vericacin enfoca el tema de la consistencia interna de un modelo, mientras que la validacin est relacionada con la correspondencia entre el modelo y la realidad. El termino validacin se aplica a aquellos procesos que buscan determinar si una simulacin es correcta o no respecto al sistema real. De forma ms sencilla, la validacin trata sobre la cuestin "Se est construyendo el sistema correcto?", mientras que la vericacin responde a "Se est construyendo correctamente el sistema?".

La vericacin comprueba que la implementacin del modelo de simulacin (programa) corresponde al modelo, mientras que la validacin comprueba que el modelo corresponde con la realidad.

La calibracin comprueba que los datos generados por la simulacin coinciden con los datos reales observados.

4.1. PRUEBAS. (OBJETIVO - JUSTIFICACIN)

Las pruebas son las investigaciones empricas y tcnicas cuyo objetivo es proporcionar informacin objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Son una actividad ms en el proceso de control de calidad.
Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier momento de dicho proceso de desarrollo.

OBJETIVOS

El objetivo de las pruebas es presentar informacin sobre la calidad del producto a las personas responsables de este. Teniendo esta afirmacin en mente, la informacin que puede ser requerida es de lo ms variada. Esto hace que el proceso de testing sea completamente dependiente del contextoen el que se desarrolla. A pesar de lo que muchos promueven, no existen las "mejores prcticas" como tal. Toda prctica puede ser ideal para una situacin pero completamente intil o incluso perjudicial en otra. Por esto, las actividades, tcnicas, documentacin, enfoques y dems elementos que condicionarn las pruebas a realizar, deben ser seleccionadas y utilizadas de la manera ms eficiente segn contexto del proyecto.

una prueba tambin tiene connotaciones de experimento en el significado cientfico, ya que en este campo, habitualmente se cambian los parmetros de las pruebas o ensayos que se estn experimentando para poder verificar los resultados y determinar diferentes resultados.

TIPOS DE PRUEBAS

La prueba del software es un elemento crtico para la garanta de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado.

es un proceso que se enfoca sobre la lgica interna del software y las funciones externas. La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene xito si descubre un error no detectado hasta entonces.
Existen 3 tipos de pruebas elementales para una buena justificacin, estas son:

1.-Pruebas de integracin
2.-Pruebas de validacin 3.-Pruebas de sistema

INTEGRACIN

Pruebas integrales o pruebas de integracin son aquellas que se realizan en el mbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. nicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Integracin Descendente Esta ataca directamente a la implementaron de los mdulos desde el programa principal hacia los mdulos inferiores de manera jerrquica. El modo de funcionamiento consiste en que el modulo de control principal maneje toda la informacin de las pruebas y las distribuya directamente a los mdulos que se encuentren inmediatamente subordinados, y a su ves estos van realizando el mismo procedimiento a sus mdulos dependientes. Hay que tener presente que las pruebas se tienen que realizar cada ves que se va incorporando un nuevo mdulo.

La estrategia descendente suena relativamente fcil, pero en la realidad pueden producirse algunos problemas logsticos que podran llegar a repercutir en los resultados de nuestras pruebas, esto se refiere a, que ocurrira si un mdulo de nivel jerrquico superior depende de clculos realizados en un mdulo de nivel inferior.

Integracin Ascendente

Las pruebas de integracin ascendente, como su nombre lo indica, consiste bsicamente en tratar el mdulo atmico (mdulo de nivel jerrquico mas bajo) hacia arriba. Dado que los mdulos son integrados de abajo hacia arriba, e procesamiento requerido de los mdulos subordinados siempre esta disponible y se elimina la necesidad de resguardo.

Una estrategia de integracin ascendente puede ser implementada mediante los siguientes pasos: Se combinan los mdulos de bajo nivel en grupos que realicen una funcin especifica del software. Se escribe un conductor (Programa de control de la prueba) para coordinar la 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.

integracin regresiva ocurre cuando la compaa aumenta su control con respecto a sus competidores. por ejemplo, cuando los hospitales o centros mdicos negocian arreglos de consorcio con mdicos especialistas para que cada medico brinde servicios en una especialidad determinada (ciruga plstica, ginecologa, pediatra, etc.), pero dentro del hospital o centro medico

VALIDACIN DE SOFTWARE

en la ingeniera de software son el proceso de revisin que verifica que el sistema de software producido cumple con las especificaciones y que logra su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que tambin utiliza tcnicas tales como evaluaciones, inspecciones y tutoriales. La validacin es el proceso de comprobar que lo que se ha especificado es lo que el usuario realmente quera. Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales

VALIDACIN ALFA
Es la primera versin del programa, la cual es enviada a los verificadores para probarla. Algunos equipos de desarrollo utilizan el trmino alfa informalmente para referirse a una fase donde un producto todava es inestable, aguarda todava a que se eliminen los errores o a la puesta en prctica completa de toda su funcionalidad, pero satisface la mayora de los requisitos.

CMO SE REALIZAN?
se llevan a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se hacen en un entorno controlado. Se realizan despus de que todos los procedimientos de prueba bsicos, como las pruebas unitarias y pruebas de integracin se han completado, y se produce despus de las pruebas del sistema.

Por lo general emplea a cualquiera de las pruebas de caja blanca o caja negra para probar el software. El sistema est probado para la funcionalidad de los empleados de la compaa solamente, y se trata de pruebas de navegacin, entrada y salida de los mecanismos del software, Esta no es la versin final de software y cierta funcionalidad puede ser aadido al software incluso despus de la prueba alfa.

QUE SE ANALIZA?
los desarrolladores de software y los programadores de estudiar cuidadosamente los datos facilitados por los clientes con el fin de encontrar los defectos y problemas. Dan sugerencias sobre cmo estos errores pueden ser rectificados. No slo esto, sino que tambin proporcionan nuevas y mejores ideas para mejorar la calidad del software.

VERIFICACIN BETA
Representa generalmente la primera versin completa del producto, que es posible que sea inestable pero til para que las demostraciones internas y las inspecciones previas seleccionen a clientes. Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelacin de las caractersticas del producto, indicando que no sern agregadas ms caractersticas a esta versin y que solamente se harn pequeas ediciones o se corregirn errores.

Muchos de esto programas beta, son de uso privado solo permitiendo a un nmero determinado de usuarios probarlo, y de esta manera mantener un control ms eficiente de la calidad y las opiniones de los usuarios que lo estn probando. Este tipo de programas casi siempre incluye instrucciones especficas para reportar estos bugs y recibir ayuda en caso de ser necesario.

Por otro lado, tenemos los betas pblicos, que son programas como los que se han comentado al principio, software dirigido a cualquier usuario con un ordenador para que lo prueben y analicen ellos mismos.

CMO SE REALIZAN?
se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador.

Las pruebas beta es la ltima fase de las fases de prueba y se hace utilizando tcnicas de caja negra. La prueba involucra a los usuarios y que compruebe la funcionalidad requerida. A veces la versin beta tambin es liberado en el mercado, y en base a las modificaciones que se hacen comentarios de los usuarios o si no hay cambios en el software se libera.

QUE SE ANALIZA?
se produce en pruebas de software en alta mar cuando los clientes utilizan el software o visita su sitio. Usan sus conocimientos informticos y su tiempo para detectar errores en el software y as poder informar de stos para que los desarrolladores los corrijan, o corregirlos ellos mismos.

SISTEMA

La prueba del sistema: se basa en otras tcnicas de pruebas, aunque la finalidad de cada prueba es distinta, sirven para verificar que se hayan integrado correctamente cada uno de los elementos del sistema.

Tipos de pruebas del sistema: Prueba de Recuperacin: es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperacin se lleve a cabo, ya sea automticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperacin.

TIPOS DE PRUEBAS DEL SISTEMA:

Prueba de Seguridad: intenta verificar la aplicacin de los mecanismos de proteccin incorporados en el sistema. Durante la prueba el encargado desempea el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema negando as el servicio a otras personas a dems de producir errores a propsito en el sistema o debe curiosear los datos pblicos intentando encontrar una clave de acceso al sistema. Prueba de Resistencia: esta diseada para enfrentar a los problemas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volmenes anormales.

Prueba de rendimiento

Disear pruebas especiales que generen 10 o mas interrupciones por segundo. Incrementar la frecuencia de datos de entrada en un orden de magnitud con el fin de comprobar como responden las funciones de entrada. Ejecutar casos de prueba que requieran al mximo de memoria o de espacio en disco. Disear casos de prueba que produzcan excesivas bsquedas de datos almacenados en el disco.

4.3. MANTENIMIENTO

El Servicio de mantenimiento de software: es una de las actividades en la Ingeniera de Software y es el proceso de mejorar y optimizar el software desplegado (revisin del programa), as como tambin remediar los defectos. el mantenimiento del software es: la modificacin de un producto software despus de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno. La fase de mantenimiento de software: involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la adicin de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software

4.4. CARACTERSTICAS DEL MANTENIMIENTO.

COSTOS Costes del mantenimiento de software Mltiples estudios sealan que el mantenimiento es la parte ms costosa del ciclo de vida del software. Estadsticamente est comprobado que el coste de mantenimiento de un producto software a lo largo de toda su vida til supone mas del doble que los costes de su desarrollo.

Costes del mantenimiento de software Existen empresas que se acercan a porcentajes del 95% de los recursos dedicados al mantenimiento, con lo cual se hace imposible el desarrollo de nuevos productos software. Esta situacin se conoce como Barrera de Mantenimiento. En general, el porcentaje de recursos necesarios para mantenimiento se incrementa a medida que se produce ms software.

CAUSAS DEL ALTO COSTE DEL MS

Una gran cantidad del software que existe actualmente ha sido desarrollado hace ms de 10 aos. Aunque estos programas fuesen creados utilizando las mejores tcnicas de diseo y codificacin existentes en su momento (la mayora no lo fueron), se construyeron con restricciones de tamao y espacio de almacenamiento y se desarrollaron con herramientas tecnolgicamente desfasadas. Estos programas han sufrido una o varias migraciones a nuevas plataformas o sistemas operativos. Y han experimentado mltiples modificaciones para mejorarlos y adaptarlos a las nuevas necesidades de los usuarios. Todos estos cambios se realizaron sin tener en cuenta la arquitectura general del sistema (no se aplicaron tcnicas de ingeniera inversa o reingeniera).

CAUSAS DEL ALTO COSTE DE MS

CAUSAS DEL ALTO COSTE DE MS

EL EFECTO ICEBERG: COSTES INTANGIBLES

Cuando se planifican los costes de mantenimiento, los analistas programadores experimentados tienen la impresin de que el MS es algo descontrolado y que nunca se sabe qu va a pasar (es algo as como predecir el futuro). Parece como si fuese un iceberg del cual slo se percibe una pequea parte, pero bajo cuya superficie se esconde una gran cantidad de problemas potenciales y de costes encubiertos. En la parte sumergida de este iceberg se ocultan otros costes, menos tangibles que los monetarios, pero que pueden ser causa de muchas preocupaciones. Un coste intangible del MS se encuentra en las oportunidades de desarrollo que se han de posponer o que se pierden, debido a que los recursos disponibles estn dedicados a las tareas de mantenimiento.

TIPOS DE MANTENIMIENTO
No Planificable (NP): Correctivo Urgente (UC): localizar y eliminar los posibles defectos que bloquean el programa o los procesos de funcionamiento de la empresa. Planificable (P): Correctivo No Urgente (NUC): localizar y eliminar los posibles defectos de los programas que no son bloqueantes.

Perfectivo (PER): aadir al software nuevas funcionalidades solicitadas por los usuarios.

Adaptativo (A): modificar el software para adaptarlo a cambios en el entorno de trabajo (hardware o software).
Preventivo (PRE): modificar el software para mejorar sus propiedades (calidad mantenibilidad, etc.).

MANTENIMIENTO CORRECTIVO
A pesar de las pruebas y verificaciones que aparecen en etapas anteriores del ciclo de vida del software, los programas pueden tener defectos. El mantenimiento correctivo tiene por objetivo: localizar y eliminar los posibles defectos de los programas. Un defecto en un sistema es una caracterstica del sistema con el potencial de causar un fallo. Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la especificacin.

MANTENIMIENTO ADAPTATIVO
Este tipo de mantenimiento consiste en la modificacin de un programa debido a cambios en el entorno (hardware o software) en el cual se ejecuta. Los cambios pueden afectar a: el sistema operativo (cambio a uno ms moderno). a arquitectura fsica del sistema informtico (paso de una arquitectura de red de rea local a Internet/Intranet). al entorno de desarrollo del software (incorporacin de nuevos elementos o herramientas como ODBC). Los cambios en el entorno software pueden ser de dos clases: En el entorno de los datos: por ejemplo, al dejar de trabajar con un sistema de ficheros clsico y sustituirlo por un sistema de gestin de bases de datos relacionales. En el entorno de los procesos: por ejemplo, migrando a una nueva plataforma de desarrollo con componentes distribuidos, Java, ActiveX, etc.

MANTENIMIENTO PERFECTIVO

Cambios en la especificacin, normalmente debidos a cambios en los requerimientos de un producto software, implican un nuevo tipo de mantenimiento llamado perfectivo. Desde algo tan simple como cambiar el formato de impresin de un informe, hasta la incorporacin de un nuevo mdulo funcional. Podemos definir el mantenimiento perfectivo: como el conjunto de actividades para mejorar o aadir nuevas funcionalidades requeridas por el usuario. Algunos autores dividen este tipo de mantenimiento en dos: Mantenimiento de Ampliacin: orientado a la incorporacin de nuevas funcionalidades. Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecucin

MANTENIMIENTO PREVENTIVO
Este ltimo tipo de mantenimiento consiste en la modificacin del software para mejorar las propiedades de dicho software (por ejemplo, aumentando su calidad y/o su mantenibilidad) sin alterar sus especificaciones funcionales. Algunas maneras de hacerlo son: incluir sentencias que comprueben la validez de los datos de entrada. reestructurar los programas para mejorar su legibilidad. incluir nuevos comentarios que faciliten la posterior comprensin del programa. En algunos casos se ha planteado el Mantenimiento para la Reutilizacin, consistente en modificar el software (buscando y modificando componentes para incluirlos en bibliotecas) para que sea mas fcilmente reutilizable.

TIPOS DE ACTIVIDADES

Basili et al. [1996] identifican las siguientes once actividades, que se realizan con cada modificacin del software:
Anlisis de impacto y de costes/beneficios: se dedica esta actividad a analizar diferentes alternativas de implementacin y/o a comprobar su impacto en la planificacin, coste y facilidad de operacin. Comprensin del cambio: puede consistir en localizar el error y determinar su causa, o en comprender los requisitos de una mejora solicitada. Diseo del cambio: se refiere al diseo propuesto para el cambio, pudindose incluir un rediseo del sistema. Codificacin y pruebas unitarias: se codifica y prueba el funcionamiento de cada componente modificado. Inspeccin, certificacin y consultora: esta actividad se dedica a inspeccionar el cambio, comprobar otros diseos, reuniones de inspeccin, etc.

Pruebas de integracin: se refiere a comprobar la integracin de los componentes modificados con el resto del sistema. Pruebas de aceptacin: en esta actividad, el usuario comprueba, junto al personal encargado del mantenimiento, la adecuacin del cambio a sus necesidades. Pruebas de regresin: en esta actividad se somete el software modificado a casos de pruebas previamente almacenados y por los que ya pas. Documentacin del sistema: se revisa y reescribe, en caso necesario, la documentacin del sistema para que se ajuste al producto software ya modificado. Otra documentacin (del usuario, por ejemplo): se revisa y reescribe, en caso necesario, los diferentes manuales de usuario y otra documentacin, excepto la documentacin del sistema. Otras actividades: como las dedicadas a la gestin del proyecto de mantenimiento.

DISTRIBUCIN DE LAS ACTIVIDADES DEL

MANTENIMIENTO

BIBLIOGRAFAS

http://jair.lab.fi.uva.es/~pablfue/leng_simulacion/material es/v_v_0405.pdf http://es.wikipedia.org/wiki/Pruebas_de_software http://es.wikipedia.org/wiki/Prueba_(ciencia)

http://es.wikipedia.org/wiki/Pruebas_de_integraci%C3% B3n http://html.rincondelvago.com/ingenieria-desoftware_4.html

http://es.wikipedia.org/wiki/Pruebas_de_validaci%C3%B 3n http://pruebasalfaybeta.blogspot.mx/