AUDITORIA INFORMÁTICA DE DESARROLLO DE PROYECTOS O

APLICACIONES

En la Auditoria informática es objeto frecuente el área de Desarrollo de Proyectos

o de Aplicaciones.

La función de desarrollo es una evolución del llamado análisis y programación

de sistemas y aplicaciones.

A su vez, engloba muchas áreas, tantas como sectores tiene la empresa. Entre
las más comunes:

• Animaciones del Usuario y del entorno.

• Análisis funcional.

• Diseño.

• Análisis orgánico (Pre-programación y Programación).

• Pruebas.

• Entrega a Explotación y alta para el Proceso.

El desarrollo de un software debe estar sometido a un exhaustivo control de

cada una de sus fases, ya que en caso contrario, además del habitual disparo
de los costes, podría producirse una total insatisfacción del usuario si
finalmente no cumple las funcionalidades necesarias así como la ergonomía
de los interfaces de la misma.

Además, la auditoría deberá comprobar la seguridad del software

desarrollado al objeto de garantizar que el resultado de su ejecución sea
exactamente el previsto, y que no interfiere con el resto de aplicaciones de la
empresa.

Una auditoria de Aplicaciones pasa indefectiblemente por la observación y el

análisis de cuatro consideraciones:

• Revisión de las metodologías utilizadas

• Control interno de las aplicaciones

• Satisfacción de usuarios
 • Control de procesos y ejecuciones de programas críticos.

Revisión de las metodologías utilizadas:

Se analizaran éstas, de modo que se asegure la modularidad de las posibles

futuras ampliaciones de la Aplicación y el fácil mantenimiento de las mismas.

Control interno de las aplicaciones:

Se deberán revisar las mismas fases que presuntamente han debido seguir el
área correspondiente de Desarrollo:

1. Estudio de Vialidad de la Aplicación.

2. Diseño de Programas.

3. Definición Lógica de la Aplicación.

4. Métodos de Pruebas.

5. Desarrollo Técnico de la Aplicación.

6. Documentación.

7. Equipo de Programación

8. Estudio de Aptitud de la Aplicación. (Muy determinante para Aplicaciones

complejas, largas y caras).
9. Definición lógica de la Aplicación. (Se examinará que se han completado
los propósitos lógicos de actuación, en función de la metodología elegida
y la finalidad del proyecto).
10. Desarrollo Técnico de la Aplicación. (Se verificará que éste es ordenado
y correcto. Las herramientas técnicas utilizadas en los diversos
programas deberán ser compatibles entre sí, y a ser posible con las ya
existentes en el sistema de la empresa).
11. Diseño de Algoritmos. (Deberán poseer la máxima sencillez, modularidad
y economía de recursos).
12. Metodología de Ensayos. (Se realizaran de acuerdo a las Normas de la
Instalación. Se realizarán juegos de ensayo de datos, sin que se permita
en ningún caso el uso de datos reales).
 13. Documentación de la Aplicación. (Cumplirá la Normativa establecida en la
Instalación, tanto la de Desarrollo como la de su puesta a Explotación).
14. Recursos Humanos Utilizados. (Deben fijarse las tareas de análisis puro,
de programación y las intermedias para cada elemento que constituye
el grupo de desarrollo. En Aplicaciones complejas se recomienda
variaciones en la composición del mismo, pero estos deberán estar
siempre previstos en la planificación inicial).
Satisfacción de usuarios:

Una Aplicación técnicamente eficiente y bien desarrollada, deberá

considerarse fracasada si no sirve a los intereses del usuario que la solicitó.
La aquiescencia del usuario proporciona grandes ventajas posteriores, ya
que evitará reprogramaciones y disminuirá el mantenimiento de la Aplicación.
Una Aplicación técnicamente eficiente y bien desarrollada, deberá
considerarse una pérdida si no sirve a los intereses del usuario que la solicitó,
o resulta ergonómicamente insuficiente. La aprobación del usuario
proporciona grandes ventajas posteriores, ya que evitará reprogramaciones
y disminuirá el mantenimiento posterior de la Aplicación.

Control de procesos y ejecuciones de programas críticos:

El auditor no debe descartar la posibilidad de que se esté ejecutando un módulo

que no se corresponde con el programa fuente que se desarrolló, codificó y probó
el grupo de Desarrollo de la Aplicación. Se ha de comprobar la correspondencia
biunívoca y exclusiva entre el programa codificado y su compilación. Si los
programas fuente y los programas módulo no coincidieran se podría provocar,
desde errores de bulto (bugs) que producirían graves y altos costes de
mantenimiento, hasta fraudes, pasando por acciones de sabotaje, espionaje
industrial/informativo, etc. Por ende, hay normas muy rígidas en cuanto a las
Librerías de programas; aquellos programas fuente que hayan sido dados por
bueno por Desarrollo, son entregados a Explotación con el fin de que éste:

 Copie el programa fuente en la Librería de Fuentes de Explotación, a la que nadie

más tiene acceso.

 Compile y monte el Programa, depositándolo en la Librería de Módulos de

Explotación, a la que nadie más tiene acceso.
 Copie los programas fuente que les sean solicitados para modificarlos,
arreglarlos, etc. en el lugar que se le indique. Cualquier cambio exigirá pasar de
nuevo por el punto 1.

El sistema para auditar y dar de alta un nuevo Desarrollo es bastante arduo y

complejo, por ello muchas empresas se apoyan en profesionales y en
la auditoría externa como mejor método para la confirmación de que el
Desarrollo cumple con todas las expectativas y fases expuestas.