Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

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




Enviado por alexcal2004



Partes: 1, 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.

  1. 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:

  1. 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.

  2. 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.

  3. Documentación
  4. 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

Profesión

Actividades y conocimientos
deseables

Informático Generalista

Con experiencia amplia en ramas distintas.
Deseable que su labor se haya desarrollado en
Explotación y en Desarrollo de Proyectos.
Conocedor de Sistemas.

Experto en Desarrollo de Proyectos

Amplia experiencia como responsable de
proyectos. Experto analista. Conocedor de las
metodologías de Desarrollo más
importantes.

Técnico de Sistemas

Experto en Sistemas
Operativos y Software Básico. Conocedor de los
productos equivalentes en el mercado. Amplios conocimientos de
Explotación.

Experto en Bases de Datos y
Administración de las mismas.

Con experiencia en el mantenimiento de Bases de
Datos. Conocimiento de productos compatibles y
equivalentes. Buenos conocimientos de
explotación

Experto en Software de
Comunicación

Alta especialización dentro de la
técnica de sistemas. Conocimientos profundos de
redes. Muy experto en Subsistemas de
teleproceso.

Experto en Explotación y Gestión
de CPD´S

Responsable de algún Centro de Cálculo. Amplia experiencia en
Automatización de trabajos. Experto
en relaciones
humanas. Buenos conocimientos de los
sistemas.

Técnico de Organización

Experto organizador y coordinador. Especialista
en el análisis de flujos de
información.

Técnico de evaluación de
Costes

Economista con conocimiento de
Informática. Gestión de costes.

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:

  1. 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.
  2. Tendencias. Se tratarán de hallar
    parámetros que permitan establecer tendencias
    futuras.
  3. Puntos débiles y amenazas.
  4. Recomendaciones y planes de acción.
    Constituyen junto con la exposición de puntos débiles, el
    verdadero objetivo de la auditoria
    informática.
  5. 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.

  1. 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".
  1. 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.
  1. 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.
  1. 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

Partes: 1, 2
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter