curso: auditoria y control de tecnologia de … · 2019. 7. 8. · 3. modelo de auditoria para el...
TRANSCRIPT
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 [email protected]