Tema 6

Auditoria del Desarrollo

¿Qué es el Desarrollo de Sistemas?

Podemos definir el desarrollo de sistemas Informáticos como el

proceso mediante el cual el conocimiento humano y el

uso de las ideas son llevados a las computadoras, de

manera que pueda 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 fue diseñada y

debe ayudar al personal a realizar su trabajo de forma

eficiente.


Algunas consideraciones…

Ya que cada organización puede descomponerse funcionalmente en

departamentos, áreas, unidades, etc. es necesario que los

mecanismos de control interno existan y se respeten en cada

una de las divisiones funcionales para que éstas cumplan y

hagan posible que la organización en su conjunto funcione de

manera correcta.


Algunas consideraciones…

Aplicando la división funcional al departamento de informática de

cualquier entidad, una de las áreas que tradicionalmente aparece es

la de desarrollo. Esta función abarca todas las fases que se deben

de seguir desde que aparece la necesidad de disponer de un

determinado sistema de información hasta que éste es construido e

implantado.

Para delimitar el ámbito de este tema, se entenderá que el desarrollo

incluye todo el ciclo de vida del software excepto la explotación,

el mantenimiento y el fuera de servicio de las aplicaciones cuando

ésta tenga lugar.


Ciclo de vida típico de los Sistemas Informáticos

Auditoría

del

Desarrollo


Evaluación del estudio de factibilidad de los Sistemas

Informáticos

La primera etapa a evaluar del sistema es el estudio de factibilidad, el cual

debe analizar si el sistema es factible de realizarse, cuál es su relación

costo/beneficio y si es recomendable elaborarlo.

Se deberá solicitar el estudio de factibilidad de los diferentes sistemas a

desarrollar para evaluar si se considera la disponibilidad y características del

equipo, los sistemas operativos y lenguajes disponibles, la necesidad de los

usuarios, las formas de utilización de los sistemas, el costo y los beneficios que

reportará el sistema, el efecto que producirá en quienes lo usarán y el efecto

que éstos tendrán sobre el sistema y la congruencia de los diferentes sistemas.


Evaluación del estudio de factibilidad de los Sistemas

Informáticos

Para investigar el costo de un sistema se debe considerar, con una

exactitud razonable, el costo de los programas, el uso de los

equipos (compilaciones, programas, pruebas, paralelos), tiempo,

personal y operación, cosa que en la práctica son costos directos,

indirectos y de operación.

Los beneficios que justifiquen el desarrollo de un sistema pueden

ser el ahorro en los costos de operación, la reducción del tiempo de

proceso de un sistema. Mayor exactitud, mejor servicio, una

mejoría en los procedimientos de control, mayor confiabilidad y

seguridad.


Qué es Auditoría del Desarrollo?

Es la revisión y la evaluación de los:

controles,

sistemas,

procedimientos de informática de los equipos de

computo,

su utilización,

eficiencia, y

Seguridad de la organización que participan en el

procesamiento de la información,

A fin de que por medio del señalamiento de cursos alternativos se

logre una utilización más eficiente y segura de la información

que servirá para una adecuada toma de decisiones.


Campo de acción de la Auditoría del Desarrollo

Prerrequisitos del usuario y del entorno

Análisis funcional

Diseño

Análisis orgánico (pre-programación y

programación)

Pruebas

Entrega a explotación y alta para el proceso


Consideraciones de la Auditoría del Desarrollo

1. Revisión de las metodologías utilizadas.

2. Control interno de aplicaciones.

3. Satisfacción de usuarios

4. Control de procesos y ejecuciones de programas

críticos


Rol del auditor en la Auditoría del Desarrollo

Durante el desarrollo del proyecto el auditor debe participar en forma

activa para:

Evaluar el cumplimiento de cada una de las fases definidas

en la metodología como verificar la existencia de la

documentación resultante

Identificar y evaluar los controles de aplicación

Pruebas e implantación del nuevo sistema



En esta fase el auditor debe evaluar:

Los planes de prueba a ejecutar por el personal involucrado en el

proyecto

Alcance de las pruebas programadas incluyendo las interfaces con

otros sistemas

La documentación de las pruebas ejecutadas

La aprobación del personal usuario

El proceso de migración a la nueva aplicación, si este es el caso

El procedimiento definido para el montaje de la aplicación

El cumplimiento de los planes de capacitación técnica y de usuarios



Adicionalmente, en esta fase el auditor deberá:

Efectuar pruebas de cumplimiento y/o sustantivas orientadas a

comprobar lo adecuado de la implantación de los controles y

funcionalidad del sistema

Conformar un programa de auditoria para su aplicación posterior


IMPORTANCIA DE LA AUDITORÍA DE DESARROLLO

Aunque cualquier departamento o área de una organización es susceptible

de ser auditado, hay una serie de circunstancias que hacen

especialmente importante al área de desarrollo, y por tanto también de

auditoría, frente a otras funciones o áreas dentro del departamento de

informática:

1. Los avances en tecnologías de las computadoras han hecho que

actualmente el desafío más importante y el principal reto sea la calidad del

software

2. El gasto destinado a software es cada vez superior al que se dedica al

hardware



3. 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.

4. 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.

5. 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.



La participación de la auditoria de desarrollo contribuye a evitar o minimizar

los siguientes riesgos:

Los requerimientos del usuario no se satisfagan

Las pruebas de aceptación no sean adecuadas

La terminación de los proyectos o actividades no estén dentro del

tiempo y costo programado

No se establezca una metodología estándar de desarrollo, adquisición

o mantenimiento



No se incorporen controles de aplicación en los nuevos sistemas

No se integren herramientas de auditoría para verificar los controles

No se mantengan los controles administrativos para tener un proceso

metódico y disciplinado de desarrollo/adquisición/mantenimiento

El nuevo sistema de información no se integre adecuadamente a la

plataforma tecnológica de la empresa.


¿Cuál es la realidad de los proyectos TI?

En 2007 del total de lo proyectos de TI

monitoreados, sólo el 29% lo logró a

tiempo y en costo, los costos

promedio se excedieron 56% y en

promedio tomó 84% más de tiempo

para completarse.

Fuente: Over due and over budget, over and over again” The Economist


¿Cuál es la realidad de los Proyectos?

15% de los proyectos fracasan y son cancelados totalmente

51% no cumplen sus objetivos

42% en promedio por encima del presupuesto

82% no cumplen el cronograma

US $55.000 millones perdidos en proyectos sólo en USA

US $17.000 millones en sobrecostos


¿Por qué los Proyectos fallan?

Falta de comprensión del problema, visión ligera del alcance

Problemas tecnológicos y con proveedores

Problemas de comunicación y trabajo en equipo

Problemas de liderazgo

Problemas metodológicos. Falta de un proceso de

administración de proyectos.


PLANTEAMIENTO Y METODOLOGÍA.

Para tratar la auditoría de desarrollo es necesario, en primer lugar,

acotar las funciones o tareas que son responsabilidad del área.

Teniendo en cuenta que puede haber variaciones de una organización a

otra, las funciones que tradicionalmente se asignan al área son:

Planificación del área y participación 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. y adopción de los mismos para mantener un nivel de

vigencia adecuado al 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.


Una metodología aplicable es la propuesta por la ISACA (Information

Systems Audit and Control Association), que está basada en la evaluación

de riesgos partiendo de los riesgos potenciales a los que está sometida

una actividad (en este caso el desarrollo de un sistema de información), se

determinan una serie de objetivos de control que minimicen esos riesgos.

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 serie de pruebas

de cumplimiento que permitan la comprobación de la existencia y correcta

aplicación de dichos controles.



El esquema de un objetivo de control es:

Objetivo de Control X:

TC-X-1: Técnica de Control 1 del objetivo de Control X

Una vez definidos los objetivos de control, será función del auditor

determinar el grado de cumplimiento de cada uno de ellos. Para

cada objetivo se estudiarán todos los controles asociados al mismo,

usando para ello las pruebas de cumplimiento propuestas.



Con cada prueba de cumplimiento se obtendrá alguna evidencia, bien sea

directa o indirecta, sobre la corrección de los planes. Si una simple

comprobación no ofrece ninguna evidencia, será necesaria la realización

de exámenes más profundos.

En los controles en los que sea impracticable una revisión exhaustiva

de los elementos de verificación, bien porque los recursos de auditoría

sean limitados o porque el número de elementos a inspeccionar sea muy

elevado, se examinará una muestra representativa que permita inferir

el estado de todo el conjunto.



El estudio global de todas las conclusiones, pruebas y evidencias

obtenidas sobre cada control permitirán al auditor obtener el

nivel de satisfacción de cada objetivo de control, así como

cuáles son los puntos fuertes y débiles del mismo. Con esta

información y teniendo en cuenta las particularidades de la

organización en estudio, se determinará cuáles son los riesgos

no cubiertos, en qué medida lo son y qué consecuencias se

pueden derivar de esa situación. Estas conclusiones, junto con

las recomendaciones acumuladas, serán las que se plasmen en el

informe de auditoría.



Aspectos a tener en cuenta en una metodología de desarrollo de

sistemas

1. Documentación interna de los programas

Los programas deben estar debidamente documentados, para que

el mantenimiento de los mismos sea rápido y fácil sin tener que

depender de la persona que lo elaboró.

Los nombres de las variables, constantes, programas, tablas,

funciones y procedimientos deben ser mnemónicos, es decir que

reflejen la información que contienen.



1. Documentación interna de los programas (Cont.…)

Las variables y constantes deben cumplir los siguientes estándares :

₱ La longitud máxima de una variable debe ser de 15 caracteres.

₱ Todas la variables deben iniciar con la letra “v” que significa

variable y las constantes deben de iniciar con la letra “c” que

significa constante.

Por ejemplo:

* v_suma = es una variable que va a contener el total de una suma.

* c_iva = es una constante que va ha contener el porcentaje de

iva actual.




Los programas deben cumplir los siguientes estándares :

₱ Los nombres de los programas deben incluir las tres primeras

letras del sistema al que corresponde, en la quinta posición debe

colocarse una “p” que significa programa y además un nombre

mnemónico con un máximo de seis caracteres, para completar diez

caracteres para nombres de programas.

Por ejemplo :

nom_pdce1 = nómina, programa de la dirección de contabilidad del

estado versión uno




₱ Dentro de los programas se deben colocar comentarios generales

para describir cuales son las funciones que realiza, además de

documentar las variables y constantes existentes al inicio de cada

programa, con la finalidad de llevar a cabo modificaciones en forma

rápida y sin problemas.




₱ Cada programa debe tener un encabezado que describa

brevemente cual es la función que realiza, además de los siguientes

requisitos :


Nombre del proyecto.

Nombre de la institución .

Objetivo.

Lenguaje en que se realizó.

Dispositivos de salida.

Fecha de finalización.

Fecha de cambio.

Módulo al que pertenece.



Las tablas (Archivos) deben cumplir los siguientes estándares :

₱ Tener un nombre mnemónico.

₱ Tener un máximo de nueve caracteres.

₱ Crear procedimientos para efectuar modificaciones a las

tablas tales como agregar, eliminar y cambios generales en

los campos.




Las tablas (Archivos) deben cumplir los siguientes estándares :

₱ Las tablas existentes deben ser documentadas debidamente con el

propósito de tener una visión clara del contenido de cada uno de los

componentes de dicha tabla.

Ejemplo:

Nombre de la tabla : Empleado: Esta tabla contiene la información de

los empleados.

Campos: No. empleado = En este campo se guarda el correlativo que

diferencia a un empleado del otro;

Salario = Contiene el salario de cada empleado




Las funciones y procedimientos deben cumplir los siguientes estándares :

₱ Tener un nombre mnemónico.

₱ Incluir una breve descripción de las operaciones que realiza.

₱ Documentar las variables y constantes existentes.

₱ Todas las funciones y procedimientos deben estar estructurados.




Los nombres de programas, reportes, gráficas, formas, consultas en

sentencias SQL , deben tener 10 caracteres los cuales deben cumplir los

siguientes parámetros:

₱ Deben de colocarse en las tres primeras letras el nombre de la

aplicación, en la cuarta letra , colocar una de las siguientes

opciones:

P = programa • R = reporte • F = formas • G = gráficas • Q = query

(consultas SQL)

Las siguientes 6 letras describen la función que se realiza.



2. Documentación externa de los programas

Diseñar manuales de usuario para cada sistema elaborado y por realizarse, los

cuales deben cumplir los siguientes requerimientos :

₱ Diseño de pantallas.

₱ Guía de ayuda fácil de usar.

₱ Actual.

₱ Eminentemente práctica.

Diseñar un catalogo de errores con las siguientes características :

₱ Códigos de error

₱ Mensajes de error

₱ Breve descripción de errores

₱ Posibles causas y soluciones

Además todos los sistemas deben de poseer un flujograma para tener una visión

general de cada sistema.



1. Especificación de los

requerimientos del cliente

2. Análisis y plan de desarrollo

3. Diseño

4. Desarrollo 5. Pruebas y validación

6. Reproducción,

entrega e instalación

7. Mantenimiento

de sistemas

Fases de un ciclo de vida de desarrollo de

sistemas


Aprobación,

planificación

y gestión

del proyecto

Análisis

Diseño Construc

ción

Implantación

nta

Etapas del Desarrollo

de un Sistema


Proyectos de desarrollo de sistemas de información

1. Aprobación, planificación y gestión del proyecto

2. Análisis

Análisis de requerimientos

Especificación funcional

3. Diseño

Diseño técnico o de detalle

4. Construcción

Desarrollo de componentes

Desarrollo de procedimientos

5. Implantación

Pruebas, implantación y aceptación


Objetivos de Control a Auditar

OBJETIVO DE CONTROL: El área de desarrollo debe tener

responsabilidades asignadas dentro del departamento y una

organización que le permita el cumplimiento de las mismas.

Deben establecerse de forma clara las funciones del área de

desarrollo dentro del departamento de informática. Se debe

comprobar que:

Existe documento que contiene las funciones que son competencia

del área de desarrollo, que está aprobado por la dirección informática

y que se respeta.


Objetivos de Control a Auditar

OBJETIVO DE CONTROL: El desarrollo de sistemas de información debe

hacerse aplicando principios de ingeniería del software ampliamente

aceptados.

Debe tenerse implantada una metodología de desarrollo de sistemas de

información. Se debe comprobar que:

La metodología cubre todas las fases del desarrollo y es adaptable a

distintos tipos de proyectos.


Como se puede observar en el esquema de agrupación de objetivos

de control propuestos, dentro del desarrollo de sistemas de

información se han propuesto cinco subdivisiones, entre las cuales

se encuentran: análisis, diseño, construcción e implantación. Estas

fases, ampliamente aceptadas en ingeniería de software para el

desarrollo, son en concreto las que propone la metodología de

desarrollo de sistemas de información.


Además de estas fases, se ha añadido una subdivisión que contiene

los objetivos y técnicas de control concernientes a la aprobación,

planificación y gestión del proyecto. 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.


Las técnicas a utilizar y los elementos a inspeccionar, normalmente los

productos y documentos generados en cada fase del desarrollo, serán

los mismos en ambos casos. La única diferencia es que en el primer

caso las conclusiones que vaya aportando el auditor pueden afectar el

desarrollo del proyecto, aunque nunca participará en la toma de

decisiones.

Para controlar se pueden solicitar los entregables para marcar los hitos

de entrega, el cumplimiento de los objetivos de control de cada fase del

desarrollo.


Aprobación, planificación y gestión del proyecto.

OBJETIVO DE CONTROL: El proyecto de desarrollo debe estar

aprobado, definido y planificado formalmente.

Debe existir una orden de aprobación del proyecto que defina

claramente los objetivos, restricciones y las unidades afectadas. Se

debe comprobar que:

Existe una orden de aprobación del proyecto firmada por un órgano

competente.

En el documento de aprobación están definidos de forma clara y precisa

los objetivos del mismo y las restricciones de todo tipo que deben tenerse en

cuenta (temporales, recursos técnicos, recursos humanos, presupuesto,

etc.).

Se han identificado las unidades de la organización a las que afecta.


Auditoría de la fase de análisis

Análisis de requerimientos del Sistema

En este módulo se identificarán los requerimientos del nuevo sistema. Se

incluirán tanto los requerimientos 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 requerimientos que se exigirán al nuevo sistema, se

determinarán las posibles soluciones alternativas que satisfagan esos

requerimientos y de entre ellas se elegirá la más adecuada.




OBJETIVO DE CONTROL: Los usuarios y responsables de las unidades

a las que afecte el nuevo sistema establecerán de forma clara los

requerimientos del mismo.




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

requerimientos del sistema. Se debe comprobar que:

Existe un documento aprobado por el comité de dirección en el que se

determina formalmente el grupo de usuarios que participará en el proyecto.

Los usuarios elegidos son suficientemente representativos de las distintas

funciones que se llevan a cabo en las unidades afectadas por el nuevo

sistema.

Se les ha comunicado a los usuarios su participación en el proyecto,

informándoles del ámbito del mismo y de qué es lo que se espera de ellos,

así como la dedicación estimada que les supondrá esta tarea.



Especificación funcional del sistema

Una vez conocido el sistema actual, los requerimientos 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 el. 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 requerimientos del sistema, por lo que

se pasa por alto la comprobación de estos aspectos.



Especificación funcional del sistema

El grupo de usuarios y los responsables de las unidades afectadas

deben ser la principal fuente de información. Se considera un único

objetivo de control, ilustrando como siempre, solo uno de ellos:

OBJETIVO DE CONTROL: 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.


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.

Hay un único módulo: Diseño técnico del sistema

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.

OBJETIVO DE CONTROL: 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.


Auditoría de la fase de construcción

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. Hay dos

módulos.


Auditoría de la fase de construcción

Desarrollo de los componentes del Sistema

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: Los componentes o módulos deben

desarrollarse usando técnicas de programación correctas.


Desarrollo de los procedimientos de usuario

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.

OBJETIVO DE CONTROL: Al término del proyecto, los futuros

usuarios deben estar capacitados y disponer de todos los medios

para hacer uso del sistema.


Auditoría de la fase de implantación

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. Hay un único módulo:

Pruebas, implantación y Aceptación del Sistema

Se verificará en este módulo que el sistema cumple con los

requerimientos establecidos en la fase de análisis. Una vez probado

y aceptado se pondrá en explotación.



OBJETIVO DE CONTROL: El sistema debe ser aceptado

formalmente por los usuarios antes de ser puesto en explotación.

Esta etapa se denomina Certificación usuaria.



Se deben realizar las pruebas del sistema que se especificaron en el

diseño del mismo. Se debe comprobar que:

• Se prepara el entorno y los recursos necesarios para realizar las pruebas

• Las pruebas se realizan y permiten verificar si el sistema cumple las

especificaciones funcionales y si interactúa correctamente con el entorno,

incluyendo interfaces con otros programas, recuperación ante fallas,

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.


La auditoria en el área de desarrollo se subdivide en:

1. Auditoria de la organización y gestión del área de desarrollo.

2. Auditoria de proyectos de desarrollo de Sistemas de

Información.


Los objetivos de control se agrupan en varias series:

1. Organización y gestión del área de desarrollo ( Serie A)

2. Proyectos de desarrollo de Sistemas de Información (SI)

• Aprobación, Planificación y Gestión del Desarrollo(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)


Auditoría de la Organización y Gestión del Área de Desarrollo.

Cada proyecto de desarrollo tiene entidad y se gestiona con cierta

autonomía, para poder llevarse a cabo necesita apoyarse en el

personal del área y en los procedimientos establecidos.

• Objetivo de Control A1: El área de desarrollo debe cumplir con

procedimientos y una organización dentro del departamento.

C-A1-1: Debe establecerse las funciones del área de desarrollo dentro

del departamento de informática. Se debe comprobar que:

Existe el documento que contiene las funciones del área

de desarrollo y está aprobado por la dirección de

informática.


C-A1-2: Debe especificarse el organigrama con la relación de

puestos del área y el puesto que ocupa cada persona. Se debe

comprobar que:

Existe un organigrama con la estructura de organización del

área.

Para cada puesto se debe describir las funciones a

desempeñar y la dependencia jerárquica del mismo.

Están establecidos los procedimientos de promoción de

personal a puestos superiores.


C-A1-3: El área debe tener y difundir su propio plan a corto,

medio y largo plazo. Se debe comprobar que:

El plan existe, es claro y realista.

Se revisa y actualiza con periodicidad en función de las

nuevas situaciones.

Se difunde a todos los empleados para que se sientan

partícipes.


C-A1-4: El área de desarrollo llevará su propio control

presupuestario. Se debe comprobar que:

El presupuesto se cumple.

El presupuesto está acorde con los objetivos a cumplir.

• Objetivo de Control A2: El personal del área de desarrollo debe

contar con la formación adecuada y estar motivado para la

realización de su trabajo.

C-A2-1: Debe existir procedimientos de contratación objetivos. Se

debe comprobar que:

Las ofertas de puestos del área se difunden suficientemente fuera de la

organización.

Las personas seleccionadas cumplen con requisitos del puesto al que

acceden.


C-A2-2: Debe existir un protocolo de recepción/abandono para las

personas que se incorporan o dejan el área. Se debe comprobar que:

El protocolo existe y se respeta para cada incorporación/abandono.

En la incorporación se incluye estándares definidos, manual de organización del

área, definición de puestos, etc.

En los abandonos de personal se garantiza la protección del área.

C-A2-3: Debe existir una biblioteca y una hemeroteca accesibles al

personal del área. Se debe comprobar que:

Están disponibles libros, publicaciones periódicas, monografías, etc. Y el

personal tiene acceso a ellos.


C-A2-4: El personal debe estar motivado en la realización de su trabajo.

Se debe comprobar que:

Exista un mecanismo que permita que los empleados hagan sugerencias

sobre las mejoras en la organización del área.

No existe una gran rotación de personal y hay un buen ambiente de

trabajo.


• Objetivo de Control A3: Si existe 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: Los nuevos proyectos deben basarse en el plan de sistemas en

cuanto a objetivos, marco general y horizonte temporal. Se debe

comprobar que:

Las fechas de realización coinciden con las del plan de sistemas.

La documentación relativa a cada proyecto debe contener los objetivos, los

requisitos generales y un plan inicial.


C-A3-2: El plan de sistemas debe actualizarse con la información que se

genera a lo largo de un proceso de desarrollo. Se debe comprobar que:

Los cambios en los proyectos se comunican al responsable de mantenimiento

del plan de sistemas por las implicaciones que pudiera tener.

Objetivo de Control A4: La propuesta y aprobación de nuevos proyectos deben

realizarse en forma reglada.

C-A4-1: Debe existir un procedimiento para la propuesta de realización

de nuevos proyectos. Se debe comprobar que:

Existe un mecanismo para registrar las necesidades de desarrollo de nuevos

sistemas con los siguientes datos: descripción, necesidad, departamento

patrocinador, riesgos, coste de la no realización, ventajas que aporta, etc.


C-A4-2: Debe existir un procedimiento de aprobación de nuevos

proyectos. Se debe comprobar que:

Exista áreas de la organización designadas para aprobar formalmente la

realización y prioridad de nuevos proyectos. La decisión afirmativa o negativa

se obtendrá en un tiempo razonable y se comunicará a los promotores.

Objetivo de Control A5: La asignación de recursos a los proyectos debe de

hacerse de forma reglada.

C-A5-1: Debe existir un procedimiento para asignar director y equipo

de desarrollo a cada nuevo proyecto. Se debe comprobar que:

El procedimiento existe y se respeta.

Exista personas disponibles cuyo perfil sea adecuado para cada proyecto

y que tenga disponibilidad.


C-A5-2: Debe existir un procedimiento para conseguir los

recursos materiales necesarios para cada proyecto. Se debe

comprobar que:

El procedimiento existe y se respeta.

Objetivo de Control A6: El desarrollo de SI debe hacerse aplicando

principios de ingeniería del software.

C-A6-1: Debe tenerse implantada una metodología de desarrollo

de SI soportada por herramientas de ayuda (CASE). Se debe

comprobar que:

La metodología cubre todas las fases del desarrollo y es adaptable a

distintos tipos de proyecto.


C-A6-2: Debe existir un mecanismo de creación y actualización de

estándares. Se debe comprobar que:

El mecanismo para creación de nuevos estándares está documentado y

es conocido en área.

Los estándares son conocidos por las personas que deben usarlos y se

respetan. Cuando se produce una modificación, se difunde dentro del

área.

C-A6-3: Los lenguajes, compiladores, herramientas CASE,

software de control de versiones, etc. deben ser previamente

homologados. Se debe comprobar que:

Existe un mecanismo para la adquisición y aprobación de nuevos

productos de software usados en el desarrollo.


C-A6-4: Debe practicarse la reutilización del software. Se debe

comprobar que:

Exista un catálogo de los productos de software que puedan ser

reutilizados: librería de funciones, clases, componentes de software, etc.

C-A6-5: Debe existir un registro de problemas que se producen

en el área, incluyendo los fracasos de proyectos completos. Se

debe comprobar que:

Existe un catálogo de problemas, incluyendo para cada uno de ellos la

solución o soluciones, proyecto en el que sucedió, persona que lo

resolvió, etc.


Objetivo de Control A7: Las relaciones con el exterior del departamento

deben producirse de acuerdo a un procedimiento.

C-A7-1: Debe mantenerse contactos con proveedores sobre productos

que pueden ser de interés. Se debe comprobar que:

Se está en contacto con un número suficiente de proveedores para

recibir una información objetiva y completa.

C-A7-2: Debe existir un protocolo para contratación de servicios externos.


Exista el protocolo, esté aprobado y se usa.

El personal externo que interviene en los proyectos cumplirá con los

mismos requisitos que se exigen a los empleados del área.


Objetivo de Control A8: La organización del área debe estar

siempre adaptada a las necesidades de cada momento.

C-A8-1: La organización debe revisarse de forma regular. Se

debe comprobar que:

Cuando se produce modificaciones se documentan, incluyendo la

fecha de actualización y se difunden dentro del área.


Auditoria de Proyectos de Desarrollo de Sistemas de

Información.

La auditoria de un proyecto de desarrollo se puede hacer en dos

momentos distintos: a medida que avanza el proyecto, o una vez

concluido el 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 a los objetivos, restricciones y las unidades

afectadas. Se debe comprobar que:

Existe una orden de aprobación del proyecto refrendad por un órgano

competente.

Los objetivos y restricciones deben estar definidos en forma clara y

precisa.

Se han identificado las unidades de la organización a las que afecta.


C-B1-2: Debe asignarse un responsable o director del proyecto.


Se designa al responsable del proyecto según procedimientos

establecidos.

Se ha comunicado al director de su nombramiento junto con la

información del proyecto.

C-B1-3: Se debe determinar el modelo de ciclo de vida que

seguirá el proyecto. Se debe comprobar que:

Se ha elegido el ciclo de vida más adecuado al tipo de proyecto de que

se trata.


C-B1-4: Elegir el equipo técnico que realizará el proyecto y

determinar el plan del proyecto. Se debe comprobar que:

Objetivo de Control B2: El proyecto se debe gestionar de forma que se

consigan los mejores resultados tomando 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 gestión del proyecto. Se debe

comprobar que:

La designación del director del proyecto y del equipo de desarrollo se

ha llevado según procedimientos establecidos.


C-B2-5: Debe haber un seguimiento de los tiempos empleados de las

tareas del proyecto. Se debe comprobar que:

Existe un procedimiento que permita registrar los tiempos que cada participante

del proyecto dedica al mismo y qué tarea realiza en ese tiempo.

C-B2-6: Se debe controlar que se siguen las etapas del ciclo de vida

adoptado para el proyecto y que se generan los documentos de la

metodología usada. Se debe comprobar que:

Antes de comenzar una nueva etapa se ha documentado la etapa previa y se ha

revisado y aceptado, especialmente en las fases de análisis y diseño.

C-B2-7: Al final cerrar la documentación, liberar los recursos empleados y

hacer balance.

Tema 6

Documents

Transcript of Tema 6