AUDITORA INFORMTICA

C o n t e n i d o
1. Control interno y auditora. 2. Impacto de la informtica en la organizacin y en la auditora. 3. Auditora a la unidad de informtica. 4. Tcnicas para auditar

aplicaciones computarizadas.
5. Auditora del desarrollo.

1.El control interno y la auditora

El Control Interno
Qu es el Control Interno ?
Conjunto de mtodos, procedimientos y planes de la organizacin que en forma conjunta se llevan a cabo para verificar la confiabilidad y exactitud de la informacin, salvaguardar los activos, hacer que se cumplan las polticas establecidas y promover la eficiencia operacional.

El Control Interno
Los Objetivos de Control Interno incluyen: 1. La proteccin de activos 2. El cumplimiento de las polticas establecidas y los requerimientos legales

3.

Cumplimiento de Autorizaciones requeridas

4. Proceso de transacciones exacto y completo 5. Control de Salidas (Outputs) 6. Confiabilidad del Proceso 7. Procedimientos de Respaldo y Recuperacin 8. La obtencin de informacin veraz y oportuna 9. Promocin de la Eficiencia y Economa Operacional

El Control Interno
Ejemplos de Objetivos de Control relacionados con la informacin en Sistemas Automatizados: 1. La informacin en Sistemas automatizados, debe ser protegida contra accesos no apropiados y estar actualizada. (preventiva) 2. Toda transaccin debe ser autorizada e introducida al sistema una sola vez. (detectiva)

3. Todas las transacciones deben ser registradas e

introducidas al sistema de cmputo para el perodo apropiado. (peventiva)

4. Todas las transacciones rechazadas deben ser reportadas. (detectiva) 5. Las transacciones duplicadas deben ser reportadas. (detectiva) 6.Los archivos y Bases de Datos deben ser respaldados adecuadamente para permitir su apropiada recuperacin.

(correctiva)
7. Todos los cambios al Software Operativo deben ser aprobados y probados. (preventiva)

La Auditora
Definiciones de Auditora
1. EXAMEN CRTICO Y SISTEMTICO de: - Direccin Interna - Estados y operaciones contables - Documentos jurdicos y financieros para cerciorarse de la exactitud, integridad y autenticidad de los estados y operaciones. 2. INVESTIGACIN CRTICA para llegar a conclusiones ciertas sobre la contabilizacin de aspectos financieros y operaciones de una organizacin

3. REVISION ANALITICA del Control Interno y registros contables de una empresa, que precede al Informe del Auditor, acerca de la veracidad de Estados Financieros. 4. Actividad profesional que en base a procedimientos y tcnicas realiza REVISIONES Y EVALUACIONES. 5. REVISION DE CUALQUIER ACTIVIDAD SUSCEPTIBLE DE CONTROL

La Auditora
Objetivos de la Auditora
1. Mejorar la situacin de la empresa.

2. Sugerir mejoras (en controles, procedimientos etc.).

3. Detectar fallas. 4. Reunir elementos para la Toma de Decisiones. 5. Reducir los riesgos. 6. Retroalimentar oportunamente. 7. Optimizar el uso de recursos. 8. Analizar imparcialmente las funciones. 9. Estandarizar.

La Auditora
El papel de la Auditora
Revisin y Evaluacin de los sistemas para determinar

Mejor informacin

Desperdicios y deficiencias

Mejor control

Operacin ms eficaz

Mejor uso de los recursos

La Auditora
Por quien la realiza Interna Externa Financiera Operacional Administrativa Crdito Informtica Permanente Espordica Exhaustiva Selectiva

Tipos de Auditora

Por el tipo de resultado

Por su periodo

Por su alcance

La Auditora
El Ciclo de la Auditora
1. 2. 3. Seleccin del rea a auditar. Establecimiento de Objetivos. Elaboracin del Programa de Trabajo.

Planeacin de actividades
Asignacin de recursos 4. 5. 6. 7. Ejecucin de la Auditora. Elaboracin del Informe de Auditora. Presentacin del Informe de Auditora. Seguimiento de la Auditora.

La Auditora
Tareas del Auditor Informtico
1. Planeacin de la Auditora (Objetivos, Alcance, Programa, Recursos) 2. Obtener y documentar evidencias. 3. Evaluar fortalezas, debilidades y controles 4. 5. Reportar hallazgos, conclusiones y recomendaciones Dar seguimiento a recomendaciones de Informes

6. Cumplir Cdigo de tica y Normas Profesionales

La Auditora
La EVIDENCIA en Auditora
Una EVIDENCIA es cualquier informacin usada por el Auditor Informtico para determinar si la entidad o dato que est siendo auditado cumple con el criterio u objetivos establecidos para la auditora. La EVIDENCIA de Auditora puede incluir: Las observaciones del Auditor. Notas tomadas en entrevistas. Material extrado de correspondencia o documentacin interna. Resultados de pruebas

La Auditora
Determinantes para evaluar la EVIDENCIA de auditora incluyen:

Independencia del Proveedor de la Evidencia.

Calificacin o Calidad del individuo que provee la informacin o Evidencia.

Objetividad de la Evidencia.

La Auditora
Pruebas de: cumplimiento y sustantivas
Prueba de cumplimiento: Una Prueba de Cumplimiento determina si los controles estn siendo aplicados de tal manera que Cumplen con las polticas y procedimientos establecidos. Prueba sustantiva:

Una prueba sustantiva Sustenta, establece o comprueba la integridad del proceso que est siendo auditado. Esto es, verifica la adecuacin de los controles existentes para proteger a la organizacin de actividades fraudulentas

La Auditora
Tipos de Opiniones en el Informe de Auditora
1. Informe sin Salvedades (Unqualified Opinin)

2.

Informe con Salvedades (Qualified Opinin)

Opinin Adversa (Adverse Opinin) Renuncia de Opinin (Disclaimer of Opinin)

3.

4.

2. IMPACTO DE LA INFORMTICA EN LA ORGANIZACIN Y EN LA AUDITORA

Impacto de la Informtica en la Organizacin y en la Auditora

Incremento del uso del computador para procesar los datos de la empresa. Conciencia de la informacin como un recurso valioso. Dependencia de las organizaciones de la Unidad de Informtica. El permanente avance tecnolgico. Mayor volumen de datos, concentracin de informacin. Uso de PCs y facilidad de acceso a la informacin. Poca comprensin de la Informtica por la Gerencia. Falta de conciencia del alcance de la informtica para bien o para mal.

Impacto de la Informtica en la Organizacin y en la Auditora

Fraudes, mal uso de la informacin.

Naturaleza de los controles en el ambiente informtico.

-Informacin en medios magnticos. -Controles y verificaciones hechos por el computador.

Alteracin sustancial de las Pistas de Auditora.

Desconocimiento de los requisitos de auditora y control para las aplicaciones

Impacto de la Informtica en la Organizacin y en la Auditora

Puntos a considerar:
A medida que ms evoluciona la Tecnologa de la Informacin, ms difcil se hace para el Auditor la definicin de controles y pistas de auditora en los Sistemas Computarizados Cuanto ms automatizado sea un Sistema, ms dificultades tiene un Auditor Interno para desempear su funcin Los Sistemas de Comunicacin de Datos aumentan las posibilidades de violacin a los Sistemas de Informacin

Parece que la Tecnologa incrementa el riesgo !! Tal parece que la Tecnologa est en contra del Auditor !!

Impacto de la Informtica en la Organizacin y en la Auditora

Los riesgos de una Auditora y Control inadecuado
1. El sistema manual vs el Sistema automtico 1. Nmero de errores. 2. Efecto de los errores. 3. Rastreo de los errores. 2. Fuentes potenciales de prdidas. 1. Errores y omisiones 2. Controles impropios 3. Diseo de sistemas inadecuado 4. Fraude y desfalco 5. Fallas en el cumplimiento de estndares y procedimientos. 6. Mala utilizacin de la informacin

Impacto de la Informtica en la Organizacin y en la Auditora

!! SI NO SE PUEDE ASEGURAR LA INTEGRIDAD DE LOS DATOS DE UNA EMPRESA LA INTEGRIDAD DE LA ORGANIZACIN PUEDE ESTAR EN PELIGRO

3.

AUDITORA A LA UNIDAD INFORMTICA

Auditora a la Unidad Informtica

Definicin: Auditora Informtica.
El examen completo y constructivo de la Unidad de
Informtica de una organizacin en los aspectos de Planeacin, Organizacin, Operacin, Control, Uso de

Recursos (Humanos, Tecnolgicos, Financieros y de

Informacin) con el fin de descubrir deficiencias e irregularidades y proporcionar las recomendaciones necesarias para mejorar su servicio, funciones, condiciones de operacin, y crecimiento.

Auditora a la Unidad Informtica

Marco de Referencia
1. Auditora a la Organizacin y Administracin de la Funcin Informtica. 2. Auditora a los Procesos de la Funcin Informtica. 3. Auditora a la Seguridad de los Sistemas de Informacin en los aspectos de Integridad, Confidencialidad y Disponibilidad. 4. Auditora al Desarrollo, Adquisicin y Mantenimiento de Sistemas de Informacin.

Auditora a la Unidad Informtica

1. Auditora a la Organizacin y Administracin de la Funcin Informtica. 1.1 Estrategia Informtica. 1.2 Polticas y procedimientos. 1.3 Prcticas Gerenciales. 1.4 Estructura Organizacional.

2. Auditora a los Procesos de la Funcin Informtica 2.1 Plataforma de Hardware. 2.2 Plataforma de Software. 2.3 Infraestructura de Redes y Telecomunicaciones. 2.4 Prcticas Operacionales.

Auditora a la Unidad Informtica

3. Auditora a la Seguridad de los Sistemas de Informacin en los aspectos de Integridad, Confidencialidad y Disponibilidad. 3.1 Controles de Acceso Lgico 3.2 Controles de Acceso Fsico 3.3 Controles Ambientales 3.4 Controles de Validacin, Proceso y Balanceo de Datos 3.5 Planeacin de Contingencias.

4. Auditora al Desarrollo, Adquisicin y Mantenimiento de Sistemas de Informacin.

4.1 Metodologas de Desarrollo, Adquisicin y Mantenimiento de Aplicaciones. 4.2 Prcticas de Desarrollo y Adquisicin de Aplicaciones 4.3 Prcticas de Mantenimiento a Aplicaciones

4. Tcnicas para auditar aplicaciones computarizadas

Aplicacin de las tcnicas de auditora a sistemas computarizados

METODOLOGIA DE 3 FASES
1. REVISION INICIAL.
Revisin inicial y evaluacin del rea a ser auditada y preparacin del Plan de Auditora
REVISION INICIAL

2. REVISION DETALLADA Y EVALUACION.

Revisin detallada y evaluacin de la lgica del proceso y los controles.

REVISION DETALLADA Y EVALUACION

3. PRUEBAS.
Pruebas para verificar el cumplimiento con los controles establecidos y la verificacin de registros y transacciones seleccionadas.
PRUEBA

Tcnicas y herramientas para auditar aplicaciones computarizadas

PARA PLANEAR Y ADMINISTRAR LA AUDITORIA - Scoring PARA SELECCIONAR Y MONITOREAR TRANSACCIONES

- Audit Area Selection - Multisite Audit SW - Competency Center

PARA PROBAR CONTROLES EN PROGRAMAS
-

- Transaction Selection

- Embedded Audit Data Collection - Extended Records

PARA VERIFICAR DATOS

Test Data / Test Cases Method Base Case System Evaluation Parallel Operation Integrated Test Facility (ITF) Parallel Simulation

- Generalized Audit SW

- Special Purpose Audit Program - File Scanning

Tcnicas y herramientas para auditar aplicaciones computarizadas

PARA ANALIZAR PROGRAMAS
-

PARA AUDITAR EL DESARROLLO DE APLICACIONES

-

Snapshot/ Tagging/ - Tracing/ Mapping - Control Flowcharting - Program Verification

PARA AUDITAR OPERACIONES DEL CENTRO DE COMPUTO

- SMF Data Analysis - Audit Guide - Disaster Testing

Post-installation Audit Control Guidelines for System Development System Development Life Cycle (SDLC) System Acceptance and Control Group Application System Control & auditability Review (ASC&A) Code Comparison

AUDITORIA DEL DESARROLLO

Se entiende por ingeniera del software el establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico que sea fiable, cumpla los requisitos previamente establecidos y funcione de manera eficiente sobre maquinas reales (Fritz Bauer)

La auditora de desarrollo tratara de verificar la existencia y aplicacin de procedimientos de control adecuados que permitan garantizar que el desarrollo de sistemas de informacin se ha llevado a cabo segn estos principios de ingeniera, o por el contrario, determinar las deficiencias existentes.

IMPORTANCIA DE LA AUDITORA DEL DESARROLLO

Avance en la tecnologa De las computadoras. Crisis del software

Mejorar la calidad del software Problemas relacionados con el desarrollo y mantenimiento del Software. Control en el desarrollo.

Gasto destinado al software es superior Al dedicado al hardware.

Software de calidad y con bajo costo de mantenimiento.

El ndice de fracasos en proyectos de desarrollo es demasiado alto lo cual denota la inexistencia o malos controles en este proceso.

Un 1.5% se us tal y como se entreg Un 3.0% se us despus de algunos cambios Un 19.5% se us y luego se abandon o se rehizo. Un 47% se entreg pero nunca se us. Un 29 % se pag pero nunca se entreg.
Fuente: Government Accounting Office Report EE.UU.

Funciones del rea de desarrollo:

Elaboracin del plan estratgico de informtica. Desarrollo de nuevos sistemas.
(anlisis, diseo, construccin e implantacin)

Estudio de nuevos lenguajes, tcnicas metodolgicas, estndares, herramientas etc.. Establecimiento del plan de formacin para el personal. Establecimiento de normas y controles para todas las actividades que se realizan en el rea y comprobacin de su observancia.

Nivel I
Escriba aqu el nombre Subdir. Planeacion

Escriba aqu el nombre Director General

PROCEDIMIENTOS DE CONTROL

OBJETIVOS

Unidad de Informatica

Unidad de Informtica

El auditor verifica su definicin y aplicacin , sealando las deficiencias que existan y los riesgos asociados a estas carencias de control. Ciclo de vida del software excepto la explotacin mantenimiento y retiro de Area de Necesidades de disponer de un servicio de aplicaciones. Desarrollo Sistema de Informacin Construccin Implementacin

Metodologa
Esta basada en la evaluacin de riesgos, partiendo de los riesgos potenciales a los que esta sometida una actividad, en este caso el desarrollo de un sistema de informacin, se determinan una serie de objetivos de control que minimicen esos riesgos. Para cada objetivo de control se especifican una o mas tcnicas de control, que contribuyan a lograr el cumplimiento de dicho objetivo.

RIESGOS POTENCIALES Objetivos de control Tecnicas de control Pruebas de cumplimiento Objetivo de control X : C-X-1: Tecnica de control 1 del objetivo X Prueba de cumplimiento de C-X-1

DESARROLLO DE UN SISTEMA DE INFORMACION

conclusiones pruebas evidencias Los auditores verifican el grado de cumplimiento de cada control.

DETERMINAN: Riesgos no cubiertos, en que medida lo son y consecuencias que se derivan de esta situacin.

INFORME DE AUDITORIA: Conclusiones Recomendaciones

a) b)

Organizacin y gestin del rea de desarrollo (serie A) Proyectos de desarrollo de sistemas de informacin:

Auditora del desarrollo

Se puede realizar: 1. Conforme avanza o 2. Cuando concluye el proyecto.

Aprobacin, planificacin y gestin del proyecto. ( serie B ) Anlisis. I. Anlisis de requisitos. ( serie C ) II. Especificacin funcional. ( serie D ) Diseo. I. Diseo tcnico. (serie E ) Construccin I. Desarrollo de componentes. (serie F) II. Desarrollo de procedimientos de usuario. (serie G) Implantacin. I. Pruebas, implantacin y aceptacin ( serie H )

Serie (A; B; C; D;E; F; G) = Objetivos de control

A U D I T O R I A

A L

A R E A

D E

D E S A R R O L L O

FA S E S ORGANIZACIN Y GESTION DEL AREA DE DESARROLLO

OBJETIVOS DE CONTROL

TECNICAS DE CONTROL

NUMERO DE PRUEBAS

A2 A3 A4 A5 A6 A7 A8 SUMA AUDITORIA DE PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACION 8

5 2 2 2 6 2 1 24

14 3 5 4 28 7 2 74

APROBACION, PLANIFICACION Y GESTION DEL PROYECTO

B1 B2

4 7

15 25

ANALISIS DE REQUISITOS DEL SISTEMA ( A R S ) C1 C2 4 2 17 7

ESPECIFICACION FUNCIONAL DEL SISTEMA ( E F S ) DI S EO DISEO TECNICO DEL SISTEMA ( D T S ) E1 CONSTRUCCION DESARROLLO DE LOS COMPONENTES DEL SISTEMA (DCS) DESARROLLO DE LOS PROCEDIMIENTOS DE USUARIO (DPU) IMPLANTACION PRUEBAS IMPLANTACION Y ACEPTACION DEL SISTEMA (PIA) H1 H2 SUMA 10 3 5 44 12 14 148 F1 3 13 5 17 D1 6 16

G1

12

Organizacin y gestin del rea de desarrollo.

C-A1-1 Deben establecer de forma clara las funciones del rea de desarrollo. C-A1-2 Debe especificarse el organigrama con la relacin de puestos. C-A1-3 Debe contar y difundir su plan de corto mediano y largo plazo. C-A1-4 El rea de desarrollo deber llevar su propio control presupuestario.

Objetivo de control A2: El personal del rea de desarrollo debe contar con la formacin adecuada y estar motivado para la realizacin de su trabajo.
C-A2-1 Deben existir procedimientos objetivos de contratacin

C-A2-2 Debe existir un plan de formacin que se corresponda con los objetivos tecnolgicos del rea
C-A2-3 Debe existir un protocolo de contratacin para las personas. C-A2-4 Debe existir una biblioteca y hemeroteca para el personal del rea. C-A2-5 El personal debe estar motivado en la realizacin de su trabajo.

Objetivo de control A3: Si existe un plan de sistemas los proyectos que se lleven a cabo se basaran en dicho plan y lo mantendrn actualizado.
C-A3-1: La realizacin de nuevos proyectos deber basarse en el plan de sistemas en cuanto a objetivos, marco general y horizonte temporal. C-A3-2: El plan de sistemas debe actualizarse con la informacin que se genera a lo largo de un proceso de desarrollo

Objetivo de control A4: La propuesta y aprobacin de nuevos proyectos debe realizarse de forma reglamentada.
C-A4-1: Debe existir un procedimiento para la propuesta de realizacin de nuevos proyectos. C-A4-2: Debe existir un procedimiento de aprobacin de nuevos proyectos que depender de que exista o no un plan de sistemas.

Objetivo de control A5: La asignacin de recursos a los proyectos debe hacerse de forma reglamentada.
C-A5-1: Debe existir un procedimiento para asignar director y equipo de desarrollo a cada nuevo proyecto.

C-A5-2: Debe existir un procedimiento para conseguir los recursos materiales necesarios para cada proyecto.

Objetivo de control A6: El desarrollo de sistemas de informacin debe hacerse aplicando principios de ingeniera de software.
C-A6-1 Debe tenerse implantada una metodologa de desarrollo de sistemas de informacin soportada por herramientas de ayuda. (CASE).

C-A6-2 Debe existir un mecanismo de creacin actualizacin de estndares, as como estndares ya definidos para las actividades principales. Se prestara especial atencin a las herramientas y lenguaje de programacin o clsicas.
C-A6-3 Los lenguajes compiladores, herramientas CASE, software de control de versiones, etc. usados en el rea deben ser previamente homologados. Debe practicarse la reutilizacin del software.

C-A6-4

C-A6-5
C-A6-6

Debe existir un mtodo que permita catalogar y estimar los tiempos de cada una de las fases de los proyectos.
Debe existir un registro de problemas que se producen en los proyectos del rea incluyendo los fracasos de proyectos completos.

Objetivo de control A7: Las relaciones con el exterior del departamento tiene que realizarse de acuerdo a un procedimiento.
C-A7-1 Debe mantenerse contacto con proveedores para recibir informacin suficiente. C-A7-2 Debe existir un protocolo para contratacin de servicios externos.

Auditora del desarrollo

b) Proyectos de desarrollo de sistemas de informacin.

Considera

el

desarrollo de

un nuevo

proyecto de

sistema de informacin como un proyecto con entidad propia. Debe tener un responsable y ser gestionado con tcnicas que permitan conseguir los objetivos la sealados teniendo en cuenta los recursos disponibles y las restricciones temporales. En plan distinto dependiendo de consecuencia los auditora de cada proyecto de desarrollo tendr un riesgos, la complejidad del mismo y los recursos disponibles para realizar la auditora
Aprobacin, Planificacin y Gestin del Proyecto. (dos objetivos de control serie B)

Objetivo de control B1: El proyecto a desarrollar debe estar aprobado, definido y planificado formalmente.
C-B1-1 Debe existir una orden de aprobacin del proyecto que defina claramente los objetivos, restricciones y las unidades afectadas. C-B1-2 Debe designarse un responsable o director del proyecto. C-B1-3 El proyecto debe ser catalogado y en funcin de sus caractersticas se debe determinar el modelo de ciclo de vida que seguir. C-B1-4 Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo tcnico que realizara el proyecto y se determinara el plan del proyecto.

Objetivo de control B2: El proyecto se debe gestionar de forma que se consigan los mejores resultados posibles teniendo en cuenta las restricciones de tiempo y recursos.
C-B2-1: Los responsables de las unidades o reas afectadas por el proyecto deben participar en la gestin del proyecto. C-B2-2: Se debe establecer un mecansmo para la resolucion de los problemas que puedan plantearse a lo largo del proyecto. C-B2-3: Debe existir un control de cambios a lo largo del proyecto. C-B2-4: Cuando sea necesario reajustar el plan del proyecto, normalmente al finalizar un mdulo o fase, debe hacerse de forma adecuada. C-B2-5: Debe hacerse un seguimiento de los tiempos empleados tanto por tarea como a lo largo del proyecto. C-B2-6: Se debe controlar que se sigan las etapas del ciclo de vida adoptado para el proyecto y que se generen todos los documentos asociados a la metodologa empleada. C-B2-7: Cuando termina el proyecto se debe cerrar toda la documentacin del mismo, liberar los recursos empleados y hacer un balance.

Auditora de la fase de Anlisis.

Pretende obtener un conjunto de especificaciones formales que describan las necesidades de informacin que deben ser cubiertas por el nuevo sistema de una forma independiente del entorno

tcnico.
Esta fase se divide en dos mdulos: I. Anlisis de Requisitos del Sistema. ARS ( serie C )

Se determinaran tanto los requisitos funcionales como los no

funcionales distinguiendo para cada uno de ellos su importancia y prioridad. A partir del conocimiento actual y sus problemas asociados, junto con los requisitos que se exigirn al nuevo sistema, se determinaran las posibles soluciones y de ellas las alternativas que satisfagan esos requisitos eligiendo la mas adecuada.

Se consideran dos objetivos de control.

Objetivo de control C1: Los usuarios y responsables de las unidades a las que afecta el nuevo sistema estableceran de forma clara los requisitos del mismo.
C-C1-1: En el proyecto deben participar usuarios de todas las unidades a las que afecte el nuevo sistema. Esta participacion, se hara normalmente a travs de entrevistas, tendra especial importancia en la definicion de requisitos del sistema.

C-C1- 2: Se debe realizar un plan detallado de entrevistas con el grupo de usuarios del proyecto y con los responsables de las unidades afectadas que permita conocer como valoran el sistema actual y lo que esperan del nuevo sistema.
C-C1-3: A partir de la informacin obtenida en las entrevistas, se debe documentar el sistema actual asi como los problemas asociados al mismo. Se debe obtener tambien un catalogo con los requisitos del nuevo sistema. C-C1-4: Debe existir un procedimiento formal para registrar cambios en los requisitos del sistema por parte de los usuarios.

Objetivo del control C2: En el proyecto de desarrollo se utilizar la alternativa ms favorable para conseguir que el sistema cumpla con los requisitos establecidos.

C-C2-1: Dados los requisitos del nuevo sistema se deben definir las diferentes alternativas de construccin con sus ventajas e inconvenientes. Se evaluaran las alternativas y se

seleccionar las ms adecuada.

C-C2-2: La actualizacion del plan de proyecto seguir los criterios ya comentados.

II. Especificacin Funcional del Sistema. EFS ( serie D )

Una vez conocido el sistema actual, los requisitos del nuevo sistema y la alternativa de desarrollo ms favorable, se elabora una especificacin funcional detallada del sistema que sea coherente con lo que se espera de el. El grupo de usuarios y los responsables de las unidades afectadas deben ser la principal fuente de informacin.

Se considera un nico objetivo de control.

Auditora de la fase de Anlisis:

II. Especificacin Funcional del Sistema (EFS)

Objetivo de control D1: El nuevo sistema debe especificarse de forma completa desde el punto de vista funcional, contando esta especificacin con la aprobacin de los usuarios.

C-D1-1: Se debe realizar un modelo lgico del nuevo sistema, incluyendo Modelo Lgico de Procesos ( MLP) y Modelo Lgico de Datos ( MLD ). Ambos deben ser consolidados para garantizar su coherencia. C-D1-2: Debe existir el diccionario de datos o repositorio.

 C-D1-3: Debe definirse la forma en que el nuevo sistema interactuar con los nuevos usuarios. Esta es la parte ms importante para el usuario porque definir su forma de trabajo con el sistema. C-D1-4: La especificacin del nuevo sistema incluir los requisitos de seguridad, rendimiento, copias de seguridad y recuperacin, etc. C-D1-5: Se deben especificar las pruebas que el nuevo sistema debe superar para ser aceptado.

C-D1-6: La actualizacin del plan de proyecto seguir los criterios ya comentados, detallndose en este punto en mayor medida la entrega y transicin al nuevo sistema.

Auditoria de la fase de Diseo.

En esta fase se elabora el conjunto de las especificaciones fsicas del nuevo sistema que servirn de base para la construccin del mismo. Considera un solo modulo.

I. Diseo Tecnico del Sistema. DTS (serie E)

A partir de las especificaciones funcionales, y teniendo en cuenta el entorno tecnolgico, se disear la arquitectura del sistema y el esquema externo de datos.

Se considera un nico objetivo de control.

Auditora de la fase de Diseo: Diseo Tcnico del Sistema (DTS)

Objetivo de control E1 : Se debe definir una arquitectura fsica para el
sistema coherente con la especificacin funcional que se tenga y con el entorno tecnolgico elegido.

C-E1-1: El entorno tecnolgico debe estar definido de forma clara y ser congruente con los estndares del departamento de informtica.

C-E1-2: Se deben identificar todas las actividades fsicas a realizar por el sistema y descomponer las mismas de forma modular.

 C-E1-3: Se debe disear la estructura fsica de datos adaptando las especificaciones del sistema al entorno tecnolgico.

C-E1-4: Se debe disear un plan de pruebas que permita la

verificacin de los distintos componentes del sistema por separado, as como el funcionamiento de los distintos subsistamos y del sistema en conjunto. C-E1-5: La actualizacin del plan de proyecto seguir los criterios ya comentados.

Auditora de la fase de Construccin.

En esta fase se programarn y probarn los distintas componentes y se pondrn en marcha todos los procedimientos necesarios para

que los Usuarios puedan trabajar con el nuevo sistema. Estar basado en las especificaciones fsicas obtenidas en la fase de diseo. Para lo anterior tenemos dos mdulos.

I.

Desarrollo de los Componentes del Sistema. DCS (serie F)

En este mdulo se realizarn los distintos componentes, se probarn tanto Individualmente como de forma integrada y se desarrollarn los procedimientos de operacin. Se considera un solo objetivo de control.

II. Desarrollo de los Procedimientos de Usuario. DPU (serie G ) En este mdulo se definen los procedimientos y formacin necesarios para que los usuarios puedan utilizar el nuevo sistema

de manera adecuada. Fundamentalmente se trata de la instalacin, la

conversin de datos y la operacin /explotacin. Se considera tambin un solo objetivo de control.

Auditora de la fase de construccin: I. Desarrollo de los componentes del sistema (DCS)

Objetivo de control F1 : Los componentes o mdulos deben Desarrollarse usando tcnicas de programacin correctas.
C-F1-1: Se debe preparar adecuadamente el entorno de desarrollo y de pruebas, as como los procedimientos de operacin, antes de iniciar el desarrollo. C-F1-2: Se debe programar, probar y documentar cada uno de los

componentes identificados en el diseo del sistema.

C-F1-3: Deben realizarse las pruebas de integracin para asegurar

que las interfases entre los componentes o mdulos

funcionen correctamente.

Auditora de la fase de construccin:

II. Desarrollo de los procedimientos de usuario(DPU)

Objetivo de control G1 : Al trmino del proyecto, los futuros usuarios deben estar capacitados y disponer de todos los medios para hacer uso del sistema.
C-G1-1: El desarrollo de los componentes de usuario debe estar planificado. C-G1-2: Se deben especificar los perfiles de usuario requeridos para el nuevo sistema. C-G1-3: Se deben desarrollar todos los procedimientos de usuario con arreglo a los estndares del rea. C-G1-4: A partir de los perfiles actuales de los usuarios, se deben definir los procesos de formacin o seleccin de personal necesarios. C-G1-5: Se deben definir los recursos materiales necesarios para el trabajo de los usuarios con el nuevo sistema.

Auditoria de la fase de Implantacin.

En esta fase se realizar la aceptacin del sistema por parte de los

usuarios adems de las actividades necesarias para la puesta en

marcha. Hay un nico modulo.

Pruebas, Implantacin y Aceptacin del Sistema. PIA (serie H)

Se verificar en este mdulo que el sistema cumple con los requisitos establecidos en la fase de anlisis. Una vez probado y aceptado se pondr en explotacin. Se consideran dos objetivos de control.

Auditora de la fase de Implantacin:

Pruebas, Implantacin y Aceptacin del Sistema (PIA)

Objetivo de control H1 : El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en operacin.

C-H1-1: Se deben realizar las pruebas del sistema que se especificaron

en el Diseo del mismo.

C-H1-2: El plan de implantacin y aceptacin se debe revisar para adaptarlo a la situacin final del proyecto C-H1-3: El sistema debe ser aceptado por los usuarios antes de ponerse en operacin.

Objetivo de control H2 : El sistema se pondr en operacin formalmente y pasar a estar en mantenimiento solo cuando haya sido aceptado y este preparado todo el entorno en el que se ejecutar.
C-H2-1: C-H2-2: Se deben instalar todos los procedimientos de operacin. Si existe un sistema antiguo, en sistema nuevo se pondr en operacin de forma coordinada con la retirada del antiguo, migrando los datos si es necesario. C-H2-3: Debe firmarse el final de la implantacin por parte de los usuarios. C-H2-4: Se debe supervisar el trabajo de los usuarios con el nuevo sistema en las primeras semanas para evitar situaciones de

abandono en el uso del sistema.

C-H2-5: Para terminar el proyecto se pondr en marcha el mecanismo

de mantenimiento.

C-A1-1 Deben establecer de forma clara las funciones del rea de desarrollo.

Existe el documento que contiene las funciones que son competencia del rea de desarrollo. Esta aprobado por la direccin de informtica,se respeta.
C-A1-2 Debe especificarse el organigrama con la relacin de puestos.

Existe un organigrama con la estructura de organizacin del rea,manual de organizacin y perfil de puestos. Existe la relacin de personal adscrito al rea. Existen los procedimientos de promocin.

C-A1-3 Debe contar y difundir su plan de corto mediano y largo plazo.

El plan existe es claro y realista. Los recursos actuales ms lo que este planificado son suficientes para su cumplimiento. Se revisa y actualiza con periodicidad en funcin de las nuevas situaciones. Se difunde a todos los empleados para que se sientan participes del mismo.
C-A1-4 El rea de desarrollo deber llevar su propio control presupuestario.

Se hace un presupuesto por ejercicio y se cumple. El presupuesto se corresponde con los objetivos.

C-A2-1 Deben existir procedimientos objetivos de contratacin

Las ofertas de puestos del rea se difunden de forma suficiente fuera de la organizacin. Las personas seleccionadas cumplen los requisitos del puesto al que acceden.
C-A2-2 Debe existir un plan de formacin que se corresponda con los objetivos tecnolgicos del rea

Se tiene un plan de formacin a corto mediano y largo plazo coherente con la poltica tecnolgica. Incluye toda la formacin relevante para cada actividad formativa: fechas horarios lugar ponentes etc.. Contempla la formacin de todos los empleados y tiene en cuenta el puesto que ocupan. El plan de trabajo del rea tiene en cuenta los tiempos de formacin.

C-A2-3 Debe existir un protocolo de contratacin para las personas.

El protocolo existe y se respeta para cada incorporacin /abandono. En los abandonos del personal se garantiza la proteccin del rea.
C-A2-4 Debe existir una biblioteca y hemeroteca para el personal del rea.

Estn disponibles un nmero suficiente de libros, publicaciones etc.. de reconocido prestigio y el personal tiene acceso a ellos.
C-A2-5 El personal debe estar motivado en la realizacin de su trabajo.

Se permite a los empleados hacer sugerencias sobre mejoras en la organizacin. No existe una gran rotacin de personal. El rendimiento del personal esta en aceptable.

C-A3-1: La realizacin de nuevos proyectos deber basarse en el plan de sistemas en cuanto a objetivos, marco general y horizonte temporal.

Las fechas de realizacin coinciden con las del plan de sistemas. La documentacin relativa a cada proyecto que hay en el plan de sistemas se pone a disposicin del director del proyecto una vez comenzado el mismo.
C-A3-2: El plan de sistemas debe actualizarse con la informacin que se genera a lo largo de un proceso de desarrollo.

Los cambios en los planes de los proyectos se comunican al responsable de mantenimiento del plan de sistemas.

C-A4-1: Debe existir un procedimiento para la propuesta de realizacin de

nuevos proyectos.

Existe un mecansmo para registrar necesidades de desarrollo de nuevos sistemas y en todo caso se aportan los siguientes datos: descripcin, necesidad, departamento patrocinador, riesgos, marco, temporal,costo de no realizarlo,ventajas que aporta.
Se respeta este mecanismo en todas las propuestas.
C-A4-2: Debe existir un procedimiento de aprobacin de nuevos proyectos que depender de que exista o no un plan de sistemas

El sistema a desarrollar es parte del plan de sistemas. De no ser el caso, existe un procedimiento para llevar a cabo el estudio de viabilidad de cada nuevo proyecto.

 Existen areas de la organizacin que tienen competencia para aprobar formalmente la realizacin y prioridades de los nuevos proyectos.
C-A5-1: Debe existir un procedimiento para asignar director y equipo de desarrollo a cada nuevo proyecto.

El procedimiento existe y se respeta. Se tiene presente a todas las personas disponibles cuyo perfil sea adecuado a los riesgos de cada proyecto. Existe un protocolo para solicitar al resto de las reas, la participacin de personal en el proyecto.
C-A5-2: Debe existir un procedimiento para conseguir los recursos materiales necesarios para cada proyecto.

El procedimiento existe y se respeta.

C-A6-1

Debe tenerse implantada una metodologa de desarrollo de sistemas de informacin soportada por herramientas de ayuda. (CASE)

La metodologa cubre todas las fases de desarrollo y es adaptable a distintos tipos de proyectos. La metodologa y las tcnicas asociadas estan adaptadas al entorno tecnolgico y de organizacin del rea de desarrollo. Se ha adquirido, homologado e implantado segn las normas del rea una herramienta CASE . Existe un procedimiento que permita determinar en que proyectos el uso de la herramienta CASE es ventajoso. Esta claramente especificado de que forma el uso de la herramienta altera las fases de desarrollo tradicionales. La herramienta CASE es capaz de mantener el diccionario de datos. La herramienta CASE mantiene los requisitos de confidenciabilidad necesarios.

C-A6-2

Debe existir un mecanismo de creacin actualizacin de estndares, as como estndares ya debidos para las actividades principales. Se prestar especial atencin a las herramientas y lenguaje de programacin no clsicas.

El mecanismo para creacin de nuevos estandares esta documentado y es conocido en el rea. Hay un estandar para la realizacin del anlisis y diseo. Hay un estandar de programacin para cada uno de los lenguages homologados.(Prestar atencion a las herramientas RAD Rapid
Application Development Existen

convenios sobre los aspectos ms importantes de la programacin, modularidad nomenclatura. Existe un estandar para la documentacin generada(anlisis diseo documentacin de los programas etc.).

 Hay un estandar para la interfaz de usuario incluyendo diseo de pantallas informes,etc. Los estandares son conocidos por las personas que deben usarlos y se respetan.
C-A6-3 Los lenguajes compiladores, herramientas CASE, software de control de de versiones, etc., usados en el rea deben ser previamente homologados.

Existe un mecanismo para la adquisicin y homologacin de cualquier nuevo producto software usado en el desarrollo. Cuando se homologa un nuevo producto de desarrollo se capacita al personal que lo manejar. Se registra la informacin ms importante a cerca de la configuracin de los productos recien adquiridos. Periodicamente se comprueba el nivel tecnolgico para ver si es coherente con el plan de sistemas.

C-A6-4

Debe practicarse la reutilizacin del software.

Existe un catlogo con todos los productos software suceptibles de ser utilizados. El catlogo es conocido y accesiblepor todos los miembros del rea, esta actualizado. Existe un catlogo de todas las aplicaciones disponibles en el rea tanto de las realizadas como de las adquiridas.
C-A6-5 Debe existir un mtodo que permita catalogar y estimar los tiempos de cada una de las fases de los proyectos.

El mtodo usado es correcto, esta bien ajustado y documentado adecuadamente. Las desviaciones producidas en cada proyectose usan para ajustar los parmetros de catalogacin y estimacin manteniendo un historico de los mismos.

C-A6-6

Debe existir un registro de problemas que se producen en los proyectos del rea incluyendo los fracasos de proyectos completos.

Existe un catlogo de problemas, incluyendo para cada uno de ellos la solucin o soluciones encontradas, proyecto en el que sucedi, persona que lo resolvi etc. El catlogo es accecible para todos los miembros del rea, esta actualizado y tiene ndices que faciliten la busqueda. Se registran y controlan todos los proyectos fracasados(aquellos que comienzan y no llegan a su fin), asi como los recursos invertidos en los mismos.

C-A7-1 Debe mantenerse contacto con proveedores para recibir informacin suficiente.

Se esta en contacto con un nmero suficiente de proveedores para recibir una informacin objetiva y completa, y el tiempo invertido en estas tareas no excede lo razonable.
C-A7-2 Debe existir un protocolo para contratacin de servicios externos.

Existe un protocolo y se hace uso de el. La seleccin del proveedor se hace de forma objetiva y evita situaciones de monopolio de un nico proveedor. Existe un contrato tipo que prevee los riesgos frecuentes. Una persona del rea certifica el trabajo realizado antes del pago. Es compatible con los estandares establecidos en el rea.

C-B1-1 Debe existir una orden de aprobacin del proyecto que defina

claramente los objetivos, restricciones y las unidades afectadas.

Existe una orden de aprobacin del proyecto refrendada por un rgano competente. El estudio de viabilidad debe haber seguido un cause establecido. En el documento de aprobacion estan definidos de forma clara y precisa los objetivos del mismo y las restricciones de todo tipo que deben tenerse en cuenta. Se ha identificado las unidades de la organizacin a las que afecta.
C-B1-2 Debe designarse un responsable o director del proyecto.

La designacin se llevo a cabo segun el procedimiento establecido. Se le comunic al director su nombramiento junto con toda la informacin relevante del proyecto.

C-B1-3 El proyecto debe ser catalogado y en funcin de sus

caractersticas se debe determinar el modelo de ciclo de vida que

seguir.

Se ha catalogado y dimensionado segn las normas establecidas. Se han evaluado los riesgos asociados al proyecto especialmente cuando se va a usar tecnologa nueva. Se a elegido el ciclo de vida ms adecuado al tipo de proyecto de que se trata. Se ha hecho uso de la informacin histrica que se dispone tanto para dimencionar el proyecto y sus riesgos. Se prestar especial atencion si se elige un tipo de ciclo de vida basado en prototipado y debe existir un acuerdo con los usuarios sobre el alcance del prototipo y el objetivo que se persigue con el mismo.

C-B1-4

Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo tcnico que realizara el proyecto y se determinara el plan del proyecto.

La designacin del equipo de desarrollo se ha llevado a cabo segn los procedimientos establecidos. Los participantes que pertenezcan a otras reas (sistemas, comunicaciones, ofimatica, etc.) se han solicitado segn el protocolo existente. Si participa personal externo los perfiles profesionales son adecuados a las funciones que van a realizar. Se ha comunicado a todos los miembros del equipo de desarrollo los objetivos del proyecto, la responsabilidad que tendrn en el mismo, las fechas en las que participarn. El plan del proyecto es realista y emplea la informacin historica para hacer estimaciones.

C-B2-1: Los responsables de las unidades o reas afectadas por el

proyecto deben participar en la gestin del proyecto.

Se ha constituido el comit de direccin del proyecto El comit se rene peridicamente y en cualquier caso siempre que lo exija el desarrollo del proyecto. Las reuniones siguen una orden del da previo y las decisiones tomadas se asientan en actas el comit.
C-B2-2 : Se debe establecer un mecanismo para la resolucin de los problemas que puedan plantearse a lo largo del proyecto.

Existen hojas de registro de problemas y alguna persona del proyecto esta encargada de la recepcin. Hay un mtodo para catalogar los problemas ,as como para trasladarlos a la persona que los debe resolver. Se controla la solucin de problemas y se deja constancia.

C-B2-3 : Debe existir un control de cambios a lo largo del proyecto.

Existe un mecanismo para registrar los cambios que pudieran presentarse y evaluar su impacto. La documentacin afectada se actualiza y se lleva un control de versiones de cada producto. Se remite la nueva versin de los documentos actualizados a los participantes en el proyecto
C-B2-4 : Cuando es necesario reajustar el plan del proyecto, normalmente al finalizar un mdulo o fase, debe hacerse de forma adecuada.

Se respetan los lmites de tiempo y presupuesto marcados al inicio del proyecto. Se han considerado los riesgos del ajuste. Se emplea la informacin histrica para realizar las estimaciones.

C-B2-5: Debe hacerse un seguimiento de los tiempos empleados tanto

por tarea como a lo largo del proyecto.

Existe un procedimiento que permita registrar los tiempos que cada participante del proyecto dedica al mismo y que tarea realiza en ese tiempo. La productividad que se obtiene para distintos empleados en las mismas tareas son similares y estn en consonancia con la informacin histrica.
C-B2-6: Se debe controlar que se sigan las etapas del ciclo de vida adoptado para el proyecto y que se generen todos los documentos asociados a la metodologa empleada.

Antes de comenzar una nueva etapa se ha documentado la etapa previa y se ha revisado y aceptado especialmente en las fases de anlisis y diseo.

 La documentacin cumple con los estndares establecidos. Se respeta el plan establecido y en caso contrario se toman las medidas oportunas para modificar el plan. Se respeta el uso de recursos previamente establecido.
C-B2-7 : Cuando termina el proyecto se debe cerrar toda la documentacin del mismo, liberar los recursos empleados y hacer un balance.

La documentacin del proyecto esta completa y esta catalogada para accesos posteriores. Los recursos tanto personales como materiales se ponen a disposicin del rea que provienen. El comit de direccin y el director del proyecto lo evalan estudiando los posibles problemas y sus causas los cambios de plan etc. La nueva aplicacin se incorpora al catlogo de aplicaciones

C-C1-1 : En el proyecto deben participar usuarios de todas las unidades a las que afecte el nuevo sistema. Esta participacion, se har normalmente a travs de entrevistas, tendr especial importancia en la definicin de requisitos del sistema.

El comit de direccin aprob formalmente el grupo de usuarios que participar en el proyecto. Los usuarios elegidos son suficientemente representativos de las unidades afectadas por el nuevo sistema. Se les ha comunicado a los usuarios su participacin en el proyecto informando les del mbito del mismo y de que es lo que se espera de ellos.

C-C1-2: Se debe realizar un plan detallado de entrevistas con el grupo de usuarios del proyecto y con los responsables de las unidades afectadas que permita conocer como valoran el sistema actual y

lo que esperan del nuevo sistema.

Existe un plan consensuado con el comit de direccin que detalla para cada entrevista, fecha, hora, lugar tipo de entrevista y un guin de los aspectos que se tratarn. Se entrevista a todos los usuarios y a todos los responsables de las unidades afectadas. Se remite el guin a los entrevistados con antelacin suficiente para que estos puedan preparar la entrevista. El guin incluye todas las cuestiones necesarias para obtener la informacin de las funciones que el entrevistado realiza en su unidad y los problemas que necesita resolver.

C-C1-3 : A partir de la informacion obtenida en las entrevistas, se debe

documentar el sistema actual asi como los problemas

asociados al mismo. Se debe obtener tambien un catlogo con los requisitos del nuevo sistema.

Se ha realizado un modelo fsico del sistema actual, incluyendo los objetivos y funciones de cada unidad , as como sus flujos de entrada y salida de informacin. Se han catalogado los problemas del sistema actual y se calificaron como reales. Se ha realizado el modelo lgico de datos y el modelo lgico de procesos del sistema actual. Existe el catlogo de requisitos y estn justificados. Los requisitos son concretos y cuantificables de forma que pueda determinarse el grado de cumplimiento al final del proyecto. Cada requisito tiene una prioridad y esta clasificado en funcional o no funcional.

 El catlogo de requisitos ha sido revisado y aprobado por el grupo de usuarios y por el comit de direccin constituyndose como el contrato.

C-C1-4 : Debe existir un procedimiento formal para registrar cambios en

los requisitos del sistema por parte de los usuarios.

El procedimiento existe y esta aprobado. Es coherente con el procedimiento de control del cambio general para el proyecto.

C-C2-1 : Dados los requisitos del nuevo sistema se deben definir las

diferentes alternativas de construccin con sus ventajas e

inconvenientes. Se evaluaran las alternativas y se seleccionar las ms adecuada.

Existe un documento en el que se describen las distintas alternativas. Hay ms de una alternativa y en caso contrario, que no existe otra posible. Cada alternativa esta descrita desde un punto de vista lgico y es coherente con los requisitos establecidos. Si existe en el mercado un producto que cumpla con mnimas garantas debe ser evaluado. Evaluar el desarrollo del sistema por una empresa externa como alternativa.
C-C2-2 : La actualizacin del plan de proyecto seguir los criterios ya comentados

C-D1-1: Se debe realizar un modelo lgico del nuevo sistema, incluyendo Modelo Lgico de Procesos ( MLP) y Modelo Lgico de Datos ( MLD). Ambos deben ser consolidados para garantizar su coherencia.

Se ha partido de los modelos realizados en el anlisis de requisitos del sistema. Existe el Modelo Lgico de Procesos. En el diagrama de contexto estn reflejados todos los agentes externos,incluidos otros sistemas con los que el sistema intercambia informacin. Existe el Modelo Lgico de Datos(entidad-relacin o diagramas de estructura de datos). En el Modelo Lgico de Datos estn reflejadas todas las entidades con sus atributos claves as como su relacin. Los Modelos Lgicos de Procesos y de Datos son coherentes.

C-D1-2 : Debe existir el diccionario de datos o repositorio.

Existe el diccionario de datos y es correcto y se gestiona de forma automatizada. Se respetan en su gestin todos los procedimientos de control de cambios.
C-D1-3 : Debe definirse la forma en que el nuevo sistema interactuara con los nuevos usuarios. Esta es la parte ms importante para el usuario porque definir su forma de trabajo con el sistema.

Se han descrito con suficiente detalle las pantallas a travs de las cuales el usuario navegar por la aplicacin. Se han descrito con suficiente detalle los informes que se obtendrn del sistema y los formularios asociados. La interfaz de usuario se ha aprobado por el grupo de usuarios y por el comit de direccin.

C-D1-4 : La especificacin del nuevo sistema incluir los requisitos de seguridad, rendimiento, copias de seguridad y recuperacin, etc.

Esta informacin se ha solicitado a los usuarios en las entrevistas correspondientes a este mdulo. Se han aadido estos requisitos al catlogo de requisitos realizado en la etapa de Anlisis de Requisitos del Sistema.
C-D1-5: Se deben especificar las pruebas que el nuevo sistema debe superar para ser aceptado.

Se ha elaborado el plan de pruebas de aceptacin del sistema es coherente con el catlogo de requisitos y con la especificacin funcional del sistema El plan de pruebas de aceptacin tiene en cuenta todos los recursos necesarios.

C-D1-6: La actualizacin del plan de proyecto seguir los criterios ya comentados, detallndose en este punto en mayor medida la entrega y transicin al nuevo sistema.

C-E1-1 : El entorno tecnolgico debe estar definido de forma clara y ser

congruente con los estndares del departamento de informtica.

Estn perfectamente definidos todos los elementos que configuran el entorno tecnolgico para el proyecto (servidores, ordenadores personales, perifricos, sistemas operativos, conexiones de red, protocolos de comunicacin, sistemas gestores de bases de datos, etc. Se dispone de los elementos seleccionados, estn dentro de los estndares del departamento de informtica y son capaces de responder a los requisitos establecidos de volmenes, tiempos de respuesta,seguridad, etc.

C-E1-2 : Se deben identificar todas las actividades fsicas a realizar por el sistema y descomponer las mismas de forma modular.

Se han documentado todas las actividades fsicas que debe realizar el sistema. El catlogo de actividades es coherente con las funciones identificadas en el Modulo Lgico de Procesos. Existe el documento con el diseo de la estructura modular del sistema, se ha realizado con una tcnica adecuada. El tamao de los mdulos es adecuado, el factor de acoplamiento entre ellos es mnimo y la cohesin interna de cada mdulo es mxima. Se han detallado las interfaces de datos y control con otros mdulos y sistemas, as como la interfaz de usuario.

C-E1-3 : Se debe disear la estructura fsica de datos adaptando las

especificaciones del sistema al entorno tecnolgico.

Se han creado e inicializado las bases de datos y cumplen las especificaciones realizadas en el mdulo de diseo.

En ningn momento se trabaja con informacin que se encuentre en explotacin.

Existen los procedimientos de copia de seguridad. Se han preparado los editores, compiladores, etc..

C-E1-4: Se debe disear un plan de pruebas que permita la verificacin de los distintos componentes del sistema por separado, as como el funcionamiento de los distintos subsistamos y del sistema en conjunto.

Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto. Las personas que realizarn las pruebas de verificacin son distintas a las que han desarrollado el sistema. Es adecuado para validar cada uno de los componentes del sistema, incluyendo pruebas del tipo caja blanca para cada mdulo. Tendrn en cuenta todas las posibles condiciones lgicas de ejecucin, adems de posibles fallos del hardware software de base. Permite validar la integracin de los distintos componentes y el sistema en su conjunto.
C-E1-5: La actualizacin del plan de proyecto seguir los criterios ya comentados.

C-F1-1: Se debe preparar adecuadamente el entorno de desarrollo y

de pruebas, as como los procedimientos de operacin, antes de iniciar el desarrollo.

Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto. Las personas que realizaran las pruebas de verificacin son distintas a las que han desarrollado el sistema. Es adecuado para validar cada uno de los componentes del sistema,incluyendo pruebas del tipo caja blanca para cada mdulo. Tendrn en cuenta todas las posibles condiciones lgicas de ejecucin, adems de posibles fallos del hardware software de base. Permite validar la integracin de los distintos componentes y el sistema en su conjunto.

 Estn disponibles los puestos de trabajo y el acceso a los equipos, redes, etc.. Estn disponibles todos los elementos lgicos y fsicos para realizar las pruebas unitarias de los componentes y las pruebas de integracin. Estn documentados todos los procedimientos operacin para cuando el sistema est en explotacin. de

 C-F1-2: Se debe programar, probar y documentar cada uno de los

componentes identificados en el diseo del sistema.

Se han desarrollado todos los componentes o mdulos.

Se han seguido los estndares de programacin y documentacin del rea, el cdigo es estructurado, contiene comentarios suficientes. Se ha probado cada componente y se ha generado el informe de pruebas. Si los resultados no son satisfactorios, se modifica el cdigo y se vuelve a realizar la prueba. Si se detecta un fallo de especificacin o diseo, el proyecto se actualizar segn el procedimiento establecido para ello.

 C-F1-3: Deben realizarse las pruebas de integracin para asegurar

que las interfases entre los componentes o mdulos funcionan correctamente.

Las pruebas de integracin se han llevado a cabo segn lo especificado en el plan de pruebas realizado en el mdulo de diseo. Se han evaluado las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizandose el proyecto en consecuencia.
No han participado los usuarios. En las pruebas de integracin solo debe participar el equipo de desarrollo.

C-G1-1 : El desarrollo de los componentes de usuario debe estar planificado.

En el plan del proyecto esta incluido el plan para el desarrollo de los procedimientos de usuario e incluye todas las actividades y recursos necesarios. Los procedimientos se llevan a cabo despus de tener la especificacin funcional del y antes de la implantacin del mismo.

C-G1-2: Se deben especificar los perfiles de usuario requeridos para el nuevo sistema.

Estn definidos los perfiles de usuario requeridos para la implantacin y explotacin del nuevo sistema.
Para cada perfil se ha definido el rango de fechas y la dedicacin necesaria.

C-G1-3 : Se deben desarrollar todos los procedimientos de usuario con arreglo a los estndares del rea.

Estn desarrollados todos los procedimientos de usuario son congruentes y se consignan en el manual de usuario. Cada procedimiento describe que realiza, el perfil de usuario asociado asi como los recursos asociados. Los manuales de usuario y el resto de procedimientos cumplen los estandares del rea y llevan asociado su control de versiones.

C- G1-4 : A partir de los perfiles actuales de los usuarios, se deben definir

sus procesos de formacin o seleccin de personal necesarios

La comparacin de perfiles de usuarios y recursos requeridos con los actuales es realista y los procedimientos que se derivan son adecuados y estn aprobados por los responsables de las reas afectadas. Los procedimientos de formacin estn individualizados y se adaptan a cada persona, y se le ha comunicado a cada usuario el plan de formacin que seguir. Se han definido y preparado los recursos necesarios para impartir la capacitacin.

C-G1-5 : Se deben definir los recursos materiales necesarios para el trabajo de los usuarios con el nuevo sistema.

Se han determinado los recursos necesarios para cada usuario ( consumibles, perifricos especiales, espacio, etc.).
Se han comparado con los recursos existentes y se ha planificado el alquiler, leasing, adquisicin, etc. de los recursos no disponibles dentro del plazo.

C-H1-1 : Se deben realizar las pruebas del sistema que se especificaron en el diseo del mismo.

Se prepare el entorno y los recursos necesarios par realizar las pruebas. Las pruebas se realizan y permiten verificar si el sistema cumple las especificaciones funcionales y si interacta correctamente con el entorno, incluyendo interfases con otros programas, recuperacin ante fallos, copias de seguridad, tiempos de respuesta,etc.

Se han evaluado los resultados de las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia.

C-H1-2 : El plan de implantacin y aceptacin se debe revisar para

adaptarlo a la situacin final del proyecto.

Se revisa el plan de implantacin original y se documenta adecuadamente.

Esta incluida la instalacin de todos los componentes desarrollados, as como los elementos adicionales (libreras, utilidades, etc.). Incluye la inicializacin de datos y la conversin si es necesaria.

Especifica los recursos necesarios para cada actividad, as como el orden marcado para las actividades es compatible.
Se ha tenido en cuenta la informacin histrica sobre estimaciones.

C-H1-3 : El sistema debe ser aceptado por los usuarios antes de ponerse en operacin.

Se sigue el plan de pruebas de aceptacin aprobado en la fase de anlisis, que debe incluir la conversin de datos y la explotacin.

Las pruebas de aceptacin son realizadas por los usuarios.

Se evalan los resultados de las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. El grupo de usuarios y el comit de direccin firman su conformidad con las pruebas de aceptacin.

C-H2-1 : Se deben instalar todos los procedimientos de explotacin.

Se han instalado adems del sistema principal todos los procedimientos auxiliares, por ejemplo copias, recuperacin, etc., tanto manuales como automticos. Estn documentadas de forma correcta.

Los usuarios han recibido la formacin necesaria y tienen en su poder toda la documentacin necesaria, fundamentalmente manuales de usuario.
Se han eliminado procedimientos antiguos que sean incompatibles con el nuevo sistema.

C-H2-2 : Si existe un sistema antiguo, en sistema nuevo se pondr en operacin de forma coordinada con la retirada del antiguo, migrando los datos si es necesario.

Hay un funcionamiento en paralelo de los dos sistemas, hasta que el nuevo sistema este funcionando con todas las garantas. Esta situacin no debe prolongarse mas tiempo del necesario. Si el sistema antiguo se va a mantener para obtener informacin se debe dejar en explotacin en modo de solo consulta.

Los datos se convierten de acuerdo al procedimiento desarrollado y se verifica la consistencia de la informacin entre el sistema nuevo y el antiguo.

C-H2-3 : Debe firmarse el final de la implantacin por parte de los usuarios.

Existe el documento y ha sido firmado por el comit de direccin y por el grupo de usuarios. Contiene de forma explicita la aceptacin de la implantacin correcta del sistema.

C-H2-4 : Se debe supervisar el trabajo de los usuarios con el nuevo sistema en las primeras semanas para evitar situaciones de

abandono en el uso del sistema.

El ndice de utilizacin del sistema es adecuado a los volmenes que se esperaban para cada una de las reas afectadas por el nuevo sistema. Se ha comprobado, al menos informalmente, la impresin de los usuarios respecto al nuevo sistema.

C-H2-5 : Para terminar el proyecto se pondr en marcha el mecanismo de mantenimiento.

El mecanismo existe y esta aprobado por el director del proyecto, por el comit de direccin y por el rea de mantenimiento, si esta existiese.
Tienen encuentra los tiempos de respuesta mximos que se pueden permitir ante situaciones de no funcionamiento El procedimiento a seguir ante cualquier problema o para el mantenimiento del sistema, ser conocido por todos los usuarios. Incluir al menos la persona de contacto, telfono, esquema de la informacin a aportar, etc.

BIBLIOGRAFIA

AUDITORIA INFORMATICA UN ENFOQUE PRACTICO MARIO G. PRATTINI EMILIO DEL PESO EDITORIAL ALFA OMEGA AUDITORIA EN INFORMATICA UN ENFOQWUE METODOLOGICO ENRIQUE HERNANDEZ HERNANDEZ EDITORIAL CECSA REINGENIERIA DE LA AUDITORIA INFORMATICA GUSTAVO ADOLFO SOLIS MONTES EDITORIAL CISA

 INSTITUTO NACIONAL DE ADMINISTRACION PUBLICA (INAP) ESPECIALIZACION EN ALTA DIRECCION EN INFORMATICA GUBERNAMENTAL ING. ANTONIO QUIONES FEBRERO 17 2000