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. Desarrollo5. 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
Implanta
ción
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

Más contenido relacionado

La actualidad más candente

Similar a Tema 6

Más de Carmelo Branimir España Villegas

Tema 6