Auditoria de Software

Es un término general que se refiere a la investigación y al proceso de entrevistas que determina cómo se adquiere, distribuye y usa el software en la organización.

Conducir la auditoría es una de las partes más críticas de un Programa de Administración de Software, porque la auditoría ayuda a la organización a tomar decisiones que optimicen sus activos de software.

Un estudio de Print UK Limited, firma de Administración de auditoría, descubrió que una organización típica con más de 500 PCs muchas veces tiene un 20% más de computadoras de lo que cree. El Gartner Group también descubrió que más de un 90% de las organizaciones han incrementado su base de activos de TI sin haber hecho ningún proceso para su seguimiento.

Una de las razones por las que las organizaciones no maximizan su inversión en activos de software es que no hay información exacta disponible. La recopilación de toda la información necesaria es un proceso intenso, especialmente cuando se hace por primera vez.

Otro problema es que la perspectiva de una auditoría

puede ser vista con algunas reservas por algunos directivos de la organización, preocupados porque pueda interrumpir el flujo de trabajo, y por algunos usuarios finales que pueden ser forzados a abandonar sus programas o procedimientos favoritos.

Una de las formas de evitar las objeciones y dejar de lado

estos problemas es planificar cuidadosamente la Auditoría de Software y comunicar su valor por adelantado.

Los siguientes factores favorecerán la colaboración entre la gerencia y el personal a través del proceso de planificación, el cual es una llave para el éxito de cualquier auditoría de software.

Establecer y acordar una serie clara de objetivos y comunicarla a todos los empleados asociados con la auditoría.

Focalizarse en los resultados que se requieran de la auditoría y discutir las áreas donde se crea pueda haber problemas.

Identificar las áreas simples pero muchas veces olvidadas que necesitan ser consideradas, tales como: Acceso a sitios y creación de mapas de esas locaciones Conocer con anticipación los log-on scripts de seguridad o

claves. Horario de la auditoría (durante el día, noche o fin de

semana).

Diseñar el plan y el cronograma de la auditoría, así como también las herramientas de auditoría que serán usadas.

Asignar recursos para cada elemento específico de la auditoría.

Este capítulo se focaliza en la selección de recursos necesarios para conducir la auditoría.

Auditoria de Hardware

A medida que una empresa incrementa su grado de informatización aumenta progresivamente el tratamiento de la información. Así, muchas de las actividades empresariales dependen de la exactitud y seguridad de la información con que se opera.

Cualquier distorsión cobra cada vez mayor vigencia la máxima que dice que la información de una empresa es parte importante de su activo y, en consecuencia, toma relevante importancia el garantizar su calidad e integridad.

A tal fin, la auditoria del entorno hardware vendrá a verificar la seguridad no solamente en la operativa de los componentes materiales del ordenador, sino de todo lo relativo a los aspectos físicos concernientes al departamento de procesos de datos. En este capitulo se pretende un acercamiento a la auditoria del entorno operativo hardware: sus objetivos, formas de actuación, puntos a revisar, recomendaciones a tener en cuenta, entre otros.

Se incluyen también unas páginas dedicadas a los planes

de contingencia y desastre. Concluye el capitulo con un cuestionario-guía de auditoria. Y como hemos visto a lo largo de este curso de Administración de Centros de Computo, generalmente la Auditoria Informática en el área de Hardware utiliza alguno de las herramientas de software que para tal fin fueron creadas, y las cuales abundan.

Pruebas de Software

Las pruebas de software, son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las

diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iníciales del sistema.

Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva requiere de un proceso de investigación más que seguir un procedimiento al pie de la letra. Una definición de "testing" es: proceso de evaluación de un producto desde un punto de vista crítico, donde el "tester" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción. Por supuesto, nunca se debe testear el software en un entorno de producción

Es necesario testear los nuevos programas en un entorno de pruebas separado físicamente del de producción. Para crear un entorno de pruebas en una máquina independiente de la máquina de producción es necesario crear las mismas condiciones que en la máquina de producción. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc.). Esas utilidades reproducen automáticamente las bases de datos para simular un entorno de producción.

En general, los informáticos distinguen entre errores de programación (o "bugs") y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa de ordenador. Éste podría presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de cálculo.

Una práctica común es que el proceso de pruebas de un programa sea realizado por un grupo independiente de "testers" al finalizar su desarrollo y antes de sacarlo al mercado.

Una práctica que viene siendo muy popular es distribuir de forma gratuita una versión no final del producto para que sean los propios consumidores los que la prueben.

En ambos casos, a la versión del producto en pruebas y que es anterior a la versión final (o "master") se denomina beta, y a dicha fase de pruebas, beta testing.

Tipos de PruebasPruebas unitarias Pruebas funcionales Pruebas de Integración Pruebas de validación Pruebas de sistema Caja blanca (sistemas) Caja negra (sistemas) Pruebas de aceptación Pruebas de regresión Pruebas de carga Pruebas de prestaciones Pruebas de recorrido Pruebas de mutación Pruebas concurrentes

Prueba Unitaria En programación, una prueba unitaria es una forma de

probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión. La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.

Pruebas Funcionales Una prueba funcional es una prueba basada en la ejecución,

revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. La pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.

Pruebas de Integración

Pruebas integrales o pruebas de integración 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. Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

Pruebas de Validación

Las pruebas de validación en la ingeniería de software son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.

Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iníciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?

Caja blanca (sistemas)

En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas.

Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso de variables), comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas, máximas menos uno y más uno).

Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integración).

En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada).

Este concepto también es utilizado de manera análoga en la teoría general de sistemas.

Caja negra (sistemas)

En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

Pruebas de regresión

Se denominan Pruebas de regresión a cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Este tipo de cambio puede ser debido a prácticas no

adecuadas de control de versiones, falta de consideración acerca del ámbito o contexto de producción final y extensibilidad del error que fue corregido (fragilidad de la corrección), o simplemente una consecuencia del rediseño de la aplicación.

Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente después de los cambios subsiguientes que experimente el programa.

Existen herramientas de software que permiten detectar este tipo de errores de manera parcial o totalmente automatizada, la práctica habitual en programación extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del software.

Pruebas de carga y Rendimiento Tiene por principal objetivo probar el funcionamiento

del software bajo condiciones extremas. Estudia la especificación del software, las funciones que debe realizar, las entradas y las salidas analizando los Valores Límite (AVL). 

Dispositivos de Prueba de Software Los dispositivos de prueba y equipos de prueba en

el circuito si consideramos que los circuitos digitales se fabrican en una sola tarjeta de servicio impreso, las tendencias actuales en observabilidad indican el uso de cada una de las terminales de todos los Cis como puntos de prueba. Esto se consigue mediante el uso de un dispositivo especial de prueba (test fiyture), cuyas terminales de contacto (Pago-Pins) coinciden con los puntos de conexión de la tarjeta de circuito impreso que están en el lado de las pistas. Las terminales de contacto de dispositivo de prueba están formadas por un perno que tiene un resorte en su interior.

El dispositivo de prueba tiene una terminal de contacto para cada patita o terminal de los circuitos integrados. La tarjeta que se va a probar se coloca en el dispositivo (que parece una “cámara perforada” llena de pago-pins) y a su vez, las terminales de contacto del dispositivo de prueba se conectan a un equipo automático de prueba que puede monitorear el estado de cada terminal como lo indica un programa de prueba (test software).

Avanzando aun mas, los equipos de prueba en el circuito también realizan lo “ultimo” en control habilidad. Este método no solo monitorea las señales en el dispositivo de prueba, sino que también conecta cada terminal de contacto (del dispositivo de prueba) en un circuito de control de baja independencia que forma parte del equipo automático de prueba.

Bibliografía

Diseño digital: principios y prácticas Escrito por: John F. Wakerly

http://es.wikipedia.org/

Presentation Presentation realized by:realized by:

Jeyzon CabanerioJeyzon CabanerioJhoan CoelloJhoan Coello