Integrantes:

Profesora : Rosangelis Mijares CI: 27.928.270

Yormis Pérez Omar Veliz CI: 27.928.446
IF01 T4-F2 Jesús Viva CI: 28.095.352
Marilyn Paul CI: 27.992.899
Contenido de Unidad 4: Metodología para realizar auditorías informáticas
Planificación de la auditoria informática, Pruebas.
Es el proceso que sigue una serie de pasos previos que permitirán dimensionar el
tamaño y características del área dentro del organismo a auditar, sus sistemas,
organización y equipo. Determinar el número y características del personal de auditoría,
las herramientas necesarias, el tiempo y costo, así como definir los alcances de la
auditoría para, en caso necesario, poder elaborar el contrato de servicios.

Definición de pruebas, Pasos para realizar las pruebas, Tipos datos de prueba.
La prueba
Es una de las fases más importantes del ciclo de vida de desarrollo del software.

La prueba es el proceso de ejecutar un programa con la intención de descubrir

defectos en el programa. La fase de prueba ocurre en la penúltima etapa, es decir
después de la fase de programación pero antes de la fase de implantación del
programa.La fase de prueba se debe realizar de la manera más robusta y eficiente.

Definición de pruebas:
El equipo de auditoría debe realizar pruebas para verificar la consistencia de los
controles existentes o bien para medir el riesgo existente. Toda opinión o evaluación de
un auditor debe estar basada en pruebas realizadas de acuerdo con mina normativa
profesional. Las pruebas pueden ser de cumplimiento, que se utilizan para comprobar si
el riesgo potencial es real.

Pasos para realizar las pruebas.

Estas especificaciones son cruciales a la hora de diseñar las pruebas de

verificación. Note que el diseño de estas pruebas requiere los siguientes pasos:

1. Revisar la verificabilidad del requerimiento;

2. Especificar el criterio de verificación;
3. Hacer visible las propiedades o elementos del software necesarios para verificar
el cumplimiento del requerimiento;
4. Hacer controlable los elementos del software necesarios para llevar a cabo las
pruebas;
5. Elaborar el plan de pruebas;
6. Ejecutar el plan de pruebas y reportar sus resultados.
Tipos datos de prueba.
 Análisis de requerimientos: Pruebas de sistema, pruebas de verificación (de
requerimientos)
 Diseño: Pruebas de integración, pruebas de subsistema.
 Codificación: Pruebas unitarias
Tipos de pruebas
• Pruebas unitarias
• Pruebas funcionales
• Pruebas de Integración
• Pruebas de validación
• Pruebas de sistema
• Caja blanca (sistemas)
• Caja negra (sistemas)
• Pruebas de aceptación
• Pruebas de regresión
• Pruebas de carga
• Pruebas de prestaciones
• Pruebas de recorrido
• Pruebas de mutación

Tipos de pruebas:
 pruebas altas
 Prueba de enlace También se le conoce como prueba en cadena.
La prueba de enlace revisa para ver si los programas que son interdependientes
trabajan, de hecho, como se planeó. Una pequeña cantidad de datos de prueba, para
probar las especificaciones del sistema, así como los programas, se usan para la prueba
de enlace. La prueba de todas las combinaciones puede llevarse varios pasos a través del
sistema, debido a que es mucho muy difícil describir los problemas si se trata de probar
todo en una sola vez.

El analista crea datos de prueba especiales que cubren una diversidad de

situaciones de procesamiento para la prueba de enlace. Primero, se procesan datos de
prueba típicos para ver si el sistema puede trabajar las transacciones normales, aquellas
que conformarán la mayor parte de su carga. Si el sistema trabaja con las transacciones
normales, luego se añaden variaciones, incluyendo los datos inválidos usados para
asegurarse de que el sistema pueda detectar errores adecuadamente.

 Prueba de aceptación.
La prueba de aceptación se relaciona y define la aceptación formal de un
producto acabado. Comprueba si el producto satisface los requerimientos originales del
negocio. Es realizado por los representantes del negocio, usando los documentos
originales de los requerimientos como referencias y no por el personal técnico.

Estas pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el
sistema completo, y buscan una cobertura de la especificación de requisitos y del
manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sería
impresentable de cara al cliente; sino una vez pasada todas las pruebas de integración
por parte del desarrollador.

 Prueba de caja blanca

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

Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que

hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las
expresiones lógico-aritméticas, pruebas de camino de datos (definiciónuso de variables),
comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para
las iteraciones máximas, máximas menos uno y más uno. Las pruebas de caja blanca se
llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja
negra sobre varios subsistemas (integración).

En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a
los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a
otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de
una clase suelen ser menos complejos que los de una función de programación
estructurada).
 Prueba de caja negra.
Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista
de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su
funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de
interactuar con el medio que le rodea (en ocasiones, otros elementos que también
podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a
cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas
y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles
internos de su funcionamiento.

Un sistema formado por módulos que cumplan las características de caja negra
será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El
sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste
podrá ser aislado y abordado más ágilmente.

En programación modular, donde un programa (o un algoritmo) es divido en

módulos, en la fase de diseño se buscará que cada módulo sea una caja negra dentro del
sistema global que es el programa que se pretende desarrollar, de esta manera se
consigue una independencia entre los módulos que facilita su implementación separada
por un equipo de trabajo donde cada miembro va a encargarse de implementar una parte
(un módulo) del programa global; el implementador de un módulo concreto deberá
conocer como es la comunicación con los otros módulos (la interfaz), pero no necesitará
conocer cómo trabajan esos otros módulos internamente; en otras palabras, para el
desarrollador de un módulo, idealmente, el resto de módulos serán cajas negras.

En pruebas de software, conociendo una función específica para la que

fue diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función
está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es
decir, de la función, actuando sobre ella como una caja negra, proporcionando unas
entradas y estudiando las salidas para ver si son o no las esperadas. También conocida
como prueba funcional, permite descubrir fallas tales como:

o Funciones errónea o faltante

o Errores de interfaz
o Errores de estructuras de datos y base de datos
o Errores de inicialización y finalización
o Errores en el desempeño Prueba de sensibilidad.
 Prueba de avance.
 Prueba en paralelo Las pruebas en paralelo tienen como propósito probar durante
un período mínimo de quince (15) días calendario el sistema de información que
contenga las funcionalidades exigibles para la primera etapa de la Fase de
Construcción del RUNT y contrastar los resultados con los de la operación
generada por los Organismos de Tránsito, por las Direcciones Territoriales del
Ministerio y por los Otros Actores en sus actuales esquemas.

 Prueba ascendente y descendente. La estrategia 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 esté 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.
 EVALUACIÓN DEL PROCESAMIENTO DE DATOS A NIVEL
ORGANIZACIÓN:
 Duplicidad de datos
 Clasificación e identidad de los datos
 Relación de los datos
 Responsabilidad de los datos

CONTROLES: Prevenir o detectar errores accidentales que puedan ocurrir en el

Centro de Cómputo durante un proceso.

1. Evitar o detectar el manejo de datos con fines fraudulentos por parte de

funcionarios Garantizar la integridad de los recursos informáticos.
2. Asegurar la utilización adecuada de equipos acorde a planes y objetivos.

Controles: Una vez conseguida la Operatividad de los Sistemas, el segundo objetivo de

la auditoría es la verificación de la observancia de las normas teóricamente existentes
en el departamento de Informática y su coherencia con las del resto de la empresa. Para
ello, habrán de revisarse sucesivamente y en este orden:

1. -Las Normas Generales de la Instalación Informática. Se realizará una revisión

inicial sin estudiar a fondo las contradicciones que pudieran existir, pero registrando las
áreas que carezcan de normativa, y sobre todo verificando que esta Normativa General
Informática no está en contradicción con alguna Norma General no informática de la
empresa.

2-.Los Procedimientos Generales Informáticos. Se verificará su existencia, al menos en

los sectores más importantes. Por ejemplo, la recepción definitiva de las máquinas
debería estar firmada por los responsables de Explotación. Tampoco el alta de una
nueva Aplicación Podría producirse si no existieran los Procedimientos de Backup y
Recuperación correspondientes.

3.-Los Procedimientos Específicos Informáticos. Igualmente, se revisara su existencia

en las áreas fundamentales. Así, Explotación no debería explotar una Aplicación sin
haber exigido a Desarrollo la pertinente documentación. Del mismo modo, deberá
comprobarse que los Procedimientos Específicos no se opongan a los Procedimientos
Generales. En todos los casos anteriores, a su vez, deberá verificarse que no existe
contradicción alguna con la Normativa y los Procedimientos Generales de la propia
empresa, a los que la Informática debe estar sometida.

ORGANIZACIÓN EN EL CENTRO DE CÓMPUTO:

Esta etapa del proceso administrativo encargada de coordinar y ordenar los recursos y
tareas del centro de cómputo con el fin de facilitar el logro de objetivos, para que estos
tengan significado y contribuyan a la eficiencia organizacional.

PRINCIPALES DEPARTAMENTOS:

1. Producción y control: verifica que los programas o sistemas que producen en el

departamento de sistema de cómputo estén correctamente estructurados. Operación:
opera y manipula el sistema, los datos del mismo, y el equipo con que cuenta la
empresa; en otras palabras el software y hardware
2. Administración de sistemas: administra los suplementos del software, dotar o
instalar en cada departamento del centro de cómputo, los requerimientos que para
un buen desempeño sean necesarios.
3. Programación: capturar, codificar y diseñar los programas, sistemas, base de datos.
Soporte: verificar que el software y hardware funcionen correctamente y en caso de
que se localice algún error, deberán repararlo. Implementación: implementar el
software necesario de manera que cada área del centro de cómputo se le destine el
material que requiere para el buen desempeño de sus funciones de la empresa.

PLANEACIÓN ESTRATÉGICA PARA QUE TENGA EXITO

En todo centro de cómputo existen varias variables para su planeación estratégica

y es que todo el centro de cómputo debe haber áreas de trabajo para cada una de las
funciones que se realizan de entre las cuales podemos mencionar. Supervisor de red área
de programación área de captura operadores de cómputo analista de sistemas
programador capturista de datos operador de computadora
PLANEACIÓN OPERATIVA

En esta etapa el administrador de centros de cómputo debe seleccionar al personal

de cómputo que se requiere para la operación del centro de sistemas de acuerdo con el
perfil profesional.

PLANEACION DE INSTALACIONES FISICAS

Se refiere a todo lo que tiene que ver con el equipo que debe de utilizar y debe
estar contenido en el centro de cómputo. Conexión No break Reguladores Aire
acondicionado y Extinguidores.

Evaluación de la configuración del sistema de cómputo, productividad.

Los objetivos son evaluar la configuración actual tomando en consideración las

aplicaciones y el nivel de uso de sistema.

Productividad: La tecnología debería jugar un papel fundamental en el esfuerzo

necesario para aumentar la productividad, ya que permitiría abaratar la producción de
bienes y la oferta de servicios.
Caso Práctico: Auditoria Informática a la Cooperativa de Producción Social.
Auditoria de la Cooperativa C.E.P.C
El (C.E.P.C) Es una empresa mixta registrada como Empresa de Producción
Social (E.P.S) dedicada a formar Jóvenes en las áreas de Mecánica Soldadura,
Electricidad, Computación, Electrónica, Refrigeración, Médica, administrativa y
Seguridad Social entre otras. En la cual se forman jóvenes capacitados para elaborar en
cualquier área de trabajo.

La empresa tiene como objetivo extender su programa a nivel Nacional e

Internacional y también a un nivel universitario, evaluando así las condiciones socios
culturales, Económicos de los diferentes sectores de la zona.

Motivos de la Auditoria
Debido a la necesidad por parte del (C.E.P.C) de contar con un sistema de
información capaz de transformar de manera positiva el modo en el anteriormente se
manejaban las actividades laborales, surge la necesidad de que dicho sistema sea
evaluado para emitir un diagnóstico, ya que en la actualidad esa información
almacenada es muy importante, y así poder identificar las debilidades para reportar la
existencia de riesgos que requieran prevención

Alcance: Realizar Auditoria Informática Propuesta en este proyecto, se realizó sobre el

Sistema de Información para la gestión Administrativa.

PLAN A EJECUTAR
En la planificación y desarrollo de nuestra auditoria consideramos el control
interno de la cooperativa (C.E.P.C), para determinar los procedimientos de auditoria que
nos permitieron expresar una opinión sobre todo el sistema que es llevado, de manera
tal se procedió a recopilar toda la información, tomando en cuenta el registro de los
usuarios, el manejo con respecto a los insumos, el tiempo de respuesta, los costos del
mismo, los recursos tanto financieros, como humanos, Y como era almacenada toda la
información.

Por lo que se requiere conformación de equipo de asesores, y personal necesario

para el cumplimiento de los objetivos propuestos, con el fin de orientar las estrategias
que se utilizaran para el desarrollo del Sistema Administrativo.
 Se necesitará, un programador cuyo perfil debe estar orientado al conocimiento
neto en ambiente no solo informático, sino además en el área de programación. Así
como un personal responsable del proyecto, que esté disponible para dirigir y coordinar
las actividades.

RECOMENDACIONES
Para solventar las fallas encontradas, y hacer que el sistema sea efectivo para
todos los procesos del área se propone lo siguiente:

A. Actualización de los equipos informáticos, para que los mismos soporten

los cambios propuestos en el Sistema de Informacion.
B. Restructurar la base de Datos con el fin de incorporar una estructura
relacional, que permita un registro adecuado de los datos prácticos.