Modelo para Pruebas de Software y auditoría en Entorno Microsoft.Net (página 2)

4. Características.

Según Schoderbek y otros (1993) las características que los teóricos han atribuido a los sistemas son las siguientes:

Interrelación e interdependencia de objetos, atributos, acontecimientos y otros aspectos similares. Toda teoría de los sistemas debe tener en cuenta los elementos del sistema, la interrelación existente entre los mismos y la interdependencia de los componentes del sistema. Los elementos no relacionados e independientes no pueden constituir nunca un sistema.

• Totalidad. El enfoque de los sistemas no es un enfoque analítico, en el cual el todo se descompone en sus partes constituyentes para luego estudiar en forma aislada cada uno de los elementos descompuestos: se trata más bien de un tipo gestáltico de enfoque, que trata de encarar el todo con todas sus partes interrelacionadas e interdependientes en interacción.
• Búsqueda de objetivos. Todos los sistemas incluyen componentes que interactúan, y la interacción hace que se alcance alguna meta, un estado final o una posición de equilibrio.
• Insumos y productos. Todos los sistemas dependen de algunos insumos para generar las actividades que finalmente originaran el logro de una meta. Todos los sistemas originan algunos productos que otros sistemas necesitan.
• Transformación. Todos los sistemas son transformadores de entradas en salidas. Entre las entradas se pueden incluir informaciones, actividades, una fuente de energía, conferencias, lecturas, materias primas, etc. Lo que recibe el sistema es modificado por éste de tal modo que la forma de la salida difiere de la forma de entrada.
• Entropía. La entropía está relacionada con la tendencia natural de los objetos a caer en un estado de desorden. Todos los sistemas no vivos tienden hacia el desorden; si los deja aislados, perderán con el tiempo todo movimiento y degenerarán, convirtiéndose en una masa inerte.
• Regulación. Si los sistemas son conjuntos de componentes interrelacionados e interdependientes en interacción, los componentes interactuantes deben ser regulados (manejados) de alguna manera para que los objetivos (las metas) del sistema finalmente se realicen.
• Jerarquía. Generalmente todos los sistemas son complejos, integrados por subsistemas más pequeños. El término "jerarquía" implica la introducción de sistemas en otros sistemas.
• Diferenciación. En los sistemas complejos las unidades especializadas desempeñan funciones especializadas. Esta diferenciación de las funciones por componentes es una característica de todos los sistemas y permite al sistema focal adaptarse a su ambiente.
• Equifinalidad. Esta característica de los sistemas abiertos afirma que los resultados finales se pueden lograr con diferentes condiciones iniciales y de maneras diferentes. Contrasta con la relación de causa y efecto del sistema cerrado, que indica que sólo existe un camino óptimo para lograr un objetivo dado. Para las organizaciones complejas implica la existencia de una diversidad de entradas que se pueden utilizar y la posibilidad de transformar las mismas de diversas maneras.

Dadas estas características se puede imaginar con facilidad una empresa, un hospital, una universidad, como un sistema, y aplicar los principios mencionados a esa entidad. Por ejemplo las organizaciones, como es evidente, tienen muchos componentes que interactúan: producción, comercialización, contabilidad, investigación y desarrollo, todos los cuales dependen unos de otros.

Al tratar de comprender la organización se le debe encarar en su complejidad total, en lugar de considerarla simplemente a través de un componente o un área funcional. El estudio de un sistema de producción no produciría un análisis satisfactorio si se dejara de lado el sistema de comercialización.

5. Elementos.

a. Subsistema.

En la misma definición de sistemas se hace referencia, a los subsistemas que lo componen cuando se indica que el mismo esta formado por partes o cosas que forman el todo. Estos conjuntos o partes pueden ser a su vez, ya que conforman un todo en sí mismo y estos serian de un rango inferior al del sistema que componen. Estos subsistemas forman y componen un sistema de un rango mayor el cual para los primeros se denomina macrosistema.

b. Entradas.

Los ingresos del sistema que pueden ser recursos materiales, recursos humanos o información. Las entradas constituyen las fuerzas de arranque que suministra al sistema sus necesidades operativas.

Las entradas pueden ser: en serie, aleatoria y retracción.

c. Procesos.

Es lo que transforma una entrada en salida, como tal puede ser una maquina, un individuo, una computadora, un producto químico, una tarea realizada por un miembro de la organización.

d. Salidas.

Estos son los resultados que se obtiene de procesar las entradas. Al igual que las entradas estas pueden adoptar las formas de productos, servicios e información. Las salidas de un sistema se convierten en entradas de otro que las procesara para convertirla en otras salidas.

e. Caja Negra.

Se utiliza para representar a los sistemas cuando no sabemos que elementos o cosas componen al sistema o procesos, pero sabemos que a determinada corresponden a determinadas salidas y con ello poder inducir, presumiendo que a determinado estimulo las variables funcionaran en cierto sentido.

f. Retroalimentación.

Se produce cuando la salida del sistema o la influencia de las salidas del sistema en el contexto, vuelven a ingresar al sistema como recurso o información.

g. Relaciones.

Son los enlaces que vinculan entre si a los objetos o subsistemas que componen un sistema complejo.

h. Atributos.

Definen al sistema tal como lo conocemos u observamos. Los atributos pueden ser definidores o concomitantes: los atributos definidores son aquellos sin los cuales una entidad no seria designada o definida tal como se lo hace; los atributos concomitantes en cambio son aquellos que cuya presencia o ausencia no establece ninguna diferencia con respecto al uso de términos que describe la unidad.

i. Contexto.

Un sistema siempre estará relacionado con el contexto que lo rodea, o sea, el conjunto de objetos exteriores al sistema pero que influyen decididamente a este, y a su vez el sistema influye, aunque en menor proporción, influye sobre el contexto se trata de una relación mutua de contexto-sistema.

j. Variables.

Cada sistema y subsistema contiene un proceso interno que se desarrolla sobre la base de la acción, interacción y reacción de distintos elementos que deben necesariamente conocerse, suele denominarse como variable, a cada elemento que compone o existe dentro de los sistemas y subsistemas.

k. Permeabilidad.

La permeabilidad de un sistema mide la interacción que este recibe del medio, se dice que a mayor permeabilidad del sistema el mismo será mas o menos abierto.

l. Estabilidad.

Un sistema se dice estable cuando puede mantenerse en equilibrio a través del flujo continuo de materiales, energía e información.

m. Adaptabilidad.

Es la propiedad que tiene un sistema de aprender y modificar un proceso, un estado o una característica de acuerdo a las modificaciones que sufre el contexto. Esta se logra a través de un mecanismo de adaptación que permite responder a los cambios internos y externos a través del tiempo.

n. Mantenibilidad.

Es la propiedad que tiene un sistema de mantenerse constantemente en funcionamiento. Para ello utiliza un mecanismo de mantenimiento que asegura que los distintos subsistemas están balanceados y que el sistema total se mantiene en equilibrio con el medio.

6. Clasificaciones.

a. Sistema Cultural.

Es una serie de creencias y conductas consecuentes que se comportan en toda la organización, país, sociedad.

b. Sistema Administrativo.

Proceso mediante el cual la organización administra sus recursos humanos y materiales así como sus activos.

c. Sistema de Control.

Procedimiento que consta de varios pasos que se aplican a diversos tipos de actividades de control.

d. Sistema de Información.

Formas escritas y electrónicas de compartir la información, procedimiento de datos y comunicación de las ideas.

Un sistema de información puede definirse técnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución. Además, para apoyar la toma de decisiones la coordinación y el control, los sistemas de información pueden también ayudar a los administradores y al personal a analizar problemas, visualizar cuestiones complejas y crear nuevos productos.

Los sistemas de información pueden contener datos acerca de personas, lugares y cosas importantes dentro de la institución y el entorno que lo rodea.

Tres actividades de un sistema de información producen la información que la institución requiere para la toma de decisiones, para el control de las operaciones, el análisis de los problemas y la creación de nuevos productos y servicios. Estas actividades son las de insumo, procesamiento y producto. La alimentación o insumos capturan o recolecta datos dentro de la organización o del entorno que la rodea. El procesamiento transforma estos datos primos a algo que tenga más sentido. El producto o salida transfiere la información procesada a las personas o actividades donde deba ser empleado. Los sistemas de información también requieren de retroalimentación que es el producto regresado a personas indicadas dentro de la institución para ayudarles a evaluar o a corregir la etapa de alimentación.

Los sistemas formales descansan sobre definiciones aceptadas y fijas de los datos y de los procedimientos para recolectarlos, almacenarlos, procesarlos, distribuirlos y emplearlos. Los sistemas formales presentados en esta obra son estructurados; esto es, operan mediante reglas predeterminadas que permanecen relativamente fijas y que no se pueden cambiar fácilmente. Por ejemplo, el sistema de entregas de paqueterías de UPS requiere que todos los paquetes sean identificados con los nombres y las direcciones de expedidores u destinatarios.

Características de los Sistemas de Información.

• Evalúa la calidad e importancia relativa de los datos de entrada. La disposición de filtros hace que no se pueda pedir operaciones imposibles al ordenador. El establecimiento de jerarquías posibilita la racionalización de los recursos y el beneficio operativo.
• Procesa la información sin corromperla y trasformarla para que sea útil al usuario, existen casos en que los errores de redondeo, conducen muchas veces a resultados absurdos e inútiles.
• Almacena los datos de forma que estén accesibles cuando se requiera.
• Ofrece la información de acuerdo con las necesidades del usuario, distribuyéndola de la forma más conveniente.

1) Componentes de los sistemas de Información.

Los sistemas de información modernos dependen de la existencia de dos componentes, a saber: infraestructura de la información y herramientas tecnológicas. La infraestructura de la información tiene que ver con cuestiones de demanda y el componente de tecnología se aplica en el suministro de soluciones técnicas al despliegue de sistemas de información.

2) Infraestructura de Información.

Comprende la definición de las necesidades de información, datos y fuentes de información, captación de datos y la gestión de la función de información en las organizaciones. Las cuestiones relacionadas con la infraestructura de la información se relacionan con dos aspectos: especificación de sistemas y gestión de los sistemas de información.

La especificación de sistemas tiene que ver con la recopilación de datos especializados y de gestión, y con tareas relacionadas con la información que se agrupan con el objetivo de determinar los detalles de la demanda de información y las posibles soluciones para generar los datos de inteligencia que necesitan gerentes y proveedores. No obstante, es la gestión de la función de información la que plantea la mayor responsabilidad para las organizaciones. La gestión de los sistemas de información comprende la responsabilidad estratégica y de toda la organización en relación con los datos, los sistemas de información implantados, la gestión de tecnología y el personal de información.

Al planificar, diseñar, desarrollar, implantar y poner en funcionamiento sistemas de información se debe tratar con una amplia gama de cuestiones de infraestructura de la información y en cada caso se deben abordar en forma realista las siguientes áreas de gestión de la función de información:

• Objetivos y propósitos. Especificar los objetivos y los propósitos del sistema de información a los niveles organizacional, comunitaria, regional y nacional.
• Necesidades de información.
• Entorno organizacional. Comprender las cuestiones organizativas que tendrán que resolverse como consecuencia de la introducción de los sistemas de información, inclusive los cambios en la estructura gerencial y física que se necesitan para apoyar la operación eficaz de los sistemas de información.
• Cuestiones relacionadas con datos. Especificar y realizar el monitoreo de la recopilación, trascripción, procesamiento de datos, y las necesidades y procedimientos de análisis.
• Necesidades de procesamiento. Describir las necesidades y los procedimientos de notificación para generar y utilizar los datos procesados y la información para la gerencia en formatos que sean comprensibles para los usuarios.
• Indicadores. Definir, en términos prácticos, los indicadores más útiles de la eficacia y eficiencia de los programas y las operaciones y procedimientos para generar dichos indicadores e informar regularmente sobre los mismos.
• Cuestiones de recursos humanos. Determinar las necesidades de personal para manejar y utilizar los sistemas en términos de procedimientos, equipos y otros insumos.

El despliegue y la utilización de tecnologías de informática y telecomunicaciones en el campo de la salud deben considerar la variedad y las necesidades cambiantes del sector; la existencia, organización y funcionamiento eficiente de una infraestructura de información; el nivel y la calidad de la infraestructura de telecomunicaciones y las cuestiones relacionadas con la existencia de un entorno organizacional y de gestión adecuado y cuestiones relacionadas con la selección, el costo y la implementación de la tecnología apropiada.

3. Herramientas Tecnológicas.

Las herramientas tecnológicas proporcionan los medios para procesar datos y convertirlos en información, comunicar datos e información y apoyar la utilización de éstos. La tecnología de información tiene que ver con el desarrollo de respuestas técnicas practicables a la necesidad de contar con una operación eficaz y eficiente del sistema de información. Las posibles opciones tecnológicas siempre dependen de las estrategias y áreas de inquietud o aplicación especificadas por un estudio de necesidades realizado en forma apropiada por el usuario; por lo tanto, tiene que ver con el suministro de soluciones.

Existe una amplia gama de aplicaciones que permiten aprovechar los recursos de la tecnología. Comprenden la consideración de los niveles de conectividad deseados, la amplitud de banda de la comunicación y el campo de aplicación.

Los sistemas de información se desarrollan con diferentes propósitos, los cuales dependen de las necesidades de la empresa.

• Los sistemas de procesamiento de datos.
• Son todos aquellos sistemas de información computarizado que se desarrollan para procesar grandes volúmenes de información, generadas en las funciones administrativas, tales como las nominas o el control de inventario.
• Sistemas Informáticos para la Administración.
• No sustituyen a los sistemas que se sustentan a la relaciona que surge entre las personas y las computadoras, estos sistemas de información para la administración soportan un amplio aspecto de tareas de las organizaciones mas aun que los sistemas de procesamiento de datos, incluyendo el análisis de decisiones y la toma de decisiones. Los usuarios de estos sistemas utilizan una base de datos compartida para tener acceso a la información.
• Sistema de Apoyo para la Toma de decisiones.
• Es un tercer tipo de sistema de información computarizado, es similar a los sistemas de información tradicionales para la administración, en el sentido de que ambos dependen de una base de datos como fuente de información.
• Sistemas Expertos o Inteligencia Artificial.
• Puede considerarse a la inteligencia artificial como el campo principal de los sistemas expertos. La idea central de la inteligencia artificial es llegar a desarrollar maquinas que cuenten con diseños inteligentes.
• Los sistemas expertos son en si un tipo muy especial de sistemas de información, que tiene un uso práctico en los negocios debido a la reciente y amplia disponibilidad de Hardware y software, como las microcomputadoras y los ambientes de sistema experto. Un sistema experto captura y en efecto utiliza el conocimiento de un experto.

4) Ciclo de Vida de los Sistemas de Información.

Existen dos niveles en a construcción de sistemas de Información: aquellos relativos a pequeños programas (los que normalmente realizan programadores individuales) y aquellos que se refieren a sistemas de desarrollo de programas grandes (Proyectos de software) y que generalmente, requieren un equipo de programadores en lugar de personas individuales. El primer nivel es denominado Programación a Pequeña Escala; el segundo nivel se le denomina Programación a Gran Escala.

El desarrollo de un buen sistema de software se realiza durante el ciclo de vida que es el periodo de tiempo que se extiende desde la concepción inicial del sistema hasta su eventual retiro de uso del mismo. Las actividades humanas relacionadas con el ciclo de vida del software implican procesos tales como:

• Análisis de requerimientos
• Diseño
• Implementación
• Codificación
• Pruebas
• Verificación
• Documentación
• Mantenimiento

e. Sistema Económico.

Medio a través de los cuales una sociedad distribuye sus recursos para satisfacer las necesidades de sus integrantes.

f. Sistema de mandos múltiples.

En este sistema es en el que existen varios mandos dentro de la misma organización, se describe como desorganización necesaria, es aquella organización donde se busca dividir las responsabilidades y delegar funciones dentro de la empresa.

g. Sistema Gerencial.

Es el sistema de la gerencia que adopta cada organización empresarial esta dependerá del tipo de organización que la gerencia de la empresa desea desarrollar en la misma.

h. Sistema Técnico.

Es el sistema que esta compuesto por factores como la tecnología usada y la infraestructura material inclusive las consideraciones ergonómicas, programas de software para computadoras y configuraciones de hardware, así como las inversiones de capital necesarias para cumplir con la misión de la compañía.

i. Sistemas productivos.

Los sistemas productivos pueden definirse como los procedimientos para convertir insumos en bienes y servicios. Todos los procesos productivos reciben insumos humanos, financieros, tecnológicos e informáticos que pasan por un proceso de transformación o conversión.

D. AUDITORIA.

1. Generalidades.

La auditoria es una función independiente de la evaluación, que se establece dentro de la organización para examinar y evaluar sus actividades.

La auditoria busca apoyar a los miembros de la organización en el desempeño de sus responsabilidades para ello proporciona análisis, evaluaciones, recomendaciones, asesoría e información concerniente a las actividades revisadas.

Los departamentos de auditoria son responsables de proporcionar información acerca de la adecuación y efectividad del sistema de control interno de la organización y de la calidad de la gestión.

Con frecuencia la palabra auditoria se ha empleado incorrectamente y se le ha considerado como una evaluación cuyo único fin es detectar errores y señalar fallas, por eso se ha llegado a utilizar la frase "tiene auditoria", como sinónimo de que antes de realizarse, ya se encontraron fallas y por lo tanto ya se está haciendo la auditoria; el concepto de auditoria es mas amplio, no solo detecta errores: es un examen crítico que se realiza con objeto de evaluar la eficiencia y eficacia de una sección o de un organismo, y determinar cursos alternativos de acción para mejorar la organización y lograr los objetivos propuestos.

El auditor tiene la virtud de oír y revisar cuentas, pero debe estar encaminado a un objetivo específico, que es el de evaluar la eficiencia y eficacia con que están operando para que, por medio del señalamiento de cursos alternativos de acción, se tomen decisiones que permitan corregir los errores, en caso de que existan, o bien mejorar la forma de actuación.

La auditoria requiere el ejercicio de un juicio profesional, sólido y maduro, para juzgar los procedimientos que deben de seguirse y estimar los resultados obtenidos.

2. Definición.

• "La palabra auditoria viene del latín "auditorius" y de ésta proviene "auditor", el que tiene la virtud de oír; el diccionario lo define como revisor de cuentas colegiado".
• El boletín C de normas de del Instituto Mexicano de Contadores nos dice "La auditoria no es una actividad meramente mecánica que implique la aplicación de ciertos procedimientos cuyos resultados, una vez llevados a cabo, son de carácter indudable".
• "La auditoria en informática, es una función que ha sido desarrollada para asegurar la salvaguarda de los activos de los sistemas de computadoras, mantener la integridad de los datos y lograr los objetivos de la organización".

Por tanto, es la revisión y evaluación de los controles, sistemas y procedimientos de la informática, de los equipos de computo, su utilización, eficiencia y seguridad, de la organización que participa en el procesamiento de la información, a fin de que por medio del señalamiento de cursos alternativos se logre una utilización mas eficiente, confiable y segura de la información, que servirá para una adecuada toma de decisiones.

3. Antecedentes.

El origen de la función de auditoria, es sin lugar a dudas, británico. La contaduría como profesión fue introducida en este continente por los británicos en la segunda mita del siglo XIX.

En el Reino Unido, en aquel entonces, como ahora, las corporaciones públicas se constituían bajo una ley nacional conocida como la Ley de Empresas, a la cual debían someterse todas las empresas públicas.

La ausencia de requerimientos estatutarios para que los accionistas dispusieran de auditorias condujo en el siglo IXI a la existencia de una gran diversidad de auditorias que comprendían desde auditorias de balance general hasta los mas amplios y detallados análisis de todas las cuentas de una corporación. Los auditores generalmente eran contratados por la gerencia o por la junta directiva de una corporación y su informe estaba destinado a estos funcionarios más que a los accionistas. Hacia 1900 la revolución industrial tenía casi 50 años y las empresas industriales habían alcanzado un crecimiento notable. Había un mayor número de accionistas distantes, muchos de los cuales empezaron a recibir informes de auditores. La contaduría se desarrolló rápidamente en América después de la Primera Guerra Mundial, durante gran parte de este siglo los contadores públicos elaboraron sus informes siguiendo muy pocas orientaciones formales.

Las concepciones erróneas acerca de la función de los auditores independientes estaban tan extendidas que en 1917 el Tribunal Federal de Reserva publicó, en el Boletín Federal de Reserva, un documento preparado por el Instituto Americano de Contadores (que se convertirla en el Instituto Americano de Contadores Públicos en 1957) estableciendo una contaduría uniforme.

En la sociedad actual, es indispensable que muchos tipos de informaciones financieras sean sometidas a una auditoria. Los administradores, accionistas, instituciones de crédito, agencias reguladoras y ramas legislativa y ejecutiva de los gobiernos federal, y estatal y local requieren de esas auditorias.

Hace muchos años, la palabra "auditor" evocaba la imagen de un individuo usando una visera verde y sentada en un banquillo muy alto. Esa imagen ha dejado de tener vigencia. El auditor moderno debe ser individuo de talento, capaz de tomar decisiones vitales sobre muchos asuntos importantes, y poseer el coraje y la fortaleza de carácter suficientes para atenerse a sus convicciones personales.

La auditoria ha sido definida como unos procesos sistemáticos que consiste en obtener y evaluar objetivamente evidencia sobre las afirmaciones relativas a los actos y eventos de caracter económico; con el fin de determinar el grado de correspondencia entre esas afirmaciones y los criterios establecidos, para luego comunicar los resultados a las personas interesadas.

Mediante la auditoria se obtiene y se evalúa la evidencia para determinar si las afirmaciones de la organización están de acuerdo con los criterios que se han establecido.

La Auditoria de Sistemas se originó como una respuesta de la auditoria tradicional a los cambios de la forma en que las organizaciones realizaban el procesamiento de transacciones en sus computadoras. Los sistemas desarrollados en forma inicial, muy simples en cuanto a si concepción y funcionamiento, no representaban un reto significativo para su auditor, las aplicaciones se digitaban fuera de línea y podían verificarse en forma directa, los procesos, la actualización de un archivo maestro a partir de un archivo de transacciones, y los resultados generalmente en forma de producción de un reporte, permitían si el auditor de sistemas estaba desarrollando sus funciones en forma correcta.

Los auditores de sistemas de información revisan y evalúan el desarrollo, mantenimiento y operación de los diferentes componentes en los sistemas automatizados (o dichos sistemas como un todo) y sus interfaces con las áreas no automatizadas de la operación de la organización.

Para que un profesional llegue al convencimiento total de la confiabilidad de la metodología debe estudiar las técnicas, instrumentos, procedimientos y todos aquellos elementos que involucren la auditoria; luego debe estudiar la metodología y evaluar cada instrumento.

Las técnicas de auditoria, debido a la variación de circunstancias en que el auditor realiza su trabajo y a la diversidad de condiciones de las empresas que se someten al examen del auditor son de muy diversas clases, pero puede agruparse bajo los siguientes rubros.

• Estudio General
• Análisis
• Inspección
• Confirmación
• Declaración o Certificaciones
• Observación
• Cálculo

Se insiste que en el transcurso de los últimos años, las empresas, que no se preocupan en incluir controles dentro de sus sistemas de cómputo, han sufrido y sufrirán lamentables pérdidas.

Mientras aún no se comprenda que es necesario diseñar programas sobre la auditoria de sistemas con respecto a los programas de cómputo, que debemos verificar y controlar, no solo después de realizado el proceso, sino antes; previsto desde el desarrollo, complementando al grupo con las técnicas de cómputo y los usuarios, mientras esto no suceda, todavía tendremos que seguir usando las técnicas que actualmente cumplen una labor menos sofisticada, que permite tener una idea general de lo que sucede en la empresa auditada.

Es pues, imprescindible, que los gerentes de informática y de auditoria interna comprendan la real necesidad gerencial de estar unidos para cumplir con el objetivo común a nivel de empresa, no pensar a nivel personal-individual, objetivo que se dirija a crear controles cruzados programados por personal de computo de la empresa pero siendo usuario directo. El personal de auditoria interna es comprensible que al momento de evaluar luego los primeros resultados, éstos no enmarquen totalmente el contexto de controles integrados, pero cualquier esfuerzo es complementar "un poco cada vez" con los costos invertidos será considerados así Inversión. Dado que reverterá en la posición de tomar información precisa, integra y segura emitida por el computador.

4. Características.

La información de la empresa y para la empresa, siempre importante, se ha convertido en un Activo Real de la misma, como sus Stocks o materias primas si las hay. Por ende, han de realizarse inversiones informáticas, materia de la que se ocupa la Auditoria de Inversión Informática.

Del mismo modo, los Sistemas Informáticos han de protegerse de modo global y particular: a ello se debe la existencia de la Auditoria de Seguridad Informática en general, o a la auditoria de Seguridad de alguna de sus áreas, como pudieran ser Desarrollo o Técnica de Sistemas.

Cuando se producen cambios estructurales en la Informática, se reorganiza de alguna forma su función: se está en el campo de la Auditoria de Organización Informática.

Estos tres tipos de auditorias engloban a las actividades auditoras que se realizan en una auditoria parcial. De otra manera: cuando se realiza una auditoria del área de Desarrollo de Proyectos de la Informática de una empresa, es porque en ese Desarrollo existen, además de ineficiencias, debilidades de organización, o de inversiones, o de seguridad, o alguna mezcla de ellas.

a. Síntomas de Necesidad de una Auditoria Informática:

Las empresas acuden a las auditorias externas cuando existen síntomas bien perceptibles de debilidad. Estos síntomas pueden agruparse en clases:

• Síntomas de descoordinación y desorganización:

– No coinciden los objetivos de la Informática de la Compañía y de la propia Compañía.

– Los estándares de productividad se desvían sensiblemente de los promedios conseguidos habitualmente.

Puede ocurrir con algún cambio masivo de personal, o en una reestructuración fallida de alguna área o en la modificación de alguna Norma importante.

• Síntomas de mala imagen e insatisfacción de los usuarios:

– No se atienden las peticiones de cambios de los usuarios. Ejemplos: cambios de Software en los terminales de usuario, refrescamiento de paneles, variación de los ficheros que deben ponerse diariamente a su disposición.

– No se reparan las averías de Hardware ni se resuelven incidencias en plazos razonables. El usuario percibe que está abandonado y desatendido permanentemente.

– No se cumplen en todos los casos los plazos de entrega de resultados periódicos. Pequeñas desviaciones pueden causar importantes desajustes en la actividad del usuario, en especial en los resultados de Aplicaciones críticas y sensibles.

• Síntomas de debilidades económico-financiero:

– Incremento desmesurado de costes.

– Necesidad de justificación de Inversiones Informáticas (la empresa no está absolutamente convencida de tal necesidad y decide contrastar opiniones).

– Desviaciones Presupuestarias significativas.

– Costes y plazos de nuevos proyectos (deben auditarse simultáneamente a Desarrollo de Proyectos y al órgano que realizó la petición).

• Síntomas de Inseguridad: Evaluación de nivel de riesgos

– Seguridad Lógica

– Seguridad Física

– Confidencialidad

Los datos son propiedad inicialmente de la organización que los genera. Los datos de personal son especialmente confidenciales.

– Continuidad del Servicio. Es un concepto aún más importante que la Seguridad. Establece las estrategias de continuidad entre fallos mediante Planes de Contingencia* Totales y Locales.

– Centro de Proceso de Datos fuera de control. Si tal situación llegara a percibirse, sería prácticamente inútil la auditoria. Esa es la razón por la cual, en este caso, el síntoma debe ser sustituido por el mínimo indicio.

b. Planes de Contingencia:

Por ejemplo, la empresa sufre un corte total de energía o explota, ¿Cómo sigo operando en otro lugar? Lo que generalmente se pide es que se hagan Backups de la información diariamente y que aparte, sea doble, para tener un Backup en la empresa y otro afuera de ésta. Una empresa puede tener unas oficinas paralelas que posean servicios básicos (luz, teléfono, agua) distintos de los de la empresa principal, es decir, si a la empresa principal le proveía teléfono Telecom, a las oficinas paralelas, Telefónica. En este caso, si se produce la inoperancia de Sistemas en la empresa principal, se utilizaría el Backup para seguir operando en las oficinas paralelas. Los Backups se pueden acumular durante dos meses, o el tiempo que estipule la empresa, y después se van reciclando.

5. Clasificación.

La auditoria podemos clasificarla de la siguiente manera:

1. La auditoria interna es la realizada con recursos materiales y personas que pertenecen a la empresa auditada. Los empleados que realizan esta tarea son remunerados económicamente. El estudio y evaluación del control interno se efectúa con el objeto de cumplir con la norma de ejecución del trabajo que requiere que: el auditor debe efectuar un estudio y evaluación adecuados del control interno existente, que le sirvan de base para determinar el grado de confianza que va a depositar en él, así mismo, que le permitan determinar la naturaleza, extensión y oportunidad que va a dar a los procedimientos de auditoría.

   El Control Interno comprende el plan de organización y todos los métodos y procedimientos que en forma coordinada se adoptan en un negocio para salvaguardar sus activos, verificar la razón habilidad y confiabilidad de su información financiera, promover la eficiencia operacional y provocar la adherencia a las políticas prescritas por la administración.

   El Control Interno contable comprende el plan de organización y los procedimientos y registros que se refieren a la protección de los activos y a la confiabilidad de los registros financieros, por lo tanto está diseñado en función de los objetivos de la organización, para ofrecer seguridad razonable, de que las operaciones se realizan de acuerdo con las normas y políticas señaladas por la administración.

   La auditoria interna existe por expresa decisión de la Empresa, o sea, que puede optar por su disolución en cualquier momento.

   Por otro lado, la auditoria externa es realizada por personas afines a la empresa auditada; es siempre remunerada. Se presupone una mayor objetividad que en la Auditoria Interna, debido al mayor distanciamiento entre auditores y auditados.

2. Auditoria Interna/Externa.

   La tecnología en información está afectando la forma en que las organizaciones están estructuradas, administradas y operadas. En algunos casos, los cambios son dramáticos. Cuando existe la necesidad de un nuevo diseño de sistemas administrativos para lograr una efectiva administración y control financiero, la planeación administrativa y el proceso de diseño y los requerimientos de control deberán cambiar o necesariamente se modificarán con los cambios de la tecnología de información. El incremento de la tecnología de información está soportado por una reestructuración organizacional alrededor de esta tecnología.

   William P. Leonard, define la auditoria administrativa como: El examen global y constructivo de la estructura de una empresa, de una institución, una sección del gobierno o cualquier parte de un organismo, en cuanto a sus planes y objetivos, sus métodos y controles, su forma de operación y sus facilidades humanas y física.

3. Auditoria Administrativa/Operacional.
4. Auditoria de Informática.

La auditoria informática interna cuenta con algunas ventajas adicionales muy importantes respecto de la auditoria externa, las cuales no son tan perceptibles como en las auditorias convencionales. La auditoria interna tiene la ventaja de que puede actuar periódicamente realizando Revisiones globales, como parte de su Plan Anual y de su actividad normal. Los auditados conocen estos planes y se habitúan a las Auditorias, especialmente cuando las consecuencias de las Recomendaciones habidas benefician su trabajo.

En una empresa, los responsables de Informática escuchan, orientan e informan sobre las posibilidades técnicas y los costes de tal Sistema. Con voz, pero a menudo sin voto, Informática trata de satisfacer lo más adecuadamente posible aquellas necesidades.

La empresa necesita controlar su Informática y ésta necesita que su propia gestión esté sometida a los mismos Procedimientos y estándares que el resto de aquella. La conjunción de ambas necesidades cristaliza en la figura del auditor interno informático.

La auditoria informática, tanto externa como interna, debe ser una actividad exenta de cualquier contenido o matiz "político" ajeno a la propia estrategia y política general de la empresa. La función auditora puede actuar de oficio, por iniciativa del propio órgano, o a instancias de parte, esto es, por encargo de la dirección o cliente.

La auditoria en Informática se clasifica a su vez de la siguiente manera:

1. Estructura Orgánica, en dónde se deberá solicitar el manual de organización de la dirección.

   Recursos Humanos, se deberá obtener información sobre la situación del personal del área.

   Personal de Informática, se deberán efectuar entrevistas con el personal de procesamiento de datos.

   Situación Personal y Financiera: Obtención y análisis presupuestal del departamento.

2. Auditoria Organizacional: Está orientada a la revisión sistematizada del área a través de la observación y entrevistas de fondo en cuanto a:

   La operatividad es uno de los objetivos de la Auditoria en Informática, es una función de mínimos consistente en que la organización y las maquinas funcionen, siquiera mínimamente. No es admisible detener la maquinaria informática para descubrir sus fallos y comenzar de nuevo. La auditoria debe iniciar su actividad cuando los Sistemas están operativos, es el principal objetivo el de mantener tal situación. Tal objetivo debe conseguirse tanto a nivel global como parcial.

   La operatividad de los Sistemas ha de constituir entonces la principal preocupación del auditor informático. Para conseguirla hay que acudir a la realización de Controles Técnicos Generales de Operatividad y Controles Técnicos Específicos de Operatividad, previos a cualquier actividad de aquel.

   Los Controles Técnicos Generales son los que se realizan para verificar la compatibilidad de funcionamiento simultáneo del Sistema Operativo y el Software de base con todos los subsistemas existentes, así como la compatibilidad del Hardware y del Software instalados. Estos controles son importantes en las instalaciones que cuentan con varios competidores, debido a que la profusión de entornos de trabajo muy diferenciados obliga a la contratación de diversos productos de Software básico, con el consiguiente riesgo de abonar más de una vez el mismo producto o desaprovechar parte del Software abonado. Puede ocurrir también con los productos de Software básico desarrollados por el personal de Sistemas Interno, sobre todo cuando los diversos equipos están ubicados en Centros de Proceso de Datos geográficamente alejados. Lo negativo de esta situación es que puede producir la inoperatividad del conjunto. Cada Centro de Proceso de Datos tal vez sea operativo trabajando independientemente, pero no será posible la interconexión e intercomunicación de todos los Centros de Proceso de Datos si no existen productos comunes y compatibles.

   Los Controles Técnicos Específicos, de modo menos acusado, son igualmente necesarios para lograr la Operatividad de los Sistemas. Un ejemplo de lo que se puede encontrar mal son parámetros de asignación automática de espacio en disco que dificulten o impidan su utilización posterior por una Sección distinta de la que lo generó. También, los periodos de retención de ficheros comunes a varias Aplicaciones pueden estar definidos con distintos plazos en cada una de ellas, de modo que la pérdida de información es un hecho que podrá producirse con facilidad, quedando inoperativa la explotación de alguna de las Aplicaciones mencionadas.

   Parámetros de asignación automática de espacio en disco:

   Todas las Aplicaciones que se desarrollan son súper parametrizadas, es decir, que tienen un montón de parámetros que permiten configurar cual va a ser el comportamiento del Sistema. Una Aplicación va a usar para tal y tal cosa cierta cantidad de espacio en disco. Si uno no analizó cual es la operatoria y el tiempo que le va a llevar ocupar el espacio asignado, y se pone un valor muy chico, puede ocurrir que un día la Aplicación reviente, se caiga. Si esto sucede en medio de la operatoria y la Aplicación se cae, el volver a levantarla, con la nueva asignación de espacio, si hay que hacer reconversiones o lo que sea, puede llegar a demandar muchísimo tiempo, lo que significa un riesgo enorme.

3. Auditoria de Sistemas: Este tipo de auditoria está centrada a revisar si existen realmente sistemas entrelazados como un todo o bien si existen programas aislados. Otros de los factores a evaluar es si existe un plan estratégico para la elaboración de los sistemas o si se están elaborando sin el adecuado señalamiento de prioridades y objetivos.
4. Auditoria del Proceso de Datos y de los Equipos de Computo. Los datos son uno de los recursos más valiosos de las organizaciones y, aunque son intangibles, necesitan ser controlados y auditados con el mismo cuidado que los demás inventarios de la organización. Una dirección de informática bien administrada debe tener y observar reglas relativas al orden y cuidado de la sala de maquinas. También dentro de los objetivos está el de evaluar el grado de eficiencia con el cual el sistema operativo satisface las necesidades de la instalación y revisar las políticas seguidas por la unidad de informática en la conservación de su programática, otro objetivo es evaluar la eficiencia con que opera el área de captación y producción.

6. Importancia de la auditoria.

Metodología de Trabajo de Auditoria Informática

El método de trabajo del auditor pasa por las siguientes etapas:

• Alcance y Objetivos de la Auditoria Informática.
• Estudio inicial del entorno auditable.
• Determinación de los recursos necesarios para realizar la auditoria.
• Elaboración del plan y de los Programas de Trabajo.
• Actividades propiamente dichas de la auditoria.
• Confección y redacción del Informe Final.
• Redacción de la Carta de Introducción o Carta de Presentación del Informe final.

Alcance y Objetivos de la Auditoria Informática

El alcance de la auditoria expresa los límites de la misma. Debe existir un acuerdo muy preciso entre auditores y clientes sobre las funciones, las materias y las organizaciones a auditar.

A los efectos de acotar el trabajo, resulta muy beneficioso para ambas partes expresar las excepciones de alcance de la auditoria, es decir cuales materias, funciones u organizaciones no van a ser auditadas.

Tanto los alcances como las excepciones deben figurar al comienzo del Informe Final.

Las personas que realizan la auditoria han de conocer con la mayor exactitud posible los objetivos a los que su tarea debe llegar. Deben comprender los deseos y pretensiones del cliente, de forma que las metas fijadas puedan ser cumplidas.

Una vez definidos los objetivos (objetivos específicos), éstos se añadirán a los objetivos generales y comunes de a toda auditoria Informática: La operatividad de los Sistemas y los Controles Generales de Gestión Informática.

Estudio Inicial del entorno auditable

Para realizar dicho estudio ha de examinarse las funciones y actividades generales de la informática.

Para su realización el auditor debe conocer lo siguiente:

Organización

Para el equipo auditor, el conocimiento de quién ordena, quién diseña y quién ejecuta es fundamental. Para realizar esto en auditor deberá fijarse en:

1. Organigrama:

El organigrama expresa la estructura oficial de la organización a auditar.

Si se descubriera que existe un organigrama fáctico diferente al oficial, se pondrá de manifiesto tal circunstancia.

2. Departamentos:

Se entiende como departamento a los órganos que siguen inmediatamente a la Dirección. El equipo auditor describirá brevemente las funciones de cada uno de ellos.

3. Relaciones Jerárquicas y funcionales entre órganos de la Organización:

El equipo auditor verificará si se cumplen las relaciones funcionales y Jerárquicas previstas por el organigrama, o por el contrario detectará, por ejemplo, si algún empleado tiene dos jefes.

Las de Jerarquía implican la correspondiente subordinación. Las funcionales por el contrario, indican relaciones no estrictamente subordinables.

4. Flujos de Información:

Además de las corrientes verticales intradepartamentales, la estructura organizativa cualquiera que sea, produce corrientes de información horizontales y oblicuas extradepartamentales.

Los flujos de información entre los grupos de una organización son necesarios para su eficiente gestión, siempre y cuando tales corrientes no distorsionen el propio organigrama.

En ocasiones, las organizaciones crean espontáneamente canales alternativos de información, sin los cuales las funciones no podrían ejercerse con eficacia; estos canales alternativos se producen porque hay pequeños o grandes fallos en la estructura y en el organigrama que los representa.

Otras veces, la aparición de flujos de información no previstos obedece a afinidades personales o simple comodidad. Estos flujos de información son indeseables y producen graves perturbaciones en la organización.

1. Número de Puestos de trabajo

El equipo auditor comprobará que los nombres de los Puesto de los Puestos de Trabajo de la organización corresponden a las funciones reales distintas.

Es frecuente que bajo nombres diferentes se realicen funciones idénticas, lo cual indica la existencia de funciones operativas redundantes.

Esta situación pone de manifiesto deficiencias estructurales; los auditores darán a conocer tal circunstancia y expresarán el número de puestos de trabajo verdaderamente diferentes.

Número de personas por Puesto de Trabajo

Es un parámetro que los auditores informáticos deben considerar. La inadecuación del personal determina que el número de personas que realizan las mismas funciones rara vez coincida con la estructura oficial de la organización.

Entorno Operacional

El equipo de auditoria informática debe poseer una adecuada referencia del entorno en el que va a desenvolverse.

Este conocimiento previo se logra determinando, fundamentalmente, los

Siguientes extremos:

1. Se determinará la ubicación geográfica de los distintos Centros de Proceso de Datos en la empresa. A continuación, se verificará la existencia de responsables en cada unos de ellos, así como el uso de los mismos estándares de trabajo.

2. Situación geográfica de los Sistemas:

   Cuando existen varios equipos, es fundamental la configuración elegida para cada uno de ellos, ya que los mismos deben constituir un sistema compatible e intercomunicado. La configuración de los sistemas esta muy ligada a las políticas de seguridad lógica de las compañías.

   Los auditores, en su estudio inicial, deben tener en su poder la distribución e interconexión de los equipos.

3. Arquitectura y configuración de Hardware y Software:

   El auditor recabará información escrita, en donde figuren todos los elementos físicos y lógicos de la instalación. En cuanto a Hardware figurarán las CPUs, unidades de control local y remoto, periféricos de todo tipo, etc.

   El inventario de software debe contener todos los productos lógicos del Sistema, desde el software básico hasta los programas de utilidad adquiridos o desarrollados internamente. Suele ser habitual clasificarlos en facturables y no facturables.

4. Inventario de Hardware y Software:
5. Comunicación y Redes de Comunicación:

En el estudio inicial los auditores dispondrán del número, situación y características principales de las líneas, así como de los accesos a la red pública de comunicaciones.

Igualmente, poseerán información de las Redes Locales de la Empresa.

Aplicaciones bases de datos y ficheros

El estudio inicial que han de realizar los auditores se cierra y culmina con una idea general de los procesos informáticos realizados en la empresa auditada. Para ello deberán conocer lo siguiente:

2. Volumen, antigüedad y complejidad de las Aplicaciones

   Se clasificará globalmente la existencia total o parcial de metodología en el desarrollo de las aplicaciones. Si se han utilizados varias a lo largo del tiempo se pondrá de manifiesto.

3. Metodología del Diseño

   La existencia de una adecuada documentación de las aplicaciones proporciona beneficios tangibles e inmediatos muy importantes.

   La documentación de programas disminuye gravemente el mantenimiento de los mismos.

4. Documentación
5. Cantidad y complejidad de Bases de Datos y Ficheros.

El auditor recabará información de tamaño y características de las Bases de Datos, clasificándolas en relación y jerarquías. Hallará un promedio de número de accesos a ellas por hora o días. Esta operación se repetirá con los ficheros, así como la frecuencia de actualizaciones de los mismos.

Estos datos proporcionan una visión aceptable de las características de la carga informática.

Determinación de los recursos necesarios para realizar la auditoria

Mediante los resultados del estudio inicial realizado se procede a determinar los recursos humanos y materiales que han de emplearse en la auditoria.

Recursos materiales

Es muy importante su determinación, por cuanto la mayoría de ellos son proporcionados por el cliente. Las herramientas software propias del equipo van a utilizarse igualmente en el sistema auditado, por lo que han de convenirse en lo posible las fechas y horas de uso entre el auditor y cliente.

Los recursos materiales del auditor son de dos tipos:

1. Programas propios de la auditoria: Son muy potentes y Flexibles. Habitualmente se añaden a las ejecuciones de los procesos del cliente para verificarlos.

   Monitores: Se utilizan en función del grado de desarrollo observado en la actividad de Técnica de Sistemas del auditado y de la cantidad y calidad de los datos ya existentes.

2. Recursos materiales Software
3. Recursos materiales Hardware

Los recursos hardware que el auditor necesita son proporcionados por el cliente. Los procesos de control deben efectuarse necesariamente en las Computadoras del auditado.

Para lo cuál habrá de convenir, tiempo de maquina, espacio de disco, impresoras ocupadas, etc.

Recursos Humanos

La cantidad de recursos depende del volumen auditable. Las características y perfiles del personal seleccionado dependen de la materia auditable.

Es igualmente reseñable que la auditoria en general suele ser ejercida por profesionales universitarios y por otras personas de probada experiencia multidisciplinaria.

Perfiles Profesionales de los auditores informáticos

Una vez asignados los recursos, el responsable de la auditoría y sus colaboradores establecen un plan de trabajo. Decidido éste, se procede a la programación del mismo.

El plan se elabora teniendo en cuenta, entre otros criterios, los siguientes:

a) Si la Revisión debe realizarse por áreas generales o áreas específicas. En el primer caso, la elaboración es más compleja y costosa.

b) Si la auditoria es global, de toda la Informática, o parcial. El volumen determina no solamente el número de auditores necesarios, sino las especialidades necesarias del personal.

• En el plan no se consideran calendarios, porque se manejan recursos genéricos y no específicos.
• En el Plan se establecen los recursos y esfuerzos globales que van a ser necesarios.
• En el Plan se establecen las prioridades de materias auditables, de acuerdo siempre con las prioridades del cliente.
• El Plan establece disponibilidad futura de los recursos durante la revisión.
• El Plan estructura las tareas a realizar por cada integrante del grupo.
• En el Plan se expresan todas las ayudas que el auditor ha de recibir del auditado.

Una vez elaborado el Plan, se procede a la Programación de actividades. Esta ha de ser lo suficientemente como para permitir modificaciones a lo largo del proyecto.

La auditoria Informática general se realiza por áreas generales o por áreas específicas. Si se examina por grandes temas, resulta evidente la mayor calidad y el empleo de más tiempo total y mayores recursos.

Cuando la auditoria se realiza por áreas específicas, se abarcan de una vez todas las peculiaridades que afectan a la misma, de forma que el resultado se obtiene más rápidamente y con menor calidad.

Técnicas de Trabajo:

– Análisis de la información recabada del auditado.

– Análisis de la información propia.

– Cruzamiento de las informaciones anteriores.

– Entrevistas.

– Simulación.

– Muestreos.

Herramientas:

– Cuestionario general inicial.

– Cuestionario Checklist.

– Estándares.

– Monitores.

– Simuladores (Generadores de datos).

– Paquetes de auditoria (Generadores de Programas).

– Matrices de riesgo.

Confección y redacción del Informe Final

La función de la auditoria se materializa exclusivamente por escrito. Por lo tanto la elaboración final es el exponente de su calidad.

Resulta evidente la necesidad de redactar borradores e informes parciales previos al informe final, los que son elementos de contraste entre opinión entre auditor y auditado y que pueden descubrir fallos de apreciación en el auditor.

Estructura del informe final:

El informe comienza con la fecha de comienzo de la auditoria y la fecha de redacción del mismo. Se incluyen los nombres del equipo auditor y los nombres de todas las personas entrevistadas, con indicación de la jefatura, responsabilidad y puesto de trabajo que ostente.

Definición de objetivos y alcance de la auditoria.

Enumeración de temas considerados:

Antes de tratarlos con profundidad, se enumerarán lo más exhaustivamente posible todos los temas objeto de la auditoria.

Cuerpo expositivo:

Para cada tema, se seguirá el siguiente orden a saber:

2. Situación actual. Cuando se trate de una revisión periódica, en la que se analiza no solamente una situación sino además su evolución en el tiempo, se expondrá la situación prevista y la situación real.
3. Tendencias. Se tratarán de hallar parámetros que permitan establecer tendencias futuras.
4. Puntos débiles y amenazas.
5. Recomendaciones y planes de acción. Constituyen junto con la exposición de puntos débiles, el verdadero objetivo de la auditoria informática.
6. Redacción posterior de la Carta de Introducción o Presentación.

E. PRUEBAS DE SOFTWARE.

1. Generalidades.

La etapa de pruebas de componentes comprende las pruebas de funcionamiento de los componentes claramente identificables. Estos son funciones o grupos de métodos conjuntados en módulos o en objetivos. Durante las pruebas de integración, estos componentes se integran para formar subsistemas o el sistema completo. En esta etapa, las pruebas se enfocan en las interacciones entre los componentes y en la funcionalidad y el desempeño del sistema como un todo. Si embargo, inevitablemente los defectos en los componentes que no han sido tomadas en cuenta durante las pruebas iniciales se ponen al descubierto durante las pruebas de integración.

Para muchos sistemas los programadores tienen la responsabilidad de probar sus propio código(módulos u objetos). Una vez que lo hacen, el trabajo se pasa a un equipo de integración que integra los módulos de los diferentes desarrolladores, construye el software y prueba el sistema conjunto, si embargo para sistemas críticos, se utiliza un proceso más formal donde probadores independientes son responsables de todas las etapas del proceso de pruebas. Las pruebas se desarrollan de forma independiente y se lleva a cabo un registro detallado.

Cuando se prueban sistemas críticos, una especificación detallada de cada componente de software es utilizado por el equipo independiente para generar las pruebas del sistema. Sin embargo en muchos casos, llevar a cabo las pruebas es un proceso más intuitivo puesto que no existe tiempo para redactar las especificaciones detalladas de cada parte de un sistema de software. En su lugar, las interfaces de los componentes principales del sistema se especifica y los programadores individuales y los equipos de programación toman las responsabilidad de diseñar, desarrollar y probar estos componentes. Las pruebas por lo general se basan en una compresión intuitiva de como operan estos componentes.

Si embargo, las pruebas de integración se basan en una especificación escrita del sistema. Un equipo aparte es responsable de las pruebas de integración.

2. Definición.

Las siguientes definiciones son algunas de las recogidas en el diccionario IEEE en relación a las pruebas [IEEE, 1990], que complementamos con otras más informales:

• Pruebas: "una actividad en la cual un sistema o uno de sus componentes se ejecuta 2 en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto". Para Myers [MYERS, 1979], probar (o la prueba) es el "proceso de ejecutar un programa con el fin de encontrar errores". El nombre "prueba", además de la actividad de probar, se puede utilizar para designar "un conjunto de casos y procedimientos de prueba" [IEEE, 1990].
• Caso de prueba : "un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito". "También se puede referir a la documentación en la que se describen las entradas, condiciones y salidas de un caso de prueba".
• Defecto: "un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa".
• Fallo: "La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados".

2. Antecedentes.

El desarrollo de software tiene sólo algunas décadas; la industria del software está aún definiendo sus caminos, buscando la manera adecuada de desarrollarse. Considerar las propuestas basadas en la experiencia de los demás nos permitirá desarrollarnos con mayor velocidad; por ello hablaremos de las últimas tendencias de las pruebas de software.

Anteriormente, las pruebas de software se consideraban sólo una actividad que realizaba el programador para encontrar fallas en sus productos; con el paso de los años se ha determinado la importancia que tienen para garantizar el tiempo, el costo y la calidad del producto, de tal forma que actualmente son un proceso cuyo propósito principal es evaluar la funcionalidad del software respecto de los requerimientos establecidos al inicio.

¿Cuál es la nueva tendencia en las pruebas? Iniciarlas antes, dentro del proyecto, y capacitar a especialistas responsables de esta actividad. El primer punto quiere decir que actualmente las especificaciones de pruebas se realizan al mismo tiempo que el diseño de software; la propuesta es iniciar el análisis del testware junto con el análisis del software. Ello habla de sondeos preventivos que permitan ejecutar las pruebas tan pronto como el software esté listo y con ello no sólo descubrir errores, sino evitarlos.

El segundo punto habla de crear conciencia acerca de la importancia de las pruebas y tener un equipo de personas dedicadas a esta actividad que puedan integrarse a un proyecto y sean responsables de su calidad.

Los objetivos actuales de las pruebas no sólo tienen que ver con corregir errores, sino con prevenirlos influyendo y controlando el diseño y desarrollo del software. Las pruebas deben ser empleadas como modelos de los requerimientos de la aplicación que se ha de construir; por tanto, en las especificaciones de software deben incluirse especificaciones de pruebas, ambas deberán revisarse en conjunto, y en esta revisión deberá participar un especialista en pruebas.

Por otro lado, se debe reconocer que las pruebas son una especie de administrador de riesgos: al igual que en los problemas de combinatorias complejas, se puede definir cuál debe considerarse buen resultado, aunque no necesariamente sea el mejor; con ello quiero decir que las pruebas sólo deben obtener un producto práctico con la calidad y funcionalidad requeridas.

Cuando aparecieron los primeros grandes sistemas informáticos se incluyó a nivel metódico e imprescindible un hasta entonces nuevo proceso en la confección de los mismos: el proceso de prueba.

Hoy en día se calcula que la fase o proceso de pruebas representa más de la mitad del coste de un programa, ya que requiere un tiempo similar al de la programación lo que obviamente acarrea un alto costo económico cuando estos no involucran vidas humanas, puesto que en este último caso el costo suele superar el 80% siendo esta etapa mas cara que el propio desarrollo y diseño de los distintos programas que conforman el sistema.

Un proceso de pruebas requiere mucho más que tiempo y dinero, necesita una verdadera metodología la cual exige herramientas y conocimientos destinados a dicha tarea, este texto trata de ser una pequeña guía para los programadores que aún no se han entrenado en este plano.

4. Características.

Algunas de las características típicas del desarrollo de software basado en el ciclo de vida son:

• La realización de controles periódicos, normalmente coincidiendo con los hitos de los proyectos o la terminación de documentos. Estos controles pretenden una evaluación de la calidad de los productos generados (especificación de requisitos, documentos de diseño, etc.) para poder detectar posibles defectos cuanto antes. Sin embargo, todo sistema o aplicación, independientemente de estas revisiones, debe ser probado mediante su ejecución controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminación del código del software, se denominan habitualmente pruebas.
• Las pruebas se deben realizar, en el entorno en el que se utilizará el sistema, lo que incluye el personal que lo maneja.
• La etapa de pruebas no debe ser posterior a la confección de un programa, tiene que ser paralela a la programación.
• Las pruebas no comienzan formalmente hasta que un número mínimo predeterminado ha instalado el software. En particular, usuarios que tardan en comenzar, generalmente nunca lo hacen y ponen en peligro todo el proceso. Esto puede significar tener que reemplazar usuarios. En la práctica, pasarán al menos cuatro semanas antes del punto de partida.

5. Clasificaciones.

5.1 Pruebas de defectos.

La meta de las pruebas de defectos es exponer los defectos latentes en un sistema de software antes de entregar el sistema. Esto contrasta con las pruebas de validación requiere que el sistema se desempeñe correctamente utilizando casos de pruebas dados. Una prueba de defectos exitosa es una prueba que provoca que el sistema se desempeñe incorrectamente y así exponer un defecto. Esto enfatiza un hecho importante acerca de las pruebas. Demuestra la presencia, no la ausencia, de fallas en el programa.

Los casos de prueba son especificaciones de las entradas a la prueba y de las salida esperada del sistema más una declaración de lo que prueba. Los datos de prueba son las entradas seleccionadas para probar el sistema. Dichos datos algunas veces se generan de forma automática. La generación de casos de prueba automáticos es imposible ya que la salida de la prueba no se puede predecir.

Las pruebas excautivas, donde se prueba cada posible secuencia de ejecuciones de programas, no son prácticas. Por lo tanto, llevar a cabo la pruebas se basa en un subconjunto de posibles casos de prueba. Las organizaciones deben desarrollar políticas paras elegir este subconjunto en lugar de dejar esto al equipo de desarrollo. Estas políticas donde todas las instrucciones del programa se ejecutan al menos una vez. De forma alternativa, las políticas de prueba se basan en la experiencia de la utilización del sistema y se enfoca en las pruebas de las características del sistema operacional.

• Se deben de probar todas las funciones del sistema que se accedan a través de menús.
• Se deben probar las combinaciones de funciones(por ejemplo dar formato al texto) que se acceden a través del mismo menú.
• Cuando el usuario introduce la entrada, todas las funciones deben probar tanto con las entradas correctas como incorrectas.

a. Pruebas de caja negra.

Las pruebas funcionales o de caja negra son un enfoque para llevar a cabo pruebas de donde éstas se derivan de la especificación del programa o componentes.

b. Participaciones.

Los datos de entrada a un programa por lo regular son de varias clases diferentes. Estos tienen características comunes, por ejemplo, son números positivos, números negativos, cadenas sin espacio en blanco. Etc.

d. Pruebas estructurales.

Son el enfoque de prueba donde éstas se generan a partir del conocimiento de la estructura e implementación del software. Algunas veces, este enfoque se le denomina prueba de "caja negra", de "caja de cristal", o de "caja transparente" para distinguirlo de la prueba de caja negra.

e. Pruebas de trayectoria.

Estas pruebas son una estrategia de prueba estructural cuyo objetivo es probar cada trayectoria de ejecución independiente en un componente o programa. Si se ejecuta cada trayectoria independiente, todas las instrucciones en el componente se ejecutan al menos una vez.

5.2 Pruebas de integración.

Una vez que se probaron los componentes individuales del programa, deben integrarse para crear un sistema parcial, o completo. Este proceso de integración comprende la construcción del sistema y probar el sistema resultante con respecto a los problemas resultantes con respecto a los problemas que surjan de las iteraciones de los componentes. Las pruebas de integración se desarrollan a partir de las especificaciones de los componentes. Las pruebas de integración se desarrollan a partir de la especificación del sistema y dan inicio tan pronto como estén disponibles versiones utilizables de algunos componentes del sistema.

Las principales dificultades que surgen en la pruebas de integración es localizar los errores que descubren durante el proceso. Existen interacciones complejas entre los componentes del sistema y cuando se descubre una salida anómala, es difícil encontrar la fuente del error. Para hacer más fácil la localización de errores, siempre se utiliza un enfoque incremental para la integración y pruebas del sistema. De forma inicial, se debe integrar una configuración mínima del sistema y probar dicho sistema. Luego se agrega componentes a esta configuración mínima y se prueba después de que se agrega cada incremento.

a. Pruebas descendentes y ascendentes.

La estrategias de pruebas descendentes y ascendentes refleja diferente enfoques de la integración del sistema. En la integración descendente, los componentes de los niveles altos de un sistema se integran y prueban antes de que se complete su diseño e implementación. En la integración ascendente, los componentes de los niveles bajos se integran y prueban antes de que se desarrollen los componentes de los niveles altos.

Las pruebas descendentes son una parte integral del proceso de desarrollo descendente en el cual este último inicia con los componentes de los niveles altos y descienden en la jerarquía de los componentes. Estos tienen la misma interfaz que los componentes pero funcionalidad muy limitada. Después de que se programa y prueba el primer componente de nivel alto, se implantan y prueban sus subcomponentes, de la misma forma. Este proceso continúa hasta que los componentes de nivel bajo se implanten. De esta forma queda completamente probado el sistema completo.

En contraste, las pruebas ascendentes comprenden integrar y probar los módulos en los niveles bajos de la jerarquía, y después asciende por la jerarquía de los módulos hasta que el módulo final se prueba. Este enfoque no requiere que el diseño arquitectónico del sistema este completo por lo que se puede comenzar en una etapa inicial del proceso de desarrollo. Se emplea donde el sistema reutiliza y modifica componentes de otros sistemas.

Las pruebas de integración descendentes y ascendentes se comparan bajo cuatros encabezados:

• Validación arquitectónica: las pruebas descendentes son susceptibles a descubrir errores en la arquitectura del sistema y en el diseño de alto nivel en las etapas iniciales del proceso de desarrollo.
• Demostración del sistema: En el desarrollo descendente se dispone de un sistema funcional limitado en las primeras etapas de desarrollo.
• Implementación de las pruebas.
• Observación de las prueba: Tanto las pruebas ascendentes como descendentes pueden tener problema con la observación de la prueba. En muchos sistemas, los niveles más altos del sistema que se implementan primero en un proceso descendente no generan salidas; sin embargo, para probar estos niveles, se les debe forzar a hacerlo. El probador debe crear un entorno artificial para generar los resultados de la prueba. Para las pruebas ascendentes, también es necesario crear un entorno artificial con el fin de que se pueda observar la ejecución de los componentes de los niveles inferiores.

b. Pruebas de interfaces.

Las pruebas de interfaces toman lugar cuando los módulos o subsistemas se integran para crear sistemas más grandes. Cada módulo o subsistema tiene una interfaz definida que es llamada por otros componentes del programa. El objetivo de las pruebas de interfaces es detectar las fallas que introdujeron en el sistema debido errores de las interfaces o suposiciones no válidas a cerca de las interfaces.

c. Pruebas de esfuerzo.

Una vez que el sistema se integra completamente es posible probar el sistema acerca de las propiedades emergentes tal como el desempeño y la fiabilidad. Se tiene que diseñar pruebas de desempeño para asegurar que el sistema puede procesar la carga pretendida. Por lo general esto comprende planear una serie de pruebas donde la carga se incrementa de forma constante hasta que el desempeño del sistema sea inaceptables.

5.3 Pruebas de orientadas a objetos.

Estas son pruebas de componentes, en las que componentes del sistema se prueban de forma individual, y pruebas de integración, en la que las colecciones de componentes se integran en subsistemas y se prueban el sistema final. Estas actividades se aplican de igual forma a los sistemas orientados objetos. Sin embargo, existen diferencias importantes entre los sistemas orientados objetos y los sistemas desarrollados mediante un modelo funcional:

• Los objetos como componentes individuales son a menudo más grandes que una sola función.
• Los objetos integrados en los subsistemas son por lo general débilmente acopladas y no existe un "máximo" para el sistema.
• Si los objetos de utilizan, los probadores no tiene acceso al código fuente del componente para su análisis.

Estas diferencias significativas que los enfoques de prueba de caja blanca basados en el análisis de código tiene que ampliarse para cubrir objetivos de grano grueso y se tienen que adoptar enfoques alternativos para las pruebas de integración. Sin embargo, una vez que el sistema se integra, el hecho de que éste se haya desarrollado como un sistema orientado a objetivos no es transparente para los usuarios del sistema.

a. Pruebas de clases de objetos.

El enfoque de la cobertura de las pruebas discutido en esta sección se refiere a asegurar que todas las instrucciones de un programa fueran ejecutados al menos una vez y que se ejecutan todas las trayectorias en el programa. Cuando se prueba completa incluye:

• Prueba aislada de todas las operaciones asociadas con el objeto;
• Las selección e interrogación de todos los atributos asociados con el objeto;
• La ejecución de los objetos en todos los estados posibles. Esto significa que simulan todos los eventos que provocan un cambio de estado en el objeto.

b. Integración de objetos.

Cuando se desarrollan sistemas orientados a objetos, los niveles de integración no son tan diferentes. Claramente las operaciones de los datos se integran para formar objetos y clase de objetos. Probar esta clase de objetos corresponde a las pruebas d unidades. No existe una equivalencia directa para la prueba de módulo en los sistemas orientados a objetos.

Ni la integración descendente ni ascendente es realmente apropiada para los sistemas orientados a objetos. En estos sistemas no existe un máximo obvio que provea una meta para integración ni existe una clara gerarquia de objetos que se pueda crear.

Existen tres posibles enfoques para las pruebas de integración que se puede utilizar:

• Pruebas de casos de uso basadas en escenario: los casos de uso o escenario describen un modo de utilización del sistema.
• Pruebas de cadenas de eventos: éstas se basan en probar la respuesta del sistema a una entrada particular o un conjunto de eventos de entrada. A menudo los sistemas orientados a objetos son conducidos por eventos por lo que esta es una forma particularmente apropiada para probar su utilización.
• Probar la interacción de los objetos:

5.4 Banco de trabajo de pruebas.

Llevar a cabo las pruebas es una fase cara y laboriosa del proceso del software. Como resultado, las herramientas de prueba estaban entre las herramientas de software a desarrollar. En la actualidad, estas herramientas ofrecen un cúmulo de recursos y su utilización reduce de forma importante el costo el proceso de pruebas. Las diversas herramientas de prueba se integran en bancos de trabajo de pruebas.

Las herramientas que se incluyen son:

• Administrador de prueba: Administra la ejecución de las pruebas del programa.
• Generador de datos de prueba: Genera los datos de prueba para el programa a probar.
• Predictor: Genera predicciones de los resultados de prueba esperados.
• Comparador de archivos: Compara los resultados de las pruebas del programa con los resultados de prueba previos y reporta las diferencias entre ellos.
• Generador de informes: Provee la definición del informe y el recurso de generación para los resultados de la prueba.
• Analizador dinámico: Agrega código a un programa para contar el número de veces que se ejecuta cada instrucción.
• Simulador: provee diferentes clases de simuladores. Los simuladores objetivos simulan la máquina sobre la que se ejecuta el programa.

6. OBJETIVOS.

1. Diseñar un modelo para pruebas de software y auditoria en el entorno Microsoft.Net que mejore los sistemas de información de la mediana empresa del sector servicio en el área metropolitana de San Salvador.

2. GENERAL.
   1. Determinar en la mediana empresa, aquellas que utilizan la herramienta Microsoft.Net a fin de proponer el desarrollo del modelo de pruebas de software y auditoria.
   2. Plantear una estrategia, que muestre los beneficios del modelo de pruebas de software y auditoria, para obtener beneficios óptimos.
   3. Dar a conocer como pueden mejorarse los sistemas de información, a través de un modelo de pruebas de software y auditoria, para adquirir la eficiencia en los sistemas de información.
   4. Identificar las áreas de la empresa que puedan ser beneficiadas con la implementación de este modelo, con el objetivo de traer un incremento en la calidad de la aplicación.
   5. Plasmar estrategias que permitan la reducción de tiempos y costos en las operaciones de la empresa, para que halla un decremento en los costos del manejo de la información.
   6. Medir la calidad que poseen los sistemas desarrollados con la herramienta de Microsoft.Net, a fin de alcanzar resultados de mayor confiabilidad.
   7. Realizar una investigación de campo que sustente el diseño de un modelo de pruebas de software y auditoria, y que siente las bases para el desarrollo de éste modelo.

3. ESPECIFICOS.

VI. HIPOTESIS.

1. ¿Si implementa un modelo de pruebas de software y auditoria en el entorno Microsoft .Net, entonces se mejora los sistemas de información de la mediana empresa del sector servicio ubicadas en el área metropolitana de San Salvador?

2. GENERAL.
   1. ¿Si se determina en la mediana empresa aquellas que utilizan la herramienta Microsoft.Net, entonces se propone el desarrollo del modelo de pruebas de software y auditoria?
   2. ¿Si se plantea una estrategia que muestre los beneficios del modelo de pruebas de software y auditoria, entonces se obtendrán beneficios óptimos?
   3. ¿Si se conoce como pueden mejorarse los sistemas de información, a través de un modelo de pruebas de software y auditoria, entonces se obtendrán eficiencia en los sistemas de información?
   4. ¿Si se identifican las áreas de la empresa que puedan ser beneficiadas con la implementación de este modelo, entonces trae consigo un incremento en la calidad de las aplicaciones?
   5. ¿Si se plasman estrategias que permitan la reducción de tiempos y costos en las operaciones de la empresa, entonces habrá un decremento en los costos del manejo de la información?
   6. ¿Si se mide la calidad que poseen los sistemas desarrollados con la herramienta de Microsoft.Net, entonces, los resultados serán de mayor confiabilidad?
   7. ¿Si se realiza una investigación de campo que sustente el diseño de un modelo de pruebas de software y auditoria, entonces tendríamos las bases para el desarrollo del modelo de pruebas de software y auditoria?
3. ESPECIFICOS.

8. OPERACIONALIZACION DE LA HIPOTESIS GENERAL

¿Si se implementa un modelo de pruebas de software y auditoria en el entorno Microsoft .Net, entonces se mejora los sistemas de información de la mediana empresa del sector servicio ubicadas en el área metropolitana de San Salvador?

Para ver el cuadro seleccione la opción "Descargar" del menú superior

VIII. PLAN DE SOLUCION (*)

Diseño de un Modelo para Pruebas de Software y auditoria en Entorno Microsoft.Net, afecta los sistemas de información de la mediana empresa del sector servicio en el área metropolitana de San Salvador.

CAPITULO I ASPECTOS GENERALES SOBRE LA MEDIANA DEDICADA A LA RAMA DE SERVICIOS.

CAPITULO II MARCO TEORICO SOBRE MODELO, INFORMATICA, SISTEMAS, AUDITORIA DE INFORMATICA, PRUEBAS DE SOFTWARE.

CAPITULO III INVESTIGACIONES DE CAMPO SOBRE LA EXISTENCIA MODELO PARA PRUEBAS DE SOFTWARE Y AUDITORIA EN ENTORNO MICROSOFT.NET, AFECTA LOS SISTEMAS DE INFORMACIÓN DE LA MEDIANA EMPRESA DEL SECTOR SERVICIO EN EL ÁREA METROPOLITANA DE SAN SALVADOR.

CAPITULO IV Diseño Modelo para Pruebas de Software y auditoria en Entorno Microsoft.Net, afecta los sistemas de información de la mediana empresa del sector servicio en el área metropolitana de San Salvador

IX. DESCRIPCION CAPITULAR (*)

CAPITULO I ASPECTOS GENERALES SOBRE LA MEDIANA DEDICADA AL SECTOR SERVICIO.

CAPITULO II MARCO TEORICO SOBRE MODELO, INFORMATICA, SIATEMA, AUDITORIA DE SOFTWARE Y PRUEBAS DE SOFTWARE.

CAPITULO III INVESTIGACIONES DE CAMPO SOBRE LA EXISTENCIA DE UN MODELO DE PRUEBAS Y AUDITORIAS DE SOFTWARE EN EL ENTORNO MICROSOFT.NET EN LAS MEDIANAS EMPRESAS DE EL SECTRO SERVICIO DEL DEPARTAMENTO DE SAN SALVADOR.

CAPITULO IV DISEÑO DE UN MODELO DE PRUEBAS Y AUDITORIA DE SOFTWARE EN UN ENTRONO MICROSOFT.NET APLICADO A LAS MEDIANAS EMPRESAS DEL SECTRO SERVICIO UBICADAS EN EL DEPARTAMENTO DE SAN SALVADOR.

X. METODOLOGÍA DE LA INVESTIGACIÓN (*)

XI. PRESUPUESTO DE TESIS. (*)

XIII. BIBLIOGRAFÍA (*)

 (*)Para ver el texto completo seleccione la opción "Descargar trabajo" del menú superior

Manuel Alexander Calderón Hernández

El Salvador