Beruflich Dokumente
Kultur Dokumente
El Objetivo de esta revisin es identificar, analizar y evaluar los requerimientos del usuario, riesgos, exposiciones a ellos
y los controles en aplicaciones especficas durante la fase de desarrollo, adquisicin o mantenimiento de las
aplicaciones. Las tareas del auditor de sistemas incluyen las siguientes:
Determinar los componentes, objetivos y requerimientos principales de los usuarios de la aplicacin e identificar
las reas que exigen controles al hacer entrevistas con miembros claves del proyecto.
Determinar y clasificar los principales riesgos y exposicin a riesgos de la aplicacin, para permitir controles por
medio de discusiones con miembros del equipo del proyecto.
Identificar los controles para minimizar los riesgos y exposiciones a riesgos de la aplicacin por referencia a
fuentes confiables y por medio de discusiones con miembros del equipo del proyecto.
Asesorar al equipo del proyecto respecto del diseo de la aplicacin y la implantacin de controles al evaluar
los controles disponibles y al participar en discusiones con miembros del equipo del proyecto.
Monitorear el proceso de desarrollo, mantenimiento o adquisicin de las aplicaciones para asegurarse de que
se implantan los controles, se satisfacen los requerimientos de los usuarios y se sigue la metodologa mas
adecuada en cada caso, esto permite asegurarse que las aplicaciones son eficaces y eficientes, al realizar
reuniones peridicas con miembros del equipo del proyecto y al hacer exmenes de la documentacin y los
productos en sus diversas etapas.
comprobar que sean apropiados. Entrevistar a los usuarios clave del sistema para comprobar su
comprensin de cmo operar el sistema y evaluar su nivel de entrada en el diseo de los formatos de
pantalla y los informes de salida. Evaluar los rastros de auditora que se programan, en el sistema para
rastrear la informacin fuente clave. Verificar la correccin de los clculos de los procesos claves.
Verificar que el sistema puede identificar y procesar correctamente datos errneos. Verificar que los
procesos de prueba de los programas sean desarrollados durante esta fase. Verificar que se hicieron
las correcciones recomendadas para los errores de programacin y que las pistas de auditora
recomendados o los mdulos de auditora fueron incorporadas en los programas correctos.
4. Fase de Prueba. La fase de prueba es crucial para determinar que los requerimientos han sido
satisfechos y que el sistema se comporta como se anticipaba. Por ende el auditor de sistemas debe
participar en forma intensa y revisar la fase. Examinar el plan de prueba, para verificar que sea
completo con la evidencia indicada de la participacin del usuario, tal como escenario de situaciones de
prueba creados por los usuarios y/o aprobacin escrita de aceptacin de los resultados. Revisar todos
los resultados de pruebas en paralelo para comprobar su exactitud. Verificar que la seguridad este
funcionando adecuadamente, probando intentos de acceso no permitidos. Examinar comprobando la
precisin de los mensajes de error para reconocer los datos errneos y la resolucin de estos errores.
5. Implantacin. Esta fase se inicia solo despus de una exitosa fase de prueba. Debe tenerse precaucin
al transferir un nuevo sistema a situacin de produccin. El auditor de sistemas debe verificar que las
aprobaciones necesarias existen antes de implementar el nuevo sistema. Revisar los procedimientos
programados que se utilizan para hacer el cronograma y correr el sistema junto con los parmetros del
sistema que se utilizan al ejecutar el cronograma de actividades. Revisar la documentacin del sistema
a fin de asegurarse de que esta completo y que todas las actualizaciones posteriores a la fase de
prueba han sido incorporadas. Verificar toda la conversin de datos para asegurarse de que es correcta
y esta completa antes de implementar en produccin al nuevo sistema.
6. Fase de Post-Implantacin. Luego que el nuevo sistema ha estado operando, por lo menos seis meses,
el auditor de sistemas independiente de las otras fases de la vida del sistema, revisar lo siguiente:
Determinar si el programa ha logrado los requerimientos de los objetivos, se debe prestar especial
atencin a la utilizacin y la satisfaccin de los usuarios finales, ellos constituirn un indicador
excelente. Verificar que se miden, analizan e informan adecuadamente a la gerencia los beneficios
identificados con el estudio de factibilidad. Revisar las solicitudes de cambios a los programas que se
han realizado, para evaluar el tipo de cambios que se exigen al sistema, el tipo de cambios puede
indicar problemas de diseo, programacin o interpretacin de los requerimientos de usuario.
b. Revisin de aplicaciones de software comprado.
Para tomar la decisin de comprar el producto de un vendedor en lugar de crear una solucin interna, debe existir en el
estudio de factibilidad, documentacin sobre la decisin de "hacer vs. Comprar", esta documentacin debe ser
analizada para determinar si la decisin de comprar fue apropiada. y considerar lo siguiente respecto a los
proveedores: Estabilidad financiera. Nmero de aos de experiencia ofreciendo el producto. Nmero de sedes de
clientes que usen el servicio. Compromiso de servicio. Compromiso de desarrollar o mejorar el producto. Nivel de
satisfaccin de otros clientes, si es posible visitar sus instalaciones y ver como se utiliza en un ambiente real de
produccin. Compromiso para la provisin de entrenamiento, documentacin y upgrades a los productos. Aceptacin de
pruebas de productos antes de la compra. Adicionalmente el auditor de sistemas deber revisar el contrato en los
siguientes puntos: Descripcin especfica de los productos a entregar. Compromisos sobre fechas de entrega de los
productos. Compromiso de entrega de los upgrades y entrenamiento. Entregas de licencias y permisos para copiar el
software para utilizarlo en esfuerzos de recuperacin de desastres.
c.
El objetivo de esta revisin es identificar, analizar y evaluar normas, tareas, procedimientos y controles en el proceso de
control de cambios a los programas. Las tareas de auditora en este aspecto son:
Evaluar los estndares y procedimientos para cambios a programas para asegurar su adecuacin por
medio de examen de la correspondiente documentacin, discusiones con personal clave y
observaciones.
Probar los procedimientos de control de cambios para asegurar que se explican segn se describe en
los estndares por medio de discusin y examen de los registros respaldatorios.
Evaluar el proceso de control de cambios para determinar que los objetivos de control fueron cumplidos
al analizar los resultados de pruebas y otra evidencia de auditora.
Desde que un sistema es puesto en funcionamiento, se practican cambios, los cuales deben tener en cuenta una
metodologa para realizar y registrar estos cambios, esta metodologa debe incluir:
Rastros de auditora de cambios, siempre debe llevarse un rastro de auditora de todos los cambios o
manejo de versiones de los programas, esto generalmente lo posee el software de manejo de
bibliotecas.
Concordancia del cdigo fuente y el ejecutable, se refiere a que si un programa fuente es compilado
nuevamente, el programa ejecutable resultante es igual al programa que esta en produccin.
Controles de acceso a los programas de produccin, debe existir un riguroso control de acceso a los
programas de produccin, estos controles generalmente son manejados por el software de acceso al
mainframe.
intento por entender y racionalizar la administracin de la tecnologa dentro de las organizaciones. Los sistemas de
informacin han madurado hasta convertirse en un campo de estudios superiores dentro de la administracin. La idea
fundamentalmente proviene de:
 La necesidad del usuario de una herramienta que le facilite el acceso a la informacin.
 La necesidad del administrador para el control de sus recursos.
 La necesidad del auditor para llevar a cabo su funcin de asesora o consultora para ver si la
administracin ha sido eficiente.
 La necesidad de terceras partes (clientes, proveedores, entidades gubernamentales, entidades financieras
etc.)
1. Factibilidad Tcnica. El trabajo para el proyecto, puede realizarse en el equipo actual, la tecnologa existente del
software y el personal disponible? Si se necesita nueva tecnologa cul es la posibilidad de desarrollarla?
2. Factibilidad Econmica. Que los beneficios (tangibles e intangibles) y horros superen a los costos; que los ndices
financieros que se calculen sean aceptables, de acuerdo con polticas y estndares generales y especficos; que el
proyecto tenga contenido econmico y est contemplado en el presupuesto respectivo.
Como mnimo deben calcularse las siguientes razones:
a. Tasa Interna de Retorno.
b. Valor Neto Presente.
c. Perodo de Recuperacin.
d. Y, el total de los beneficios netos.
Dependiendo de los resultados de este estudio se determinar si se contina o no con el proyecto.
3. Factibilidad Operacional. Si se desarrolla e implanta, ser utilizado el sistema?, existir cierta resistencia al
cambio por parte de los usuarios que de cmo resultado una disminucin de los posibles beneficios de la aplicacin?
El estudio de factibilidad lo lleva a cabo un pequeo equipo de personas (en ocasiones una o dos) que est
familiarizado con tcnicas de sistemas de informacin; dicho equipo comprende la parte de la empresa u organizacin
que participar se ver afectada por el proyecto y es gente experta en los procesos de anlisis y diseo de sistemas.
En general, las personas que son responsables de evaluar la factibilidad son anlisis capacitados o directivos.
2. ANLISIS DE SISTEMAS
El aspecto fundamental del anlisis de sistemas es comprender todas las facetas importantes de la parte de la
empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben
estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas:
1. Qu es lo que hace?
2. Cmo se hace?
3. Con qu frecuencia se presenta?
4. Qu tan grande es el volumen de transacciones o de decisiones?
5. Cul es el grado de eficiencia con el que se efectan las tareas?
6. Existe algn problema?
7. Si existe un problema. Qu tan serio es?
8. Si existe un problema. Cul es la causa de lo que origina?
Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los
procesos de la empresa, sus opiniones sobre porque ocurren las cosas, las soluciones que proponen y sus ideas para
cambiar el proceso. Se emplea cuestionarios para obtener esta informacin cuando no es posible entrevistar, en
forma personal, a los miembros de grupos grandes dentro de la organizacin.
As mismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin en condiciones
reales de las actividades de trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de
comprender el proceso en su totalidad.
Conforme se renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar
las caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas junto
con caractersticas operacionales tales como controles de procesamiento, tiempos de respuesta y mtodos de
entrada y salida.
3. DISEO DEL SISTEMA.
El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir
con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con
frecuencia, a esta etapa como diseo lgico en contraste con la de desarrollo del software, a la que denominan
diseo fsico. Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y dems salidas
que debe producir el sistema. Hecho lo anterior se determinan con toda precisin los datos especficos para cada
reporte y salida. Es comn que los diseadores hagan un bosquejo del formato o pantalla que esperan que aparezca
cuando el sistema est terminado. Lo anterior se efecta en papel o en la pantalla de una terminal utilizando para ello
algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas.
Los documentos que contienen las especificaciones de diseo representan a ste de muchas maneras (diagramas,
tablas y smbolos especiales). La informacin detallada del diseo se proporciona al equipo de programacin para
comenzar la fase de desarrollo de software .
Los diseadores son los responsables de dar a los programadores las especificaciones de software completas y
claramente delineadas. Una vez comenzada la fase de programacin, los diseadores contestan preguntas, aclaran
dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseo
Fases del Diseo:
 Eleccin de una solucin de diseo entre las soluciones candidatas..
 Evaluacin del hardware y software requeridos
 Diseo e Integracin del nuevo sistema
1. Evaluacin operacional: Valoracin de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo
de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin.
2. Impacto organizacional: Identificacin y medicin de los beneficios para la organizacin en reas tales como
finanzas, eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin
externo e interno.
3. Opinin de loa administradores: evaluacin de las actividades de directivos y administradores dentro de la
organizacin as como de los usuarios finales.
4. Desempeo del desarrollo: La evaluacin de proceso de desarrollo de acuerdo con criterios tales como tiempo y
esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos.
Tambin se incluye la valoracin de los mtodos y herramientas utilizados en el desarrollo.
Desafortunadamente la evaluacin de sistemas no siempre recibe la atencin que merece. Sin embargo, cuando se
conduce en forma adecuada proporciona mucha informacin que puede ayudar a mejorar la efectividad de los
esfuerzos de desarrollo de aplicaciones subsecuentes.
Un plan de pruebas permite especificar lo que desea probar y cmo ejecutar dichas pruebas. Un plan de pruebas se
puede aplicar a una iteracin concreta de su proyecto. Puede tener solo un conjunto de pruebas predeterminado para
sus casos de prueba o puede crear una jerarqua de conjuntos de pruebas.
El Plan de Pruebas de Aceptacin describe los pasos que se deben seguir para verificar que el sistema construido
satisface los requerimientos.
El Plan de Pruebas de Aceptacin es uno de los planes de prueba detallados y corresponde al nivel de pruebas de
aceptacin del sistema o de la solucin. Este plan describe clara y completamente como realizar las pruebas.
Las pruebas de aceptacin, involucran al usuario final y pretenden comprobar que la solucin cumple con el modelo de
negocio para el que fue desarrollado. Deteccin de defectos del producto entregado y planes de accin para correccin
de los mismos.