UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA

CURSO: AUDITORIA Y CONTROL DE TECNOLOGIA DE INFORMATICA

(SESION 12)

Profesor: Mg. Mario Huapaya Chumpitaz

INDICE

UNIDAD III: Tipos de Auditoria

1. Conceptos de Auditoria, Desarrollo y Mantenimiento2. Estrategias y Diseño de Desarrollo de Sistemas3. Modelo de auditoria para el Desarrollo y Mantenimiento4. Auditoria de Desarrollo y Mantenimiento de Sistemas5. Auditoria de Adquisición de Software6. Plan de Auditoria de Desarrollo de Aplicaciones Informáticas 7. Caso practico

1. Concepto de Auditoria, Desarrollo y Mantenimiento

Auditoría de Sistemas de Información:Es la revisión técnica, especializada y exhaustiva que se realiza alos sistemas computacionales, software e información utilizadosen una empresa, sean individuales, compartidos y/ o de redes,así como sus instalaciones, telecomunicaciones, mobiliario,equipos periféricos y demás componentes

1. Concepto de Auditoria, Desarrollo y Mantenimiento

1. Concepto de Auditoria, Desarrollo y Mantenimiento

1. Concepto de Auditoria, Desarrollo y Mantenimiento

1. Concepto de Auditoria, Desarrollo y Mantenimiento

Auditoría de Desarrollo de Proyectos: Ciclo de vida de los sistemas Se utiliza metodología de desarrollo de Proyectos informáticos. Exigente control interno de todas las fases antes nombradas. Seguridad de los programas, Hacen la función prevista

1. Concepto de Auditoria, Desarrollo y Mantenimiento

Auditoría en Desarrollo de Sistemas

Que entendemos por desarrollo de sistemas.?

Podemos definir el desarrollo de sistemas informáticos como elproceso mediante el cual el conocimiento humano y el uso delas ideas son llevados a las computadoras; de manera quepueda realizar las tareas para la cual fue desarrollada.

Para que esto sea utilizado deberán, funcionar adecuadamente,ser de fácil manejo, adecuarse a la empresa para la que fuédiseñada y debe ayudar al personal a realizar su trabajo deforma eficiente.

1. Concepto de Auditoria, Desarrollo y Mantenimiento

Auditoría en Desarrollo de SistemasEs la revisión y la evaluación de los controles, sistemas,procedimientos de informática; de los equipos de cómputo, suutilización, eficiencia y seguridad, de la organización queparticipan en el procesamiento de la información, a fin de quepor medio del señalamiento de cursos alternativos se logre unautilización más eficiente y segura de la información que servirápara una adecuada toma de decisiones.

1. Concepto de Auditoria, Desarrollo y MantenimientoAuditoría en Desarrollo de SistemasSus funciones son: Revisión de las metodologías utilizadas en el desarrollo de sistemas. Verificar el Control interno de las aplicaciones Verificar la satisfacción de usuarios con el sistema Verificar el Control de procesos del sistema Revisar las ejecuciones de programas críticos Participación del auditor en el desarrollo de sistemas Hacer Solicitudes al Usuario: Conocer y verificar la necesidad y sus objetivos. Hacer el Estudio de Factibilidad: Conocer el dictamen que justifica el proyecto. Planear la participación de la auditoria. Participar en el Análisis del Sistema: Determinar los controles que debe constar el

nuevo sistema. Participar en el Diseño del Sistema: Precisar que el proyecto sea acorde con las

necesidades del usuario y que cuente con los controles suficientes. Verificar la Programación: Definir que el programa contemple todos los controles

analizados anteriormente. Revisión de la Implantación: Probar el sistema con sus propios datos y con las

pruebas en paralelo que se realicen para garantizar la efectividad del sistema. Verificar la Documentación del Sistema: Constatar que la documentación se

conoce por los usuarios.

2. Estrategias y Etapas de Desarrollo de Sistemas

Estrategias Acción a Ejecutar

Desarrollo interno Consiste en diseñar, desarrollar e implantar elsistema completo con recursos internos.

Desarrollo externo Se contrata una empresa desarrolladora externaque se encargue de todas las labores relacionadascon el diseño y desarrollo completo.

Desarrollo mixto Bajo esta metodología las labores se llevan a cabocon recursos internos y la contratación de unaempresa externa que se encargue de ciertostrabajos asignados por el grupo interno.

Compra de paquetes Se trata de adquirir cualquier tipo de paquete, quecumpla con las necesidades de cada organización.

ETAPAS DE DESARROLLO DE SISTEMAS

2. Estrategias y Etapas de Desarrollo de Sistemas

ETAPAS DE DESARROLLO DE SISTEMAS

2. Estrategias y Etapas de Desarrollo de Sistemas

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

El Proceso de Auditoría según ISO 12207modelo de procesos de ISO 12207:

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

El Proceso de Auditoría según ISO 12207 Según la norma ISO 12207, el Proceso de Auditoría del

Software (PAS) es uno de los procesos de soporte. Se define como el proceso para determinar el cumplimiento

con los requerimientos, los planes o los contratos. Debe ser realizado por personas autorizadas con el propósito

de mantener una valoración independiente de los productos yprocesos del software.

Intervienen dos participantes: la parte auditora y la parteauditada.

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

El Proceso de Auditoría según ISO 12207Consta de dos actividades: Implementación del Proceso; y Auditoría.

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

El Proceso de Auditoría según ISO 12207Durante la Implementación del Proceso se realizan las siguientes tareas: Se realizarán auditorías de los hitos predeterminados en el plan del

proyecto. El personal auditor no tendrá responsabilidad directa sobre los productos

software y actividades auditados. Todos los recursos necesarios para realizar la auditoría deberán ser

acordados por las partes (incluyendo personal de apoyo, locales,infraestructura, hardware, software y herramientas).

Para cada auditoría las partes deberán acordar siguientes puntos: agenda;productos software (y resultados de alguna actividad) que seránrevisados; alcance y procedimientos de la auditoría; y criterios de entraday salida para la auditoría.

Los problemas descubiertos durante las auditorías se registrarán y sepasarán al Proceso de Resolución de Problemas.

Después de completar una auditoría, los resultados se documentarán y seproporcionarán a la parte auditada.

Las partes deberán acordar el resultado de la auditoría y cualquierresponsabilidad y criterio de cierre.

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

El Proceso de Auditoría según ISO 12207La actividad de auditoría propiamente dicha consta de una única tareatendente a garantizar que: Los elementos software (código, etc.) reflejan la documentación de

diseño. La revisión de aceptación y los requerimientos de prueba prescritos

por la documentación son adecuados para la aceptación de losproductos software.

Los datos de prueba cumplen con la especificación. Los productos software fueron suficientemente probados y sus

especificaciones cumplidas. Los informes de pruebas son correctos y las discrepancias entre

resultados actuales y esperados han sido resueltas. La documentación de usuario cumple los estándares especificados. Las actividades han sido conducidas de acuerdo con los

requerimientos, planes y contratos aplicables. Los costes y calendarios se ajustan a los planes establecidos.

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

La Metodología COBIT Control Objectives for Information and Related Technologies. Propuesta por la ISACF (Information Systems Audit and Control

Foundation). Es la principal propuesta metodológica realizada a nivel internacional

para abordar la Auditoría de Sistemas de Información. Supone un paso muy importante al considerar que, a efectos de

auditoría, el sistema de información de una organización es UNICO,aunque ciertos procesos se realicen de forma manual y otrosmediante el uso de la informática.

La filosofía de COBIT asimila los principios de reingeniería deempresas (BPR) y divide las funciones que ha de realizar un sistemade información en procesos que, a su vez, están subdivididos enactividades y tareas más simples.

Los sistemas de información están orientados a los procesos y portanto su auditoría se debe adaptar a estos conceptos.

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

La Metodología COBIT CobiT esta diseñado para ser utilizado por tres audiencias distintas:

Gestores:Para ayudarlos a lograr un balance entre los riesgos y las inversionesen control en un ambiente de Tecnologías de la Información (TI)frecuentemente impredecible. Usuarios:Para obtener una garantía en cuanto a la seguridad y control de losservicios de TI proporcionados internamente o por terceras partes. Auditores de Sistemas de Información:Para dar soporte a las opiniones mostradas a los Gestores sobre loscontroles internos.

También puede ser utilizado dentro de las empresas por elresponsable de un proceso de negocio en su responsabilidad decontrolar los aspectos de información del proceso, y por todosaquéllos con responsabilidades en el campo de las TI en las empresas.

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas

La Metodología COBITEl enfoque del control en TI se lleva a cabo visualizando la informaciónnecesaria para dar soporte a los procesos de negocio y considerando a lainformación como el resultado de la aplicación combinada de recursosrelacionados con las TI que deben ser administrados por procesos de TI.

3. Modelo de Auditoria para el Desarrollo y Mantenimiento de Sistemas: COBIT 5

Área de Desarrollo deProyectos

Revisión de Metodologíasusadas.

Control Interno de lasAplicaciones.

Satisfacción de Usuarios. Seguridad de Procesos y

Ejecución de Programas.

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Área de Desarrollo de ProyectosLa función de Desarrollo es una evolución del llamado Análisis yProgramación de Sistemas y Aplicaciones. A su vez, engloba muchasáreas, tantas como sectores informatizados tiene la empresa. Demanera resumida, una Aplicación recorre las siguientes fases: Prerequisitos del Usuario Análisis funcional Diseño Análisis orgánico (Preprogramación y Programación Pruebas Entrega a Explotación y alta para el Proceso.Estas fases deben estar sometidas a un exigente control interno, casocontrario, además del aumento de los costos, podrá producirse lainsatisfacción del usuario. Finalmente, la auditoría deberá comprobarla seguridad de los programas en el sentido de garantizar que losejecutados por la maquina sean exactamente los previstos y no otros.

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Revisión de las metodologías utilizadas:Una revisión obligada de las metodologías utilizadas, esdecir estas serán analizadas, para así asegurar lamodularidad de las nuevas ampliaciones de aplicación, asícomo también su mantenimiento.

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Control interno de las aplicaciones:Dentro del control interno se revisarán las mismas fases, lasmismas que han debido continuar en el área correspondiente dedesarrollo:

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Control interno de las aplicaciones:Dentro del control interno se revisarán las mismas fases, lasmismas que han debido continuar en el área correspondiente dedesarrollo:

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Satisfacción de usuarios:Una Aplicación técnicamente eficiente y bien desarrollada,deberá considerarse fracasada si no sirve a los intereses delusuario que la solicitó. La aquiescencia del usuarioproporciona grandes ventajas posteriores, ya que evitaráreprogramaciones y disminuirá el mantenimiento de laAplicación.

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Seguridad de Procesos y Ejecución de ProgramasOtro punto son los programas críticos a quienes hay que mantenerun control de procesos y ejecuciones: entonces el Auditor debetener la posibilidad de ejecutar un módulo el cual no correspondecon el programa fuente que desarrollo, codificó y probó en el áreade Desarrollo de Aplicaciones. La compilación debe corresponder alprograma codificado, de no ser así podrían provocar graves daños yaltos costos de mantenimiento, lo que también puede suceder esque se prestaría para fraudes y sabotajes, etc.

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Seguridad de Procesos y Ejecución de ProgramasCuando un programa se da por bueno entonces se sujeta a ciertasnormas que determinan el ser entregados a producción(explotación) con el fin de copiar el programa fuente en la libreríade fuentes de producción, ha esta librería nadie más tiene acceso.Después la compilación y el montaje del programa poniéndolo enla librería de módulos de explotación, a esta tampoco nadie tieneacceso, y por último hacer una copia de los programas fuente quese soliciten para modificarlos o en todo caso para ser arregladosuna vez hecho esto es necesario volver a verificar todo.

4. Auditoría de Desarrollo y Mantenimiento de Sistemas

Enfoques para encarar la auditoría del proceso de adquisición Evaluar el proceso de adquisición: Es decir determinar si la

adquisición del software fue realizada de acuerdo a prácticasrazonables para este tipo de procedimiento.

Evaluar el proyecto en forma integral: Aquí la revisión incluyeaspectos relacionados con el gerenciamiento y calidad delproyecto.

Evaluar el impacto del software adquirido en relación alnegocio: En este caso, además de los aspectos enunciadosanteriormente se incluye el análisis del ambiente del proyectoes decir que se evalúan otros aspectos tales como laexistencia de un plan de sistemas, nivel de integración dedicho plan con el plan estratégico de negocios, organizacióndel área de sistemas, etc.

5. Auditoria de la Adquisición de Software

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del Software

Etapas de Revisión

Revisión del Proyecto

Proceso de Adquisición

Seguimiento

Etapas de la revisión del proceso de adquisición del SoftwareRevisión del ProyectoAmbiente del Proyecto: Por ambiente del proyecto se entiende a todosaquellos aspectos, que si bien no se encuentran directamentevinculados, influyen sobre el mismo y permiten tener un primer gradode aproximación a cerca de la calidad del proyecto. Dentro de estosencontramos la posibilidad de verificar la existencia de un planestratégico de sistemas, la forma en que el proyecto es administrado, lametodología utilizada y el nivel tecnológico de la organización.

Impacto del Proyecto: El objetivo de medir el impacto del proyecto espara determinar los riesgos a los que se encuentra sometida laorganización al incorporar el software en cuestión. Es así que se deberevisar lo relacionado con el impacto sobre el esquema de negocios, elimpacto que implicaría un cambio tecnológico y el impacto que unnuevo sistema tendría sobre aspectos funcionales, es decir sobre losprocesos que se realizan en la organización.

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareRevisión del ProyectoAmbiente del Proyecto

Ambiente del Proyecto

Información sobre el ambiente

Plan Estrategico

De Sistemas

Administración

del

Proyecto

Metodología Tecnología

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareObjetivos de Control y Riesgos del AmbienteCuadro 1 - Objetivos de control Relacionados con Plan Estratégico de Sistemas

Plan Estratégico de Sistemas

Objetivo de Control Riesgos Asociados Verificaciones a Realizar

El Plan de sistemas contemplalas necesidadesorganizacionales y elcrecimiento del negocio y seencuentra adecuadamenteaprobado por la dirección y esperiódicamente revisado antecambios en la planificación dela organización.

Los sistemas no respondena las necesidades de laorganización.Inflexibilidad de lossistemas ante nuevosrequerimientosorganizacionales.Desvinculación entre losdistintos sistemas.

Existencia de un planformalizado y aprobadopor el nivel máximo de laorganización.Verificación de laactualización periódica delplan.

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareObjetivos de Control y Riesgos del AmbienteCuadro 2 -Objetivos de Control y Riesgos Asociados con la Administración delProyecto

Administración del Proyecto

Objetivo de Control Riesgos Asociados Verificaciones a Realizar

El proyecto se encuentraadecuamente definido yaprobado por la autoridadcompetente y se inserta enel plan de sistemas de laorganización.

El proyecto no fueadecuadamente aprobadoy formalizado

Mala integración entre losdistintos proyectos.

Descoordinación con lasáreas usuarias.

Existencia de undocumento (memorando onorma interna) donde seaprueba el proyecto

Existencia de un plan delárea de sistemas.

Existencia de un “proyect“donde se establecen losplazos y los recursosasignados.

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareObjetivos de Control y Riesgos del AmbienteCuadro 3 - Objetivos de Control y Riesgos Asociados con la Metodología

Administración del Proyecto

Objetivo de Control Riesgos Asociados Verificaciones a Realizar

Existe una metodología y lamisma se encuentraadecuadamenteformalizada.

No se aplica unametodología para eldesarrollo del proyecto

Existe documentada unametodología de trabajo.

La metodología abarca todoel proceso del ciclo de vidade los sistemas y contemplalos pasos para laadquisición de aplicaciones.

La metodología no abarcatodas la etapas deldesarrollo de sistemas.No existe una metodologíapara la adquisición deaplicaciones

Amplitud y alcance de lametodología utilizada.Existencia de unametodología para laadquisición de software.

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareImpacto del proyecto

Analisis del Impacto del

Proyecto

Tamaño del Proyecto

Negocio Tecnológico

Funcional

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareImpacto del proyectoEl principal riesgo está dado el tamaño del proyecto. Existendiversos factores que nos permiten establecer el tamaño delproyecto: Cantidad de áreas involucradas: La existencia de distintas

áreas con diversos intereses que deben ser satisfechos por elsistema.

Niveles organizacionales involucrados: Si el sistema va a serutilizado por más de un nivel de la organización debencontemplarse las necesidades de niveles gerenciales,gerencias medias y el nivel operativo.

Cantidad de Recursos Involucrados: Cantidad de personasque directa o indirectamente se encuentran vinculadas alproyecto y volumen de la inversión.

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareImpacto del proyectoImpacto en el negocio

Impacto en el Negocio

Tam

año

de

l P

roye

cto

Impacto en el proceso de Negocio

Bajo Alto

Gra

nd

e Riesgo Alto

Peligra la

supervivencia

Riesgo Medio

Problemas de

adminisración

Riesgo Bajo

Mala utilización

de recursos

Riesgo Medio

Demora en la

implementación

de negociosRe

ducid

o

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareImpacto del proyectoImpacto en el negocio

Alto impacto en el negocio y Proyecto Amplio – Alto Riesgo: Eneste caso se trata de un proyecto de alto impacto en el negocio yde una alta complejidad importante dada su tamaño.

Alto impacto en el negocio y Proyecto reducido – Riesgo Medio:La variante respecto del caso anterior es que el grado decomplejidad o tamaño del proyecto en este caso es reducida locual permitiría por un lado contar con mayores posibilidades deéxito en la administración del proyecto y en caso de existirinconvenientes es más fácil atacarlos

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareImpacto del proyectoImpacto en el negocio

Bajo Impacto en el negocio y Proyecto Amplio – Riesgo Medio:En este caso se trata de un proyecto de alta complejidad pero queno tiene un impacto alto sobre el negocio.

Bajo Impacto en el Negocio y Proyecto Reducido – Riesgo Bajo:En este caso se trata de proyecto de menor relevancia que noafectará la continuidad del negocio. En este punto el riesgo estadado por la mala utilización de los fondos destinados al proyecto.

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareObjetivos de Control y Riesgos asociados con el Impacto en el NegocioCuadro 4– Objetivos de Control y Riesgos Asociados con el Impacto en el Negocio

Impacto en el Negocio

Objetivo de Control Riesgos Asociados Verificaciones a Realizar

El proyecto se encuentradentro del marco del plande negocios de la empresa.

Los sistemas no respondena las necesidades delnegocio.

El plan estratégico desistemas es coordinado conel plan de negocios.

Las especificacionesestablecidas contemplanlos factores esenciales delnegocio.

La habilidades propias delnegocio no se encuentranapoyadas por los nuevossistemas.

En la documentación de losrequerimientos seidentifican las habilidadesprincipales que distinguen ala empresa.

El sistema tiene lacapacidad de adaptarse anuevas reglas del negocio.

El sistema se muestrainflexible ante nuevoscambios.

Se ha previsto que el o lossistemas seanparametrizables y flexiblespara adaptarse a loscambios.

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del Software

Etapas de Revisión

Revisión del Proyecto

Proceso de Adquisición

Seguimiento

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareRevisión del Proceso de Adquisición e Implantación

Proceso de Adquisición

Revisión del

requerimiento

Revisión de la

especificación

Revisión

Proceso

selección

Revisión

Proceso de

customización

Revisión de

pruebas

e instalación

Revisión de la

Entrega

5. Auditoria de la Adquisición de Software

Etapas de la revisión del proceso de adquisición del SoftwareObjetivos de Control y Riesgo de la Etapa de Revisión de los RequerimientosCuadro 5 – Objetivos de Control y Riesgos – Etapa Revisión del Requerimiento

Revisión de los requerimientos

Objetivo de Control Riesgos Asociados Verificaciones a Realizar

Se han establecido enforma clara todos losrequerimientos de todoslos usuarios.

El sistema no contemplatodas las necesidades delos sectores usuarios.Las necesidades deinformación de los nivelesdirectivos no se encuentrantotalmente cubiertas.El sistema no contemplaaspectos de control internoEl sistema no contemplaaspectos legales onormativos propios de laactividad de la organización

Existe un documentoadonde se establecencuales son los usuarios querepresentan a cada sector.Existe un documento dondese establece como serealizará el contacto con losáreas usuarias.Se ha analizado el sistemaactual y se han identificadolas fortalezas y debilidadesdel mismo.

5. Auditoria de la Adquisición de Software

6. Plan de Auditoria de desarrollo de aplicaciones I.

Objetivos Revisar el cumplimiento del proceso completo de desarrollo

de proyectos Verificar las metodologías utilizadas Verificar el control interno de las aplicaciones, satisfacción de

los usuarios y control de procesos y ejecuciones de programascríticos.

Revisar el ciclo de desarrollo del software.

N° PREGUNTAS SI NO N/A

1 ¿Existe el documento que contiene las funcionesque son competencia del área de desarrollo, estaaprobado por la dirección de informática y serespeta?

X

2 ¿Existe un manual de organización que regula lasrelaciones entre puestos?

X

3 ¿El presupuesto esta en concordancia con losobjetivos a cumplir?

X

4 ¿El personal de área de desarrollo cuenta con laformación adecuada y son motivados para larealización de su trabajo?

X

5 ¿Las personas seleccionadas cumplen losrequisitos del puesto al que acceden?

X

6. Plan de Auditoria de desarrollo de aplicaciones I.

N° PREGUNTAS SI NO N/A

6 ¿Existe rotación de personal y existe un buenambiente de trabajo?

X

7 ¿La realización de nuevos proyectos se basa en elplan de sistemas en cuanto a objetivos?

X

8 ¿Existe un procedimiento para asignar director yequipo de desarrollo a cada nuevo proyecto?

X

9 ¿Se tiene implantada una metodología dedesarrollo de sistemas de información soportadapor herramientas de ayuda?

X

10 ¿La metodología cubre todas las fases deldesarrollo y es adaptable a distintos tipos deproyectos?

X

11 ¿La metodología y las técnicas asociadas a lamisma están adaptadas al entorno tecnológico y ala organización del área de desarrollo?

x

6. Plan de Auditoria de desarrollo de aplicaciones I.

Importancia de la auditoría del área de desarrollo: Los avances en tecnología de los computadores han hecho

actualmente el principal factor de éxito de la información sea lamejora de la calidad del software.

El gasto destinado a software es cada vez más superior al que sedestina a hardware.

El software como producto es muy difícil de validar. Por elloincrementar la calidad del software y disminuir los costes demantenimiento debemos proporcionar un mayor control en elproceso de desarrollo.

El índice de fracasos en proyectos de desarrollo es demasiadoalto, lo cual nos hace ver el mal o nulo funcionamiento de loscontroles en este proceso

Las aplicaciones informáticas, que son el producto principalobtenido al final del desarrollo, pasan a ser la herramienta detrabajo principal de las áreas informatizadas, convirtiéndose enun factor esencial para la gestión y la toma de decisiones.

6. Plan de Auditoria de desarrollo de aplicaciones I.

Características de un sistema de control1. Establecimiento de estándares, normas o necesidades, esto incluiría definircon detalle la precisión con la que se deben medir las necesidades.2. El registro del rendimiento real. Estos registros van a clasificar la informaciónde manera que se adapta a la ordenación de objetivos que se haya fijado.3. La comparación periódica del rendimiento con los objetivos.4. Informes de excepción, que notifiquen y expliquen las diferencias que existenentre los objetivos y el rendimiento durante ese período.5. Acciones correctoras que obliguen a que las actividades vuelvan a obedecerlas pautas exigidas. Existen tres tipos posibles de acciones correctoras:a. repetir la operación después de eliminar la causa del error, para que se

ejecute correctamente.b. asegurarse de que en el futuro las cosas vayan según los planes, pero

aceptando que no se puede modificar lo sucedido y que el error se va aquedar sin corregir, y

c. ajustar las necesidades en un futuro próximo de modo que sed. cumplan los objetivos generales durante un periodo de tiempo restante,

aunque no sea posible alterar lo que haya ocurrido ya.6. El repaso conjunto de estándares, para utilizarlos en el futuro.

6. Plan de Auditoria de desarrollo de aplicaciones I.

Objetivos de control, y guías o técnicas de control del área dedesarrollo de aplicaciones informáticasTodos los objetivos de control tareas que la organización deberealizar y tener controladas para que se realicen de la maneraadecuada. Para el auditor, estos objetivos de control son lasexpectativas que tiene acerca del proyecto, que si no se cumplense introducirán en el informe que eleve a la dirección. Para cadauno de estos objetivos de control se especificará una o más guíasde auditoría o técnicas de control, mediante estas guías el auditorpretende averiguar si los objetivos mencionados anteriormente secumplen con exactitud.

6. Plan de Auditoria de desarrollo de aplicaciones I.

Controles de desarrollo de aplicaciones informáticasEl proceso seguido por una organización en el desarrollo deaplicaciones informáticas debería tratar de alcanzar la efectividad,ahorro y eficiencia del sistema la integridad de datos, protecciónde recursos, y el cumplimiento de las leyes y regularizaciones. Eluso de una metodología de ciclo de vida de desarrollo deaplicaciones informáticas efectiva, debería proporcionar a la altadirección de la organización una razonable garantía de que estosobjetivos serán alcanzados.

6. Plan de Auditoria de desarrollo de aplicaciones I.

Controles de desarrollo de aplicaciones informáticasÁreas a controlar: La metodología y responsabilidades del proceso de desarrollo de

aplicaciones informáticas Las funciones y responsabilidades de cada individuo Proceso de actualización de la metodología que sigue la

organización en el proceso desarrollo de aplicacionesinformáticas

6. Plan de Auditoria de desarrollo de aplicaciones I.

6. Plan de Auditoria de desarrollo de aplicaciones I.

6. Plan de Auditoria de desarrollo de aplicaciones I.

7. Caso Practico

Muchas Gracias!!!mhuapaya.chu@gmail.com