Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

AUDITORIA DEL DESARROLLO

No description
by

diego fernando fernandez

on 8 April 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of AUDITORIA DEL DESARROLLO

AUDITORIA DEL DESARROLLO
La auditoría del desarrollo trata de verificar la existencia y aplicación de procedimientos de control adecuados que permitan garantizar que el desarrollo de sistemas de información se ha llevado a cabo según estos principios de Ingeniería, o por el contrario, determinar las deficiencias existentes en este sentido.
IMPORTANCIA DE LA AUDITORIA DE DESARROLLO
Los avances en tecnologías de los computadores han hecho que actualmente el desafío más importante y el principal factor de éxito de la informática sea la mejora de la calidad del software.
El gasto destinado a software es cada vez superior al que se dedica a hardware.
El software como producto es muy difícil de validar. Un mayor control en el proceso de desarrollo incrementa la calidad del mismo y disminuye los costos de mantenimiento.
El índice de fracasos en proyectos de desarrollo es demasiado alto, lo cual denota la inexistencia o mal funcionamiento de los controles en este proceso.
Las aplicaciones informáticas, que son el producto principal obtenido al final del desarrollo, pasan a ser la herramienta de trabajo principal de las áreas informatizadas, convirtiéndose en un factor esencial para la gestión y la toma de decisiones.

PLANTEAMIENTO Y METODOLOGIA
Las funciones que tradicionalmente se asignan al área de desarrollo son:
• Planificación del área y participación, en la medida que corresponda, en la elaboración del plan estratégico de informática.
• Desarrollo de nuevos sistemas.

• Estudio de nuevos lenguajes, técnicas, metodologías, estándares, herramientas, etc. Relacionados con el desarrollo y adopción de los mismos cuando se considere oportuno para mantener un nivel de vigencia adecuado a la tecnología del momento.
• Establecimiento de un plan de formación para el personal adscrito al área.
• Establecimiento de normas y controles para todas las actividades que se realizan en el área y comprobación de su observancia.

Esta auditoría se desglosa en dos grandes apartados:

• Auditoría de la organización y gestión del área de desarrollo.
• Auditoría de proyectos de desarrollo de sistemas de información.

Para cada objetivo de control se especifican una o más técnicas de control también denominadas simplemente controles, que contribuyan a lograr el cumplimiento de dicho objetivo. Además, se aportan una seria de pruebas de cumplimiento que permitan la comprobación de la existencia y correcta aplicación de dichos controles.
El esquema para cada objetivo de control es:
Los objetivos de control se agrupan en varias series:

-Organización y gestión del área de desarrollo
(serie A)
-Proyectos de desarrollo de sistemas de información
Aprobación, Planificación Y Gestión Del Proyecto.
(serie B)
-Análisis
Análisis de requisitos
(serie C)
Especificación funcional
(serie D)
-Diseño
Diseño técnico
(serie E)
-Construcción
Desarrollo de componentes
(serie F)
Desarrollo de procedimientos de usuario
(serie G)
-Implantación
Pruebas, implantación y aceptación
(serie H)


AUDITORIA DE LA ORGANIZACIÓN Y GESTIÓN DEL ÁREA DE DESARROLLO
Aunque cada proyecto de desarrollo tenga entidad propia y se gestione con cierta autonomía, para poderse llevar a efecto necesita apoyarse en el personal del área y en los procedimientos establecidos.
Objetivo de Control A1:

Cometidos asignados dentro del departamento y una organización.

C-A1-1:
Funciones del área de desarrollo dentro del departamento de informática.
C-A1-2:
Organigrama con la relación de puestos del área, así como el personal y el puesto que ocupa.
C-A1-3:
Plan a corto, medio y largo plazo.
C-A1-4
: Control presupuestario.

Objetivo de Control A2:
Formación adecuada y estar motivado para la realización de su trabajo.

C-A2-1:
Procedimientos de contratación
C-A2-2:
Plan de formación de acuerdo con los objetivos tecnológicos que se tengan en el área
C-A2-3:
Protocolo de recepción/abandono para las personas que se incorporan o dejan el área
C-A2-4:
Biblioteca y una hemeroteca accesible para el personal
C-A2-5:
Motivación en la realización del personal en su trabajo

Objetivo de Control A3:
Existencia de un plan de sistemas, los proyectos que se lleven a cabo se basarán en dicho plan y lo mantendrán actualizado.

C-A3-1:
Realización de nuevos proyectos debe basarse en el plan de sistemas
C-A3-2:
Actualización del Plan de Sistemas a lo largo de un proceso de desarrollo
Objetivo de Control A4:
Realización de propuestas y aprobaciones de nuevos proyectos de forma reglada.

C-A4-1:
Procedimiento para la realización de nuevos proyectos.
C-A4-2:
Procedimiento de aprobación de nuevos proyectos que dependerá de que existe o no plan de sistemas.
Objetivo de Control A5:
Asignación reglada de recursos a los proyectos.
C-A5-1:
Procedimiento para designar director y equipo de desarrollo
C-A5-2:
Procedimientos para conseguir recursos materiales necesarios para el proyecto

Objetivo de Control A6:
El desarrollo de sistemas de información debe hacerse aplicando principios de Ingeniería del software.

C-A6-2:
Debe existir un mecanismo de creación y actualización de estándares, así como estándares ya definidos para las actividades principales. Se prestará principal atención a las herramientas y lenguajes de programación no clásicas.
C-A6-1:
Sistemas de Información soportada por herramientas de ayuda (CASE).
C-A6-3:
Los lenguajes, compiladores, herramientas CASE, software de control de versiones, etc. Usados en el área deben ser previamente homologados.
C-A6-4:
Debe practicarse la reutilización del software
C-A6-5:
Debe existir un método que permita catalogar y estimar los tiempos de cada una de las fases de los proyectos.
C-A6-6:
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 tienen que producirse de acuerdo a un procedimiento
C-A7-1
: Deben mantenerse contactos con los proveedores para recibir información suficiente sobre productos que pueden ser de interés.
C-A7-2:
Debe existir un protocolo para contratación de servicios externos
Objetivo De Control A8
La organización del área debe ser siempre adaptada a las necesidades de cada momento.
C-A8-1:
La organización debe revisarse de forma regular.
Cada desarrollo de un nuevo sistema de información será un proyecto con entidad propia, tendrá objetivos marcados y afectará a determinadas unidades de la organización. Debe tener un responsable y ser gestionado con técnicas que permitan conseguir los objetivos marcados.
Auditoría De Proyectos De Desarrollo De S.I
La auditoría de cada proyecto de desarrolló tendrá un plan distinto dependiendo de los riesgos. La complejidad del mismo y los recursos disponibles para realizar la auditoría. Esto obliga que sea la experiencia del auditor las que determinen las actividades del proyecto.
Se definirán los objetivos y técnicas de control más importantes en función de las características del proyecto y de la fase a auditar.
La aprobación del proyecto es un hecho previo al comienzo del mismo, mientras que la gestión se aplica a lo largo de su desarrollo.
La planificación se realiza antes de iniciarse, pero sufrirá cambios a medida que el proyecto avanza en el tiempo.
La auditoría de un proyecto de desarrollo se puede hacer en dos momentos distintos: a medida que avanza el proyecto, o una vez concluido el proyecto; La única diferencia es que el primer caso las conclusiones que vaya aportando el auditor pueden afectar al desarrollo del proyecto, aunque nunca participará en la toma de decisiones del mismo.
Aprobación, Planificación Y Gestión Del Proyecto.
Objetivo De Control B1
El proyecto de desarrollo debe estar aprobado, definido y planificado formalmente.

C-B1-1:
Debe existir una orden de aprobación 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 función de sus características, 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 técnico que realizará el proyecto y se determinará el plan del proyecto.
Objetivo De Control B2
El proyecto se debe gestionar de forma que se consignan los mejores resultados posibles teniendo en cuenta las restricciones de tiempo y recurso.

C-B2-1:
Los responsables de las unidades o áreas afectadas por el proyecto deben participar en la gestión del proyecto.
C-B2-2:
Se debe establecer un mecanismo para la resolución 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 el finalizar un módulo 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 siguen las etapas del ciclo de vida adoptado para el proyecto y que se generan todos los documentos asociados a la metodología usada.
C-B2-7:
Cuando el proyecto se debe cerrar toda la documentación del mismo, liberar los recursos empleados y hacer balance.

La fase de análisis pretende obtener un conjunto de especificaciones formales que describan las necesidades de información que deben ser cubiertas por el nuevo sistema de una forma independiente del entorno técnico.
AUDITORÍA DE LA FASE DE ANÁLISIS
En este módulo se identificarán los requisitos del nuevo sistema. Se incluirán tanto los requisitos funcionales como los no funcionales, distinguiendo para cada uno de ellos su importancia y prioridad.
A partir del conocimiento del sistema actual y sus problemas asociados, junto con los requisitos que se exigirán al nuevo sistema, se determinarán las posibles soluciones alternativas que satisfagan esos requisitos y de entre ellas se elegirá la más adecuada
Análisis De Requisitos Del Sistema (ARS)
OBJETIVO DE CONTROL C1
Los usuarios y responsables de las unidades a las que afecte el nuevo sistema establecerán 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 participación, que se hará normalmente a través de entrevistas, tendrá especial importancia en la definición 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 cómo valoran el sistema actual y lo que esperan del nuevo sistema.
C-C1-3:
A partir de la información obtenida en las entrevistas, se debe documentar el sistema actual así como los problemas asociados al mismo. Se debe obtener también un catálogo 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 DE CONTROL C2
En el proyecto de desarrollo se utilizará la alternativa más favorable para conseguir que el sistema cumpla los requisitos establecidos
C-C2-1:
Dados los requisitos del nuevo sistema se deben definir las diferentes alternativas de construcción con sus ventajas e inconvenientes. Se evaluarán las alternativas y se seleccionará la más adecuada.
C-C2-2:
La actualización del plan de proyecto seguirá los criterios ya comentados.
Una vez conocido el sistema actual, los requisitos del nuevo sistema y la alternativa de desarrollo más favorable, se elaborará una especificación funcional detallada del sistema que sea coherente con lo que se espera de él. La participación de los usuarios en este módulo y la realización de entrevistas siguen las pautas ya especificadas en el análisis de requisitos del sistema, por lo que se pasa por alto la comprobación de estos aspectos. El grupo de usuarios y los responsables de las unidades afectadas deben ser la principal fuente de información
ESPECIFICACIÓN FUNCIONAL DEL SISTEMA (EFS)
Objetivo De Control D1
El nuevo sistema debe especificarse de forma completa desde el punto de vista funcional, contando esta especificación con la aprobación de los usuarios.
C-D1-1:
Se debe realizar un modelo lógico del nuevo sistema, incluyendo Modelo Lógico de Procesos (MLP) y Modelo Lógico 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 distintos usuarios. Ésta es la parte más importante para el usuario porque definirá su forma de trabajo con el sistema.
C-D1-4:
La especificación del nuevo sistema incluirá los requisitos de seguridad, rendimiento, copias de seguridad y recuperación, etc.
C-D1-5:
Se deben especificar las pruebas que el nuevo sistema debe superar para ser aceptado.
C-D1-6
: La actualización del plan de proyecto seguirá los criterios ya comentados, detallándose en este punto en mayor medida la entrega y transición al nuevo sistema.
AUDITORÍA DE LA FASE DE DISEÑO

En la fase de diseño se elaborará el conjunto de especificaciones físicas del nuevo sistema que servirán de base para la construcción del mismo.

A partir de las especificaciones funcionales, y teniendo en cuenta el entorno tecnológico, se diseñará la arquitectura del sistema y el esquema externo de datos. Se considera un único objetivo de control
DISEÑO TÉCNICO DEL SISTEMA (DTS)
Objetivo De Control E1
Se debe definir una arquitectura física para el sistema coherente con la especificación funcional que se tenga y con el entorno tecnológico elegido.

C-E1-1:
El entorno tecnológico debe estar definido de forma clara y ser conforme a los estándares del departamento de informática
C-E1-2
: Se deben identificar todas las actividades físicas a realizar por el sistema y descomponer las mismas de forma modular.
C-E1-3:
Se debe diseñar la estructura física de datos aceptando las especificaciones del sistema al entorno tecnológico.
C-E1-4:
Se debe diseñar un plan de pruebas que permita la verificación de los distintos componentes del sistema por separado, así como el funcionamiento de los distintos subsistemas y del sistema en conjunto
C-E1-5
: La actualización del plan de proyecto seguirá los criterios ya comentados.
En esta fase se programarán y probarán los distintos componentes y se pondrán en marcha todos los procedimientos necesarios para que los usuarios puedan trabajar con el nuevo sistema. Estará basado en las especificaciones físicas obtenidas en la fase de diseño.
AUDITORÍA DE LA FASE DE CONSTRUCCIÓN
Desarrollo de los Componentes del Sistema (DCS)
En este módulo se realizarán los distintos componentes, se probarán tanto individualmente como de forma integrada, y se desarrollarán los procedimientos de operación.
Objetivo de control F1
Los componentes o módulos deben desarrollarse usando técnicas de programación correctas.

C-F1-1:
Se debe preparar adecuadamente el entorno de desarrollo y de pruebas, así como los procedimientos de operación, antes de iniciar el desarrollo.
C-F1-2:
Se debe programar, probar y documentar cada uno de los componentes identificados en el diseño del sistema
C-F1-3:
Debe de realizarse las pruebas de integración para asegurar que las interfaces entre los componentes o módulos funcionan correctamente
En este módulo se definen los procedimientos y formación necesarios para que los usuarios puedan utilizar el nuevo sistema adecuadamente. Fundamentalmente se trata de la instalación, la conversión de datos y la operación/explotación.
Desarrollo de los Procedimientos de los Usuarios (DPU)
Objetivo de Control G1
Al término 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 estándares del área
C-G1-4:
A partir de los perfiles actuales de los usuarios, se deben definir los procesos de formación o selección de personal necesarios.
C-G1-5:
Se deben definir los recursos materiales necesarios para el trabajo de los usuarios con el nuevo sistema.

En esta fase se realizará la aceptación del sistema por parte de los usuarios, además de las actividades necesarias para la puesta en marcha

Auditoría de la fase de implantación
Pruebas, Implantación y Aceptación del Sistema (PIA)
Se verificará en éste módulo que el sistema cumple con los requisitos establecidos en la fase de análisis. Una vez probado y aceptado en explotación.
Objetivo de Control H1
El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en explotación.
C-H1-1:
Se deben realizar las pruebas del sistema que se especificaron en el diseño del mismo
C-H1-2:
El plan de implantación y aceptación se debe revisar para adaptarlo a la situación final del proyecto.
C-H1-3:
El sistema debe ser aceptado por los usuarios antes de ponerse en explotación.
Objetivo de Control H2
El sistema se pondrá en explotación formalmente y pasará a estar en mantenimiento sólo cuando haya sido aceptado y esté preparado todo el entorno en el que se ejecutará
C-H2-1:
Se deben instalar todos los procedimientos de explotación.
C-H2-2:
Si existe un sistema antiguo, el sistema nuevo se pondrá en explotación de forma coordinada con la retirada del antiguo, migrando los datos si es necesario.
C-H2-3:
Debe firmarse el final de la implantación 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 de uso del sistema.
C-H2-5:
Para terminar el proyecto se pondrá en marcha el mecanismo de mantenimiento.
Metodología SCRUM
Scrum es un proceso para el desarrollo de software que aplica un conjunto de buenas prácticas para trabajar colaborativamente por medio de iteraciones logrando obtener el mejor resultado y valor al proyecto.
Full transcript