Auditori A

4<M$ AUDITOR!.* DE TECNOLOGJAS Y S1STF.MA.
S DE INKORMACION
Piattini, M. y Hervada, F,
Sistemas de Information. Ra-Ma, Madrid,
(eds.)
RA-MA
Gobiemo
(2007).
de
las
Tecnologias
13.10 CUESTIONES DE REPASO

1.
Establezca
dates.
objetivos
de
control
relatives
al
diseflo
de
una
base
Capitulo 14
de
2. Defina un procedimiento para ia adquisicion de SGBD.

3. [.Cuales son las diferencias mas importantes entre las funciones de un
administrador de dates y las de un administrador de bases de datos?
4. ^Por que resulta tan critico un diccionario de datos corporative?
5. ^Que controles estableceria sobre la distribucion de listados extraidos a
partir de la base de datos?
6.
Proponga
personal
diferentes
relacionado
objetivos
con
de
el
control
SGBD
sobre
(usuarios
la
formacidn
finales,
del
administradores,
Julio Alfonso Novoa Bermejo
diseftadores, etc.).
7.
Analice
el
grado
de
ajuste
existente
entre
ios
paquetes
de
seguridad
del
mercado y los SGBD.

8.
9.
i,Que riesgos
datos?
(.Que
adicionafes
controles
implies
el
hecho
de
distribuir
las
bases
de
Cuando
estableceria
para
desarro'los
que
empleen
lenguajes
visuales que acceden a bases de datos?

10.
Analice
el
soporte
auditor informatico.
14.1 AMBITO DE TECNICA DE SISTEMAS
que
ofrecen
elementos
que
se
habla
cooperan
de
sistemas,
en
un
por
todo
definition,
armonico.
se
En
trata
de
ocasiones
un
esos
conjunto
de
elementos
se
imbrican unos en otros para mejor integrarse en el conjunto, de manera que a veces
resulta dificil identificar los componentes parciales.
las
herramientas
de
mineria
de
datos
al
Este
podria
es
abarcar
el
caso
de
la
practicamente
Tecnica
la
de
Sistemas
totalidad
del
puesto
proceso
que,
segun
informatico
se
analice,
como
quedar
reducido a una parcela muy precisa y con un desempeno muy restringido.

Para
primera
otorgar
ilustrar
escuela
a
quienes
el
primer
especializada
acababan
SISTEMAS.
Segiin
mformatiea,
existieodo
aquel
los
plan
ademas
supuesto
valga
estudios
de
tres
tras
estudios,
como
DE
(INST1TUTO
el
especialidades
que dispongo, eran:

SISTEMAS FISICOS
INFORMATICA FUNDAMENTAL
* INFORMATICA DE GESTION
ejemplo
la
1NFORMATICA,
superar
TS
que,
el
quinto
abarcaba
si
no
todo
me
titulacion
1970)
afio:
e!
failan
que
empezo
TliCNICO
ambito
los
la
a
DE
de
la
datos
de
408 AUDITORIA DE TECNOLOGI AS Y SISTBftAS DE INFQRMACION
Segun
Hardware
esto,
tan
(Sistemas
Formales
TS
(Tecnico
Fisicos)
como
Automatas
de
el
Sistemas)
que
(Informatica
se
era
la
dedicaba
persona
al
Fundamental)
especialista
desarrollo
como
de
el
en
obstante,
la
especializacidn
en
de
necesitado
Datos
ban
relacionada
mas
de
necesario,
complejas
persona.
instalaciones
en
con
Informatica
esas
actividades
en
y
la
llegado
muy
trabajaba
en
consecuencia,
necesidad
incluso
de
grado
las
sin
no
desempehables
se
por
rigor
con
TS
Datos
especializacion
tareas
con
Bases
de
de
de
de
ban
hecho
una
unica
determinadas
las
personas
La
con
Microinformatica
en
los
algunos
convencionales,
especificas.
En
este
las
casos
Redes
unices
pero
sentido
ban
(emprcsas
que
oimos
generado
mas
requieren
bablar
de
cada
una
dia
nuevos
en
preparation
(incluso
en
entornos
otros
de
dedication
anuncios
de
prensa)
de TS de Microinformatica o TS de Redes.
Parece
nuestro
la
pues
que
compromiso
materia
en
con
no
lo
es
cuestion,
especializados
en
integration
detenninar
queremos
para
como
de
ambito
de
instalaciones,
la
utilizar
tarea
equipos
el
de
el
escribir
poder
sentido
TS
de
Se
imbito
nos
establecer
de
obliga
la
tarea
acotar
despues
las
de
TS,
con
asf
de
de
apartado
la
proceso
incluiria
elementos
de
de
comandos
administration
componentes
IP,
asi
los
switches...),
tratamiento
como
sus
dispositivos
de
los
de
componentes
llamadas...)
los
de
los
Bases
auxiliares
Sistemas
programas,
de
Operatives,
junto
Datos)
intermedios
con
Compiladores,
los
Gestores
toda
una
(herramientas
de
serie
de
Traductores
Datos
de
(o
sistemas
herramientas
facilidades
de
desarrollo,
explotacion como planificadores, paquetes de seguridad, middleware...).

Si
consideramos
necesario
para
infraestructura
que
las
todo
Aplicaciones
cuanto
hemos
fttneionen
detallado,
que,
no
es
decir,
olvidemos,
todo
son
el
objetivo de nuestros sistemas, estableceriamos, segun mi criterio, el ambito de TS.

No
obstante,
dado
Auditoria
Fisica,
dedicados
y
de
correspondientes
las
Redes,
que
de
intentaremos
existen
cn
esta
la Explotacion,
centrarnos
en
publicacidn
de Bases
el
apartado
de
capitulos
Datos,
del
de
Sistema
especificos
la
Seguridad
Operativo
las
14.2 DEFINICION DE LA FUNCION
comun
infraestructura
y
e!
la
praxis
habitual
informatica,
llamado
software
es
determinariamos
decir,
de
base.
el
conjunto
Vamos
deberiamos
requiere
salas
de
conexibn
proceso,
y
con
cableado,
para acondicionar los componentes del apartado siguiente.
sus
es
sistemas
decir,
los
que
definir
un
determinado
Siguiendo
de
seguridad
elementos
antes
primero
de
la
entrar
tarea
en
la
Auditoria
auditar
desempeno
como
profesional
de
una
para
Tecnica
de
Sistemas,
actividad
informatica
cumplir
unos
que
objetivos
precisos.
que
como
modems,
telefonia
micro),
pero
claridad
Instalaciones
Este
compone
Interpretes
puntualizar lo que, segun mi criterio, debe incorporar cada uno de estos apartados.
control,
cinta...),
Software de Base
Parece
de
(routers,
(como
mini
de
elementos especificos de seguridad (Firewall, IDS, IPS...).
actividades de control.
Tratando
(main,
unidades
Comunicaciones, como aspectos no cubiertos en los apartados mencionados.
facil
que
ordenadores
comunicaciones
mezclados
los
impresoras,
lo
unos
pequenas)
estarian
(pantallas,
conmutacion
que
colaboran en la realization del trabajo correspondiente a la funcion concreta.
trabajo,
Aqui
perifericos
habilitar,
Bases
que
departamentos
grado
figura
no
en
administrar
crear
la
Este
un
Seguridad
Seguridad
grandes
dejando
Operativo,
entornos),
centros
obligado
Operatives,
Sistema
y/o
ha
concretas,
Comunicaciones,
todo,
laboriosas,
Sistemas
areas
el
en
ocasiones
ha
la
Comunicaciones,
sobre
En
de
expertos
especialistas
(administradores
sido
que
exclusivamente
naturalmente,
ha
evotucion
Equipos de proceso
Lenguajes
que
Aplicaciones (Informatica de Gestion).

No
CAPiTULO 14. AUDITORIA DE TECNICA DE SISTEMAS 409
RA-MA
RA-MA
Tecnica
de
este
esquema
Sistemas
consiste
buscando
en
la
un
enunciado
actividad
simple
desempeftar
podemos
para
decir
instalar
mantener en adecuado orden de utilizacion la infraestructura informatica.
base
Todo de acuerdo con lo ya comentado en el apartado anterior -en cuanto a

ambito-
buscando
un
compromiso
formal
para
separar
las
Aplicaciones
de
todo
lo
necesario para que estas fimcionen correetamente.

Profundizando
caracterizaria por:
en
esto
diriamos
que
el
funcionamiento
correcto
se
4!0 AUDITORIA DE TECNOlOGiAS YSISTEMAS PH 1NFQRMACION
RA-MA
CAPm/i.O 14. AUD1TORJA DE TECN1CA. PE SiSTEMAS 411
RA-MA
correspondientes
* Disponer de fodos los elementos necesarios
la
anomah'a
tiempo
For parte de los usuarios autorizados
utif,
asistencia
tiempo
* En el momento requerido
de
un
nuestros
* 14.3 EL NIVEL BE SERVICIO
encima
No
debemos
perder
de
vista
que
el
cumplimiento
de
tales
caracteristicas
) constituye ei objetivo de los SI (Sistcmas de Informacidn) v que su consecucion se
impacto
lo
que,
estos
(segun
la
terminos,
lo
se
y
el
que
esta
de
nos
detectar
subsanarla
de
impacto
por
previsto,
se
negocian
con
actividades
Level
eficacia
conseguir
el
anterior.
que,
exige
que
por
de
disponibilidades
los
SI
no
tener
con
Hay
comunmente
de
su
Agreement)
negociado
lo
los
para
criticidad
llevaiia
en
lo
aportan
de
de
contrato
Service
grado
importante
correspondiente
filosofia,
para
habla
grado
(SLA:
requerida
tan
capacidad
reducir,
servicio
clientes
es
la
del
con
servicio
sectores
organizacion)
que,
de
asistencia
en
permita
el
nuestros
la
que
como
disponer
reciben
nivel
99,9%
en
nos
anadirse
que
aseguran
proveedores
que
Debe
de
hardware
deberemos
proveedor
acuerdos
de
que
proveedores
del
Comprcnderemos
elemento
inactividad.
lado,
entender
un
consecucion
por
soslayarlo.
un
para
con
usuarios
* Con el rendimiento adecuado
para
en
relacion
interrupciones
al
durante
mas de 2 horas en total en un ano para un servicio estimado en 2.000 horas anuales.
^ expresa en terminos de nive! de servjcio. Toda nuestra actividad deberia estar
Vease
fundam.entada en ei logro de ese objetivo y, tanto los procedimientos de actuacion,
que
un
total
de
10
horas
de
parada
en
un
ano
no
es
el
para
ese
mismo
servicio
supondria una disponibilidad del 99,5%.
como los correspondientes controles, deberian tener como fin ultimo dicha meta.
La
' Entendemos por nivel de servjcio una serie de parametros cuya medicion
numero
) es capaz de determinar objetivamente ei mayor 6 manor grado de eficacia del
servicio
prestado.
No
cabe
duda
de
que
la
disponibilidad,
obtencion
de
dicho
nivel
se
ve
afectada
fundamental,
unico
parametro
medir,
solo
de
horas
puede
ai
ano,
comprobarse
porque
mediante
ademas,
tiempos
debe
de
hacerlo
respuesta
bien.
que
den
Este
ultimo
una
medida
aspecto
de
la
utilidad del servicio.
* por cuantas incidencias, de cualquier tipo, impacten en el normal desenvolvimiento

) de la actividad de! SI. Ast, paradas por instalacion de nuevos drspositivos, cambios
La
de versiones del sistema operativo, puesta en servicio de nuevas herramientas,
depende
satisfaction
de
tanto
la
averias de maquina, fallos de corriente o elementos de acondicionamiento,
Este
ultimo
aspecto
! arranque o modificacidn de enlaces de comunicaciones, inclusion de nuevos
tiempo
de
respuesta,
por
infraestructura
siendo
toda vez que no se trata de tener un sistema que responde durante un determinado
usuarios o cualquier tipo de problema con el hardware o el software puede
' degradar el servicio, con el consiguienie perjuicio para ia organizaeidn, que no
la
de
los
eficacia
esta
bien
pero
y
usuarios
de
se
las
es
fruto
del
aplicaciones
las
representado
completa
opiniones
por
con
de
el
los
resultado
como
los
general
la
de
parametros
anaJisis
usuarios
del
de
servicio
del
eficiencia
disponibilidad
de
las
incidencias
sobre
el
servicio,
en
una
sistema.
y
originadas
en
la
parte
correspondiente a ese mismo componente.
1 podra desarrollar sus funciones adecuadamcnte o en el tiempo preciso, con el
correspondiente
;
impacto
economico
que
esto
supone
que,
generalmente,
resultara
14.4 LOS PROCEDIMIJENTOS
dificil de calcular, pero, en cualquier caso, importante.
Toda
Este
apartado
de
nivel
de
servicio
requiere
un
tratamiento
especifico,
toda
vez que en la busqueda de la calidad se convierte en el aspecto clave de la geslion
acciones
tarea
organizada
realizar
con
debe
unos
estar
descompuesta
procedimientos
especificos
que
serie
de
garanticen
actividades
su
calidad
(o correcto funcionamiento).
\ de la configuracion. Bastaria decir que sin los clientes del SI no tiene sentido el SI.
De
Y lo que tales clientes necesitan es la garantia de que el SI cumple su funcidn
la
administration
adecuadamcnte, puesto que, cada vez mas, es el fundamento de toda la actividad de
parametros
, la organizacion.
orientacidn
de
antes
los
que
recursos
mencionados,
hemos
del
dado
SI
cuestidn
nuestros procedimientos.
Digamos
garantia
del
para
terminar
funcionamiento
esta
global
breve
se
incursion
obtiene
en
primero
el
concepto
consiguiendo
expuesto
la
de
que
cada
la
uno
de sus elementos, lo que nos obliga a determinar los pantos criticos que afecten a la
actividad del SI y a prever su fallo y planificar los controles y acciones
Podemos efectuar una clasificacion en:
hacia
el
servicio
(infraestructura),
que
ha
de
se
que
convertirse
deduce
debe
en
ia
tares
pptimizar
el
objetivo
de
los
de
412 AUDlTORiA DE TECNOLOGiAS Y S1STEMAS DE INFORMACION
RA-MA
dia
1. Instalaeion y puesta en servicio
CAPITULO 14. AUDlTORiA DE TECNiCA DE S1STEMAS 4 i3
RA-MA
la
facilitar
asistencia
information
prestar
necesaria
X Requisites para otros componentes
colectivos
el
sistema
(desarrolladores,
por
sus
herramientas
de
garantia
ejemplo)
para
su
para
raejor
Pianificacion.
Control
del
periodo
comienzo
del
mantenimiento del elemento.

Documentacion. Procedimiento para contactar con el soporte.
4. Resolution de Incidencias
5. Seguridad y Control "
Parametrizacidn.
de
nuevos
resoiucion
6. Information sobre la actividad
clasrficacidn
otros
utilization.
2. Mantenimiento y soporte
La
a
sobre
Adaptacion
de
los
rcquerimientos
como
de
incidencias
parametros
del
sistema.
En
resultado
de
nuevas
versiones
parches
(incluiria
aplicacion
de
funcion
actualizacion de nuevas versiones de software).
anterior
sin'e
para
cualquier
elemento
de
infraestructura,
Pruebas. Verificaciones de los cambios o adaptaciones realizadas.
pero como ejemplo, podemos pensar en e! Sistema Operative de una maquina. .

INSTALACIQN Y PUESTA EN SERVICIO
REOUIS1TOS PARA OTROS COMPONENTES

Comprenderia
tod
as
las
actividades
para
conseguir
el
funcionamiento
adecuado del elemento en cuestion:
Procedimiento
Planificacibn. Procedimiento general de! suministrador adaptado a la
instalaeion concreta.
Pianificacion.
para
Documentation. Inventario de componentes del elemento y normas de
con
Considerar
otros,
en el subsistema
a
Parametrizacion.
resto
requerimientos
de
recomendaciones
para
el
mejor
Valores
elementos
de
parametros
planificados
del
sistema
(numero
por
los
ejemplo:
requisitos
cruzados
considerar
el
de
espacio
en
unos
elementos
disco
necesaria
para una nueva instancia de una base de datos y, por ende, el impacto
actualization.
de
comportamiento de otros componentes del SI.
en
tipos
funcion
de
del
espacio
limitar
usuarios,
el
de
discos
requerido
tiempo
de
las consccuencias
tiempo
necesario
servicio
en los back-up en cuanto
(ventana
usuarios),
de
back-up
teniendo
en
que
puede
cuenta
las
limitaciones que en cuaiquiera de estos aspectos pudieran existir.
aplicaciones...).
Pruebas. Verificaciones a realizar y sus resultados.
Documentacion.
Procedimiento
que
determina
los
efectos
considerar
en otros componentes.
Debe
normativa
de
partirse
general:
instalaeion
proyectos
(criterios
de
(como
demas
de
los
estructura
per
ejemplo
informaciones
securizacion
de
documentos
organizativa
direcciones
que
existentes
IP
puedan
aplicaciones
en
la
(especialmente
a
y
criticas
utilizar),
deban
que
organization
informatica),
metodologia
condicionar
requieren
sobre
normativas
general
la
de
instalaeion
garantia
Parametrizacion,
de
nuevos
Adaptacion
requerimientos
de
los
como
parametros
del
sistema
resultado
de
nuevas
resoiucion de incidencias.
de
servicio: cluster, mecanismos y comprobacion de back-up...).

MANTENIMIENTO Y SOPORTE
Pruebas. Verificaciones de los cambios o adaptaciones realizadas.
Comprenderia el conjunto de aeciones necesarias para la puesta al dia de!

elemento, asi como la asistencia de terceros para la consecucidn de dicha puesta ai
en
funcion
versiones
414 AUDITORJA DE TECNOLOGIAS Y SISTEMAS DK INFGRMAClON
RA-MA
CAPiTULQ 14. AUDiTORiA DE TECNICA DE SISTEMAS 415
O RA-MA
RESOLUCION DP; INCIDENCIAS
Seguimiento.
la
accion
continua
normalizada
para
conseguir
el
proceso
de
SEGURIPAD Y CONTROL
Estos
Registrar. Supone abrir un formulario en el medio habiiitado (papel,
Es
diagnostico de una incidencia y la persecucion de su resolucion.
Procedimiento para registrar, analizar, diagnosticar, calificar y seguir las

incidencias que se produzcan, en relacion con el elemento en cuestion con el
objetivo tie su resolucion.
procedimientos
adquieren
una
especial
relevancia
en
e!
evitacion de incidencias y, en caso de producirse, en su temprana deteccion.
electronicu...) que permita recoger los datos que identifican la

proteccidn
debe
considerar
malintencionados.
La
Los
primeros
, anomaHa: momenta en que se produjo, elementos y servicios/usuarios

como
aFectados, danos producidos y/o que pueden producirse, entomo del

1 problems y una description de lo acaecido (las opiniones de los
adecuada
> observadores pueden resultar de interes en algunos casos).
procedimicntos
competencia
malintencionados
Analizar. Supone buscar una relacion entre etecto y sus posibies causas,
procedimientos
. para lo que se cuenta, ademas de con los cornentarios de los
profesional
robustos
se
que
tanto
se
mas
que
inciuyan
prevendran
mediante
eviten
concentracion
la
posibiiidad
evitaran
la
organizacion
elementos
una
de
de
politics
(areas
de
partiendo
de
hechos
de
una
fortuitos
formacion
que
establezca
control".
Los
personal
consideren
unos
hechos
adecuada,
la
unos
segregacidn
de
funciones y ios correspondientes controles.
observadores ya mencionados, con la experiencia de! tecnico que trata

Adquiere
> ia incidencia y la tnformacion ya registrada sobre otras incidencias

j
producidas que pudieran estar relacionadas o responder a la misma o

parecida causa que esta.
,i
una
transporte
el
un
existente
objeto
relevancia
proceso
que
en
especial
toma
un
un
entorno
el
control
de
nuevo
objeto,
la
para
su
puesta
en
Transportes.
Se
modificacion
produccion
en
entiende
eliminacion
otro.
En
por
de
este
proceso se consideran:
1 y Diagnosticar. Determinar, de entre las causas posibies, aquella que
| tuviera mas probabilidad de resultar el origen del problema, una vez

) analizada la informacion disponibie. En el caso hipotdtico de no poder
Objeto:
piezas
de
cbdigo
(programas),
de
datos
(tablas
de
configuracion
o datos basicos).
, establecer una causa del fenomeno reportar al soporte disponibie para

Entomo: espacio de trabajo, como pOT ejemplo:
! su diagnostico.
:)'
o Desarrollo: programacion y pruebas de nuevas funciones o
, Calificar. Es un dato importante en el enfoque de la resolucibn, pues no
adaptaciones.
! tiene el mismo tratamiento una anomaHa bloqueante que afecta a iodo

I
J un sistema que un error que se produce de forma muy espoxadica y sus
, efectos no son muy prpbtematicos.
o Integracion: pruebas de consistencia de nuevas funciones con

existentes.
o Formacion: equipos para entrenamiento de usuarios.
i Resolucion. Para resolver definitivamente un problema bace falta
, conocer su causa y la forma de evitar que se rcproduzcan las

condiciones
origen.
En
caso
o Produccion: sistema dedicado a transacciones de negocio.

de
disponer
de
la
solucidn,
su
aplicacion
, / debera atenerse a los criterios de nivel de servicio, evaluando la
servicio global en curso. Supdngase e! caso de un problema que sdio

puede
solucionarse
mediante
1 ; (iroagmese cualquier ejemplo en: hospital, banco, produccion de

!
fabrica...). .
un
Proyecto
de
y
transportes:
en
cuaiquier
normalmente
caso
el nuevo desarrollo o la modificacion.
' resolucion, para coordinar las acciones que menos perjudiquen el
: ' instalarse parando una maquina que controla un proceso critico
Responsable
del
problematica creada por la faita de solucidn y la que pueda crear la
"parche"
de
software
que
solo
puede
una
el
persona
Director
diferente
del
Responsable
que
realiza
4!6 AUDITOR!A PS TECNOLOGlAS Y SISTEMAS DE INFORMACION
Es
mmimos
necesario
reservando
proteger
los
funciones
accesos
accesos
informacion
especiales
funciones
niveles
con
de
criterio
acceso
poner
ejemplos,
modificar
del
que
sistema
personal
de
y,
operative
desarrollo
de
igual
no
debe
forma,
los
tener
T3
en
de
explotacion
versiones
los
es
fuente
en
que
vigor.
de
algun
la
realidad,
parametro,
permitiendo
en
aras
profundizar
de
localizar
si
se
la
tipicos
en
comprueba
Un
cuanto
que
control
los
dichos
de
este
programas
objetos
tipo
se
tambien
objeto
compilados
corresponden
detecta
con
aquellos
las
objetos
Deberian
determinar
el
comportamiento
del
sistema
no deseadas desde cualquier punto de vista: .

Hardware.
informacion
autores
entornos
sobre
de
de
las
las
desarrollo
sentencias
mantenimiento
borradas,
modificaciones.
de
modificadas
Estas
pistas
de
programas
anadidas,
auditoria
deben
asi
dejar
como
permiten
los
importante
que
informaticas,
funciones
existan
aunque
es
una
serie
igual
de
de
o Existen los componentes adquiridos (inventario)
realizar
investigaciones para determinar el origen de un determinado cambio.

Es
o Estan correctamente instalados

normativas
importante
que
para
realizar
las
tales
normas
se
o Se mantienen adecuadamente
cumplan.
o Dan el rendimiento requerido
INFORMACION SOBRE LA ACTIVIDAD
Forma
parte
responsable
superior
estructurada,
de
de
ia
del
acuerdo
esencia
trabajo
con
los
de
cualquier
realizado.
parametros
de
actividad
Dispones-
rendir
de
seguimiento
una
mas
cuentas
al
informacion
acordes
con
los
Software,
Se dispone de las correspondientes licencias
o
Esta correctamente instalado
objetivos de desempeflo, es cuestidn primordial para:
o
Se mantiene adecuadamente
(versiones oficialmente
Conocer la evolution de la actividad
soportadas)
o
Comparar la realidad con objetivos y estandares
a Dan el rendimiento adecuado

Mejorar la calidad de la tarea
Comunicaciones.
Anticiparse a situaciones criticas analizando las tendencias

Es
objetiven
uno
parametros
comportamientos
servicio.
de
de!
los
elementos
para
sistema
de
un
un
analisis
mas
determinado
comportamiento o magnitud.
que no disponen de su correspondiente programa fuente.

Los
requiere
causa
14.5 LOS CONTROLES
controles
el
de
no
deben poder modificar programas.
Uno
representativa
fmo
diremos
parametros
La informacion debe servir para gestionar y, por tanto, debe ser resumida y
de
responsabilidad
superiores con los controles adecuados.

Por
CAPiTULO 14. AUDITORIA DE TECN1CA DE SISTEMAS 417
RA-MA
SRA-MA
su
que
basicos
del
seguimiento,
esten
es
nivel
decir,
directamente
o Existen componentes
de
servicio,
seamos
ligados
sicmpre
capaces
con
la
que
de
calidad
se
medir
Conmutacion.
del
o Estan correctamente instalados
q Se mantienen adecuadamente
o Dan el rendimiento adecuado
prevenir
situaciones
AUPITORIA OE TECNOLOgiAS Y SfSTEMAS DE INFORMACION
RA-MA
CAPI'TULG 14. AUOITORiA DE TKCNlCA DE SiSTEMAS 4!9
RA-MA
Comumcaciones.
o Existen los contratos o servicios
e)
Control
de
los
Sistemas
de
IT Governance Certification
En
o Dan el ancho de banda y respuesta necesarios
1998
reconocio
la
necesidad
creciente
de
dedicar
esfuerzo
creciente
al
Gobierno y Control de las TI creando el I TGI (IT Governance Institute) que paso a
gestionar
la
relacionan
evolucion
los
Organization
Soporte
y,
actividades
como:
o Se controlan las excepciones
Auditoria
C1SM. Certified Information Security Manager
o Se mantienen adecuadamente
o Se Uevan a cabo
la
C1SA. Certified Information System Auditor
o Esran correctamente parametrizados
o Existen los procedimientos
para
Informacion (ISACA) otorga las certificaciones:
Enlaces.
Seguridad.
Asociacion
La
del
procesos
y
Modelo
de
ios
PJanificacion,
por
ultimo,
relacionadas
Personas,
con
COBIT (Control Objectives & IT related). Alii se

Sistemas
Compras
de
e
Monitorizaeion.
ios
Aplicaciones,
Sistemas
de
Tecnologia,
Informacion,
Implantation,
Estos
clasificados
Puesta
procesos
Informacion
Explotacion
y,
y
en
en
engloban
a
su
Datos.
vez,
Por
dominios:
Servicio
todas
con
y
las
factores
otra
parte
tienen una conexion mayor o menor con siete Criterios de Informacion:
o Se toman inedidas
1. Eficacia
Informacton.
2. Eficiencia
o Se dispone de procedimientos de back-up
3. Confidencialidad
o Se realizan los back-up correspondientes
4. Integridad
o Se guardan adecuadamente
6. Cumpiimiento riormativo (legalidad vigente y regulation interna)
o Se comprueban por muestreo
Plan de Contingencias.
7. Fiabilidad
La
definition
del
factor
Tecnologia
puede
estamos aplicando a Ticnica de Sistemas, puesto que comprende:
o Estan contratados los servicios necesarios
1. Hardware
o Esta debidamente actualizado
2. Sistemas Operatives
o Se realizan los ensaybs periodicos
3. Gestures de Bases de Datos
4. Redes,
identificarse
con
el
ambito
que
420 AODITORlAPE'I'ECN'OLOGiAS Y SISTEMAS DEINFORMACION
RA-MA
CAPITULO 14. AUDlTORiA OK TECNICA DE SISTEMAS 421
RA-MA
P03 - Determination de la direcci6n tecnologka
5. Multimedia,
Se
mantener
Extrayendo
los
procesos
relacionados
con
obtendriamos, segun ISACA, los objetivos de control
nos ocupa: Tecnica de Sistemas.
esta
definicion
de
Tecnologia
al aTea que
coTrespondientes
la
trata
un
grupos
para
los
34
procesos
que
ISACA
identifica
que
se
capacidad
de
la
Se
por
ME4 procesos de monitorizacion y Evaluation de los SI
seg&n
los
el
objetivos
concepto
de
control
anterior
en
el
los
criterio
las
tecnologias
tecnoiogica,
actual,
emergentes.
adecuando
siguiendo
los
Pretende
haciendo
desarrollos
crear
evolucionar
tecnologicos,
las
establecimiento
de
estandares
criterios
de
unificacion
de
deben
equilibrar
eficacia
eficiencia
(normalization
simplification).
medio
la
de
disposition
los
el
control
correspondientes
de
desemboisos
presupueslos
de
operativos
recursos
financieros,
periodieos
establecidos
sobre
lo
gastado
eficacia
y convenientemente aprobados.
que
del
infraestructura
el
Asegura
Veamos
de
P05 - Administrar las inversiones cn TI
DS 13 procesos de Entrega y Soporte (Deliver & Support) de Servicios
Sistemas,
ventajas
infraestructura
plataformas.
PO 10 procesos de Planificacidn y Organization

AI 7 procesos relacionados con Adquisiciones e Instalacion de
recursos de SI
obtener
de
restricciones del negocio y los planes de adquisicion.

incluye
Existen cuatro
agrupan en 4 apartados:
de
plan
se
invoiucra
autor
(se
la
incluye
Tecnica
la
de
refereneia
Tiene
en
cuenta
altemativas
de
financiacion,
control
justification de costes.
y description del proceso en COBiT 4.1).

En
POl - Definicibn del plan estratgico de TI

Pretende
balance
optima
requerimientos
estrategica
Estos
que,
planes
la
satisfaction
entre
las
su
a
posterior
intervalos
largo
de
los
oportunidades
plazo
requerimientos
de
la
cumplimiento.
regulares,
deben
este
proceso
son
igual
de
importantes
eficiencia,
considerandose, ademas, la fjabilidad de lo adquirido.
va
Permite
cumpliendo
traducirse
del
tecnologia
negocio,
de
un
la
proceso
los
periodicamente
planes
en
buscando
information,
de
a
un
P08 - Administrar la calidad
dichos
Considera el nivel de servicio a prestar en cada caso (sistema o aplicacion).
planificacion
largo
planes
plazo.
operativos
negocio
Lo
estandares
de
servicio
deben
de
cada
de
ellos.
Veamos
uno
considerar
una
la
criticidad
clasificacion
con
y
un
el
impacto
ejemplo
en
de
e!
cada
agrupaeion:
con objetivos claros y concretes a corto plazo.
Toma en consideracidn objetivos de negocio y necesidades de

de la informacidn, inventario de solutiones tscnologicas e Infraestructura
estudios de factibilidad.
tecnologia
actual y
Front-office- Servicios orientados a mercado y clientes (maxima

prioridad: e-business).
Back-office. Operaciones intemas (importantes pero con menor nivel
Primaivdo
fundamerdalmente
importancia a la eficiencia.
el
criterio
de
eficacia,
concede
tambkn
de criticidad: nomina).
Servicios base: Infraestructuras (requerimiento de robustez y
fiabilidad: comunicaciones).
Los
niveles
de
servicio
de
los
Seivicios
de
Base
deberan
Front-office y el Back-office puedan cumplir sus propios estandares. En casos de
permitir
que
el
422 AUDiTORiA DE TECNOLOOlAS Y SiSlfcMAS DE INFORMACION
external izacion (outsourcing

tales parametros (incluyendo
e! funcionamiento de las sistemas.
RA-MA
de servicios de base,
las penalizaciones por
nonnalmente) la negotiation
incumpiimiento) son clave
de
en
CAPiTUE.O 14. AUDiTORiA DE TfeCNtCA DE SISTEMAS 423
O RA-MA
All - Identification de soluciones automatizadas

Se
trata
requerimientos
Se
P09 - Evalaar y administrar riesgos de TI

(como
(tecnologia
servicios
de
el
la
de
asegurami'ento
information),
TI.
Permits
de
la
previniendo
la
obtencion
las
organization
de
los
amenazas
en
identificar
objetivos
la
los
asegurar
los
la
usuarios,
mejor
facilitando
aproximacidn
un
analisis
para
claro
satisfacer
de
las
los
oportunas
alternativas ajustadas a los requisites.
La Administration de la Calidad busca fundamerrtalmente la eficacia.
Pxetende
de
de
de
TI
de
los
analizar
su
obtencion
riesgos,
ban
de
sistemas
factibilidad
tomar
en
heredados),
ia
(costes,
beneficios,
consideration
direction
las
de
alternativas...),
restricciones
la
los
intemas
tecnologia,
los
requerimientos
extemas
estudios
la
de
arquitectura
de informacion.
impacto y tomar las medidas de coste efectivo para mitigarlos.

Prevalece la eficacia, aunque la eficiencia debe considcrarse tambien.
Considers
los
momentos
sistemas),
distintos
de
ambitos
tipo
analisis
de
riesgos
(periodicos
giobales
(tecnologia,
durante
especificos,
seguridad,
la
continuidad...),
implantation
informes
de
de
incidencias
nuevos
y
AI3 - Adqtiisicion y mantenimiento de infraestructura tecnologica
el
mantenimiento de un modelo de riesgo.
Este
proceso
aplicaciones
Estan
involucrados
los
confidencialidad, integridad y disponibilidad.
siete
criterios,
pero
especialmente:
del
requerimientos
provee
las
negocio.
funcionales
plataformas
Permite
adecuadas
defmir
operativos
para
consideraciones
una
implantation
soportar
las
especificas
por
fases
de
con
hitos
claros.
Se
evolution,
deben
las
considerar:
politicas
la
de
disponibilidad
seguridad,
el
de
la
tecnologia,
ajuste
de
los
direction
de
su
procedimientos
la
la
instalacion y la flexibitidad.
Supone
los
marcar
presupuestos.
Imea
con
el
prioridades
Permite
plan
la
operativo.
para
conseguir
organization
Mis
aun,
la
objetivos
identificar
organization
en
tiempo,
priorizar
debe
dentro
proyectos
adoptar
Deben
de
en
aplicar
involucrados,
comite
de
preciso
las
tener
incidencias
seguimiento,
los
en
y
cuenta
los
eJ
hitos,
presupuestos
de
promoter
la
del
determination
costes
mano
Pretende
proyecto,
de
de
los
usuarios
tesponsahilidades,
obra,
plan y la segur.dad del plan para con los sistemas sensibles.

Results fundamental la participation de las Areas de Infraestructuras y
tad en la planificacion y puesta en marcha de nuevos proyectos, a efectos
del cumplimiento de politicas y estandares y el aseguramiento del minirno impacto
en los SI.
la
calidad
el
del
los
estandares
(regulation
tecnologicas
usuario
asegurar
instaladas.
a
los
el
uso
Supone
manuales
de
adecuado
una
de
las
aproximacion
normativa
procedimientos
aplicaciones
estructurada
operativos,
interna)
asi
de
al
como
las
soluciones
desarrollo
a
del
requerimientos
de servicio y material de entrenamiento.

Tiene
en
consideration
tanto
procedimientos
como
controles
de
usuario
procedimientos y controles operativos.

Prevaleciendo
eficacia
eficiencia,
tambien
intervienen criterios de integridad, cumplimiento normativo y fiabilidad.

AI5 - Adquisicldn de recursos de IT
Asegurar la integration con la infraestructura existente.
En esle caso intervienen por igual los criterios de eficacia y eficiencia.
A14 - Facilitar las operaciones y el uso de los SI
tecnicas seguras de gestion de proyectos para cada proyecto emprendido.

Es
prevalecer
considerando eficacia y eficiencia.
-en
segundo
tdrmino-
424 AUDiTQRlA DE
TF.CNOLOGIAS
Considera
el
RA-MA
Y SISTEMAS DE [NFORMACION
soporte
mamenimiento
adecuado
por
parte
CAPiTULO 14. AUD1TOR1A DE TECNiCA DE SISTEMAS 42S
RA-MA
Involucra
del
respuesta,
suministrador para poder garantizar el mamenimiento de la operativa global del SI.
definition
dependencies,
de
responsabilidades,
cargas,
garantias
volumenes
de
integridad,
tiempos
de
penalizaciones
por
incumplimientos y acuerdos de discrecion.

Busca la integridad y la disponibilidad, prevaleciendo la eficacia.
Intervienen ios siete criterios, siendo primarios; eficacia y eficiencia.
AI6 - Gestidn de cambios
Pretend
habilitando
la
mimmizar
gestion
de!
disfunciones,
sistema
para
alteraciones
el
analisis,
no
la
autorizadas
implantacion
el
errores,
DS2 - Gestion de servicios de terceros
seguimiento
Aseguran
que
con
claridad,
definidos
de los cambios solicitados y realizados en la infraestructura de Tl existente.
satisfaciendolos.
Tiene
priorizacion
en
cuenta
la
procedimientos
identificacion
de
emergencia,
e!
de
los
cambios,
impacto,
la
la
categorizacion,
autorizacion
de
los
contratos
los
Facilitan
existentes
roles
son
medidas
los
responsabilidades
conformes
de
con
control
procedimientos
de
los
para
para
su
terceras
partes
requerimientos
revisar
eficacia
estan
continuan
monitorizar
cumplimiento
los
de
las
poHticas de la orgariizacion.
cambios, gestion delegada y distribucion de software.

Asegura
que
todos
los
afectados
conocen
las
nuevas
Tiene
ftmcionalidades,
discrecion,
cambios en la operativa de los sistemas y su impacto.
que
las
ver
con
poHticas
de
los
la
acuerdos
compafiia,
de
nivel
las
de
Seyes
servicio,
con
los
acuerdos
de
los
contratos
de
regulaciones
outsourcing.
Considera
la
comunicacion,
formacion
entrenamiento
adecuado
de
todos
Igual
los participantes (tecnicos para el soporte y usuarios para su adecuada utilizacion).
que
el
proceso
anterior,
requiere
de
todos
los
criterios
y,
en
especial,
de eficacia y eficiencia.
DS3 - Gestion de rendimiento y capacidad
Busca la integridad y la disponibilidad, prevaleciendo la eficacia.
Asegura
A17 - Instalacion y certificacion de sistemas
Verifica
que
permite
confirma
la
que
realizacion
dptimos
la
solucion
de
una
encaja
con
el
proposito
correctamente
Considera
la
aprobacion
entrenamiento,
de
gestionar
la
capacidad
la
carga,
tamano
el
la
los
gestionar
la
y/o
estructura,
carga
la
de
documentation,
datos
el
capacidad
adecuada,
requerimientos
rendimiento
de
las
su
establecidos.
que
recopilan
aplicaciones
disponibilidad
Permite
datos
la
gestion
uso
controles
para
informan
para
de
recursos
eficacia
Tiene en cuenta volumenes, tiempos de respuesta y rendimientos.
pruebas
revisiones
post-
implantation.
Busca
el
factor
de
disponibilidad,
prevaleciendo
siernpre
eficiencia.
DS4 - Aseguramiento de la continuidad del servicio
Busca la integridad y la disponibilidad, prevaleciendo ia eficacia.
Dispone
DSl - Definicidn y gestidn de niveles de servicio

Persigue
requerido,
con
peticiones.
de
conversion
existencia
lo
migracion, conversion y un plan de aceptacion.
especificas,
la
acuerdo
instalacion,
perseguido,
formalizada
de
Permite
un
entendimiento
el
establecimiento
general
de
se
izado
sobre
el
nivel
acuerdos
de
nivel
de
de
servicio
servicio
que
produce
estructurado
una
el
servicio
incidencia.
(simulacros)
tal
Permite
facilrtando
como
el
se
requiere
ejercicio
distintas
regular
fases
continua
de
hitos
un
facilitandoio
plan
claros,
de
cuando
contingencia
alineando
las
TI
con los aspectos del negocio.
formalizan los enterics de rendimiento con los que deben medirse cantidad y
calidad del servicio.
Considera
la
clasificacion
critica,
e!
plan
alternativos y las pruebas y ensayos sistematicos y regulares.
documentado,
los
procedimientos
SRA-MA
426 AUDfTOfUA DE TECNOLOGIAS YSiSTKMAS DJ- INFORMACION
Se fundamenta en dtsponibilidad y eficacia y, de manera secundaria, en
CAPri'lJl.O 14. AUDlTORiA DE TECMCA D SISTEMAS 42?
RA-MA
DS10 - Gestion de problemas
eficiencia.
Asegura
DS5 - Aseguramiento de la seguridad de Jos sistemas
las
, Para salvaguardar la informacion contra usos no autorizados, Tevelacion de

informacion, modificacion, corrupcion o perdida, controla el acceso logico al <
sistema, a los datos y a los programas, restringiendo estos a los usuarios
, autorizados. |
I Involucra autonzacion, autenticacion, perfiles e identificacidn de usuarios,

, gestion de claves e informs de incidencias y seguimiento.
IS
causas
que
que
se
se
conocen
los
previene
su
existencia
de
problemas
repetition,
las
incidencias,
permitiendo
un
que
sistema
se
que
investigan
registre
persiga su resolucion.
Determina
soluciones,
la
eltiempo
de
pistas
resolucion
de
de
los
auditoria
problemas
suficientes
sobre
reportados,
problemas
procedimier.tos
y
de
escalado (paso de problemas a otras instancias) e informes de incidencias.
Criterios primarios: eficacia y eficiencia; secundarios: disponibilidad.

^ Aplica criterios de confidencialidad e integridad y, en segundo orden,
. disponibilidad, cumplimiento normative y fiabilidad.
ME1 - Momtomation y evaluation del rendimiento delT

Persigue
) DS6 - Identificacibn y reparto de costes

1
i
Asegurar la corrects atribucibn de ios costes de los servicios de II. Debe j

disponerse de un sistema de contabilidad de costes que garantice el registro de los
^ mismos, con el consiguiente cdlculo y distribution de detalle.

) Considera los recursos a mcluir, las poiiticas de reparto y los ratios de
distribucidn.
St,
de
defmiendo
la
la
rendimiento
consecution
gestion
de
de
ia
de
los
informes
objetivos
buscados
relevantes
implantation
del
para
ia
soporte
de
por
los
procesos
direction
los
de
sistemas,
de
los
indicadores
asi
como
clarificando los informes sobre una base regular y normalizada.

Son
importantes
los
auto-controles,
benchmarks,
metricas,
indicadores
clave de medicion de rendimientos e informes de gestion.
, Utiliza criterios de eficiencia y fiabilidad.

intervienen Ios siete criterios, siendo primario e! de la eficacia.
DS9 - Gestidn de la configuration
Inventariado de todos los componentes de los SI, previendo alteraciones no
1
ME2 - Monitorizaci6n y evaluaci6n del control interno
autorizadas, verificando su existencia flsica y facilitando una base precisa para
Para
incrementar
los
. gestionar el cambio, los controles que identifican y registran todos los bienes y su
referencias
localizacion fisica, asi como un programs regular de verification que asegure su
independientes a intervaios regulares.
de
las
niveles
mcjores
de
practicas
confidencialidad
es
importante
el
beneficio
realizar
de
auditorias
i existencia.
A
' Tiene en cuenta el registro de activos y su etiquetado.
considerar
la
revision
de
la
existencia
cumplimiento
de
la
normativa
interna en cuanto a poiiticas, estandares y procedimientos

La
proactiva,
de
las
mencionada
la
ejecucion
observaciones
auditoria
de
los
las
independiente
controles
por
recomendaciones
con
personal
conceptos
cualificado
conatituyen
aspectos
de
la
clave
auditoria
clarification
de
esta
aqut,
con
actividad.
Usa criterios de disponibilidad y fiabilidad, dando prioridad a la eficacia.

Como
en
el
caso
id en eficacia y eficiencia.
anterior,
intervienen
los
siete
criterios,
pero
428 AUDITORIA DE TECNOLOOf AS Y SISTEMAS DEINFORMACIQN
RA-MA
CAPITLJLO 14. AUDITORIA DE TECNICA DE SISTEMAS 429
RAMA
ME3 - Cumplimiento de requisitos externos

Asegura
el
conocimiento
respeto
de
la
legislation
vigente
de
1.Queexisten
acuerdos
con terceros.
2. Que son consistentes con los objetivos de control
E1
cada
cumplimiento
ubicacion
de
(pais)
deberes
supone
multinacionales
que
puede
especificos
cada
estado.
en
los
una
suponer
Los
impuestos
complejidad
ajustes
de
requisitos
por
la
especial
estandares
en
-normativa
cuanto
en
y
que
las
regule
movimientos
de
internos
information
entre diferentes paises deben ser especialmente analizados y tratados.
indirecfamente
tanto
en
de
en
materia
fiabilidad
Tecnica
recuperation,
de
de
Sistemas
control
Protection
transparencia
de
de
de
Datos
las
encriptado
(back-up,
accesos,
pistas
de
en
cuanto
como
organizaciones
Como
observados
hechos
El panorama de regulacidn internacional que afecta a IT e impacta directa o

sistemas
3. Que se ejecutan
organizaciones
procedimientos
en
information,
de
auditoria...)
a
es
cuanto
deben
su
de
la
information
financiera y contable (Sarbanes Oxley).
No
del
un
determinando
sustantivas
pian
repetir
conceptos
de
misma
la
promover
objetivos
y
de
precisos
cumplimiento
clasicos
que
y
de
incluya
auditoria,
el
permitan
como
analisis
estableciendo
que
de
un
obtener
ia
necesidad
ejercicios
conjunto
unas
de
anteriores,
de
pruebas:
conclusiones
reilejadas
en ei informe correspondiente.
Se trata pues de aplicar las ideas anteriores al segmento de actividad al que
ultimo
concreto:
la
expuestas
anterioridad.
haciendo
los
se
El
ban
en
y
auditoria
de
que
corregido
informe
hincapie
los
de
comprobacion
responsables
ratificar
informe
final
una
ban
reflejar,
objetivos
nuevas
planteamientos
se
no
debe
o
en
plantear
para
cabo
puntos
este
al
fijar
las
la
las
realidad
que
o
objetivo
detectados
razones
respecto,
altemativas
un
recomendaciones
negros
caso,
conseguidos,
recomendaciones
originales
servir
llevado
debilidades
debera
aquelios
realizado
los
anterior, debe comprobarse:
procedimientos,
de
resultado
debe
olyidar
la
que
auditoria
estos
supone
coleccionar
profesional
se
realizan
soportar
su
el
de
las
las
unos
hechos
independiente,
dichos
pruebas
sustantivas
conclusiones
del
de
informe
informe
las
de
-como
auditoria
de
resultado
acciones
correctoras
posteriores
soslayar
cuantas
debilidades
funcionamiento,
para
en
es
base
direction
sistema
adecuada
de
con
contrastada,
de
que,
el
caso
de
de
la
funcion
en
profunda
acuerdo
con
los
consecuentemente,
final
que
debe
problemas
mejorarlo
pueda
para
que
Existe,
expuesto
el
desarroilo
tantd
de!
Sistemas
de
TS
especialmente
son
y
la realidad
mainframe,
que
la
de
construyen
existen
tipo
de
campo
Informacibn,
la
la
de
asi
de
auditoria
la
los
de
es
auditoria
como
importanies,
especificidad
Hoy
distintas
mini
ha
sido
Sa
con
el
pueden
ser
dispositivos cache, etc., etc.
entomos
dia
partes
fundamental
como
aspectos
tenor
de
diferentes
los
SI
que
cada
desarrollos
que
de
origen
de
la
los
actuales
cuanto
de
la
especificos
la
tecnificacion
entomos
tecnologicos
en
ubican
de
se
ademis,
rendimientos:
en
maquinas
de
micro,
sistemas
se
array
de
vias
otros;
entomo
que
elementos
beneficia
varias
puesto
del
agregacion
y,
aplican
discos
de
variedad
puros
en
menos
entomos
por
la.
entomos
son
desarrollos
que,
a
se
vez
unos
aimacenamiento
en
que
tecnologia
mencionado,
mainframe
origina
encontrar
de
de
se
diflcil
(PC)
micro
base
que
es
dispositivos
desarrollos
anadido
en
ejemplo
por
de
problema
evoluciona
como
grandes
pequehos
un
entomos.
de
tecnologia
poner
microinformatico
mis
los
actual,
tipo
baste
ademas,
de
de
los
acceso,
de
objetivos
Resulta
lo
en
generales,
existentes.
expuestas
nuevos
metodologia
aspectos
organization
mainframe
a
cuyo
la
el
requiere
para resolver las debilidades encontradas (controles compensatorios).

En cuanto
Para
realizado-
multiplicidad
nos estamos refiriendo: Tecnica de Sistemas.
El
de
ecuanime,
responda a los requerimientos que constituyen su razon de ser.
14.6 AUDITORIA DE LA FUNCION

vamos
ejercicio
juicio
contrastados.
podemos
trabajo
Una
No
el
un
auditoria (recopilacion de evidencias).
plantear
El criterio que prima, en este caso, es la integridad.
confeccioriar
que
emitir
estar
cumplimiento,
creciente,
aseguramiento
quiera
para
en el
punto
para
que
otras
red que
noirnai
en
soporta
una
un
completa
soporte
la
una
serie
empresa
de
microinformatico,
infraestructura
dc
de
cierto
tamano
ftincionalidades,
sirs
articulado
sistemas
junto
encontrar
con
generalmente
centrales.
alrededor
Pero esto
sino que se completa -tambien usualmente- con equipos en sus centros perifericos
un
entomo
entomos
no
medios
de
es
una
todo,
430 AUDiTORfA.DE TECNOLOGiAS Y SISTEMAS DE INFORMAC'ION
que intesran las instalaciones

y la electronica inherente.
En
sistema
entomos
operative,
con
los
correspondientes
enlaces
de
CAPiTUEO 14. AUDI T0R1A DE TECNICA DF. SISTEMAS 431
RA-MA
comunicaciones
En
grandes
organizativas
heterogeneos
gesror
O 'RA-MA
se
de
requieren
base
de
conocimienios
datos,
espetificos
herramientas
de
de
cada
desarrollo,
organizaciones
cumplan
con
estabiecimiento
de
ejemplo,
programadores
los
(operativo,
administration, seguridad y monitorizacion.
que
gestor
procedimientos
de
relativamente
criterios
no
datos...)
es
los
segregation
puedan
de
de
puedan
urdir
control,
funciones
modificar
quienes
sencillo
basicos
los
cuanto
para
que,
parametros
ejecutar
estrategias
en
programas
del
en
a
por
sistema
realidad
no
puedan modificarlos.
La funcibn, en estos casos,
diferentes y con equipos de personas distintas:
debe
ser
auditada
desde
dos
perspectivas
Pero
menos
Equipo
de
aspectos
operativos,
los
organization
como
procedimientos
generales
niveles
resolution
servicio
conocimientos
estabiecimiento
inberentes
como
de
con
dicha
de
infonnes
generales
separation
separacion
incidencias,
periodicos
que
de
entomos
planes
de
las
de
Tecnica
verifique
y
funciones
contingencia,.
de
Sistemas
sobre
veees,
recursos
determinados
producen
situaciones
se
como
parciales
con
donde
amcnazas
otros
porque
operativos
objetivos
cortsecucnciamediante
bien
tanto
la
medios
trata
de
de
como
elementos
segregation
debilidades
puedan
organizaciones
control,
dc
de
proceso
ftincionai
que
el
compensarse
no
auditor
dichas
mas
pequenas
grupos
de
con
servicio
departamentales,
existe
debe
surgen
-en
para
que
traves
de
determinar
debilidades,
bien
a
se
otros controles y/o medidas (seguros, por ejemplo).
el desarrollo de la tarea.
Puesto
*
Equipos
los
expertos
en
parametros
concepciones:
entomos
claves
espetificos
que
software
de
del
sistemas
operativos,
sean
capaces
base
gestores
de
de
en
sus
bases
de
complejidad,
puesto
infraestructuras
enlaces
una
se
red
para
comunicaciones
diferentes
solapan,
instalaciones
para
de
por
las
servicios,
ejemplo:
centrales
interconectar
mcorpora
datos
nuevo
pueden
lineas
(ordenadores
diferentes
un
de
y/o
redes)
ubicaciones
de
de
distintas
estabilidad
conectar
que
otro
conjunto
prevenirlas.
organizacion
soportar el servicio de correo electronico.

Los
mucho
vista
servicios
menos
del
control,
tecnolbgico
chocan
de
de
separation
flexibilidad
exposition
mbyiles
recibidos
el
y
de
vez
en
como
se
control
entomo
conexion
ataques
extemos
(via
VPN
WiFi
traves
de
mas
curso
dificil
su
ella.
abiertas
que,
desde
su
vigilancia,
de
pesar
de
creciente,
verification
limitados)
ftp...)
a
y
constituye
todo
de
de
ello,
lo
que
empresa
de
un
la
los
las
En
expldtacion,
probar
elevado
nivei
Pgr
flexibilidad
que
sobre
con
perfiles
dicho
penetration
una
una
robustez
servicios
de
de
de
se
tratan
un
especificamente
poco
en
el
area
constituye
un
aspectos
que
especifica
del
enlaces
prestados
componentes
de
de
trabajo
los
riesgos
del
planteamiento
desarrollo.
Hay
que
tener
las
mientras
cabria
como
de
otra
conexiones
(operadores
entre
que
las
trata
conseguir
falios
de
que
especificas,
a
sin
nuevos
y
compilar
las
entomos
ttna
necesidad
q
separaciones
mismos
comprobarla,
incidencias
restricciones
de
de
programas,
producidas
nuevas
acceso
de
versiones
conltevar
un
los
programadores
!o
para
funcibn
del
involucrar
ante
deben
(en
replica
incidencias
usuarios
pueden
de
otros
-siendo
laboratorio)
mencionadas
los
no
se
sus
existencia
(en
training
parte,
la
desarrollo,
implantation
comprobar
impartir
en
buscar
incluso
el
circunstancias
que
pruebas-
de
en
las
de
control
distintos
que
no
pueden acceder al entomo de production, etc., etc.).
mayor
creciente
entomos
-en
pennitiria
aplicacion.
la
obra
profundizar
production
procesos,
ocasiones,
reales
hemos
la
intentar
organizaciones)
ejecuciones
supone
conjunto
pero
punto
de
aislar
los
obiigaria
de
cl
el
y
ya
la
de
economicas
dado
apertura
facilmente
exterior
La
entomos
(web,
es
mundo
mas
afiadida
vocation,
comprender
necesarios.
el
en
publicas
complejidad
puede
Internet
basicos a vigilar y comprobar.
redes
empresarial
con
para
production-
una
cada
soluciones
seguridad
en
Internet
traves
generan
hacen
las
frontalmente,
aspectos
seguras
en cuenta que, llevadas las cosas al limite en el area de produccidn, se persigue la
para
y
la
presentc
vamos
nivel
existir
datos
la
sistema operativo y herramientas complementarias.
ver
La
que,
que
terminales/redes
de
de
TS,
distintas
que
fundamental
existencia
en
con
tienen
herramientas varias.
La
que
analizar
Los datos reales

casos
especlales
desvirtuindose
para
en
su
considerar
especialmente
proteccion
es
paises).
no
pruebas
creciente,
deben ser
de
eontenido
si
se
tanto
para
trata
en
accesibles
volumen
de
la
podrian
el
ni utilizados para pruebas: solo en

tomarse
traspaso
datos
al
como
entomo
punto
de
parti
correspondiente
de
caracter
personal,
Comunidad
Europea
como
en
da,
(a
cuyo
nivel
de
el
resto
de
432 AUDlTORiA D E TECNOLOGTAS Y SISTEMAS DE INFORMACiON
Ei
software
controlar
los
de
base
cambios
correspondiente
debe
aportar
dejando
herramientas
pistas
procedimiento
que
de
para
modiftcar
auditoria,
contemple
programas
debiendo
la
existir
segregacion
GAPlTULO 14. AUDlTORiA PETECNICA DES!STEMAS433
RA-MA
RA-MA
Constituyen
y
el
funcional
desarrollo,
cambios
por
sin
controles
La
verificable
consistencia
y
de
garantiza
los
que
programas
las
ejecutables
aplicaciones
en
con
los
ejecucion
fiientes
origen
es
coinciden
con
las
Debe
comprobarse
la
la
organization
existencia
en
precario
de
todos
frente
los
fiientes.
cualquier
La
El
perdida
modification
de
alguno
necesaria
que
afecte a la funcionalidad que soporta el programa en cuestion.

Un
permiten
control
accesos
elementos
especial
directos
sensibles
determinados
opiniones
unicamente
favor
de
eliminar
nucleo
dejan
disponer
sean
del
alguien
omnipotencia
de
con
estar
pista
de
de
estas
los
utilidades
operative
las
uso
los
fuera
despues,
acceder
datos.
Sistemas,
de
actualization
evitar
Con
que
que
trata
de
que
sistema,
para
de
Se
vez
realizadas.
del
elJas.
restringido
toda
modificaciones
fiinciones
Tdcnicos
de
especificado,
borrandolas
pudiera
en
dependencia
que
supondria
adecuada
que
atente
inadecuada
falta
la
contra
comprobar
de
la
la
(del
responsable
segregacidn
existencia
igualmente
supervision,
de
super-usuarios
segregacion
restriccion
del
funcional),
de
los
con
una
funcional.
Los
los
accesos
de
para
su produccion
casos,
detenninadas
valorado
hospital
ei
debe
en
negocio
ni
la
pueda
ser
funcion
consonancia
que
la
en
complemento
en
en
banco
repercusion
como
medidas
estar
un
de
organizacion:
misma,
no
son
iguales,
factores
(las
personas,
como
la
la
un
otros
o
con
en
fabricante
de
sustitucion
complejidad
el
sillas.
ni
la
por
por
riesgo
es
el
Aunque
no
la
probabilidad
ejemplo).
no
En
justificarse
en
cuestion,
que
ayudan
puede
estudiarse una politica de seguros:
-en
SPS Seguro de soportes de datos
Existen
cargandolas
que
-por
una
se
trata
de
esto
poder
buscar
riesgo
un
repercusion
ciertos
las
sistema
debe
necesarias
seguridad-
la
aplicarse
uso
no
de
cuando
debilidad
al
cuyo
casos-
debe
de
una
efectuar las revisiones conespondientes.
rnismo
a
lo
planificacion
deben
desarrolladas, validadas y 'que sirven de base para cualquier modificacidn posterior.
deja
una
concentracibn
(aprobacion del cambio, realization, validation y puesta en explotacion).
riesgos
ejemplo,
deben
estar,
los
mddulos
SPW Seguro de Software
tambidn,
SICO Seguro para cobertura de contingencias
del
SO
SPB Seguro de perdida de beneficios
la
no
sujetos a una normative rigurosa.

Ha
(sistema
de
tenerse
operative)
actualizacion
en
si
cuenta
el
existen
mencionada
nivel
parches
supondria
el
pendientes
riesgo
ante
de
de
aplicar,
dado
los
errores
que
vulnerabilidades
que las actualizaciones corrigen.

La
planificacion
posibilidad
de
que
permita
no
consideration
los
factores
de
altemativas
el
acciones
de
correcto
niveles
Tambien
metodoiogia,
de
debe
marcha
ser
atras
ante
funcionamiento
servicio
pactados
cuidadosa,
documentada
cualquier
del
eventualidad
sistema.
procurar
el
Ha
de
minimo
con
imprevista
tener
impacto
en
en
la
de
cabe
utiles
utilizar
historicos
existir
planes
de
respaldo
continuidad
en
cuanto
al
software
de
-en
la
riesgo
existencia
de
para
semiautomatica
especificos
a
ser
sobre
una
seguimiento
practica
parametros
de
habitual
y
la
y
adecuada
continua,
mediciones,
sintonia
para
existen
lo
del
sistema
cual,
herramientas
ademas
de
y
de
su
rendimiento
los
contraste
el
herramientas
un
tabulandolos
de
auditoria-
de
valor
objetiv-o
de
auditoria.
informe
sistemas
Gestion
En
este
de
Eventos
que
punto
hay
que
producen
que
destacar
simplifican
los
sistemas
de...
El
obtener
para
pistas
de
observaciones,
concretos
que,
casos
en
revisar
de
de
en
acuerdo
los
De
sus
la
con
resultados,
igual
forma
parametros
sistemas
complejos,
son especialmente recomendables.
informacidn
sistemas, as! como el adecuado soporte intemo/externo.
de
forma
cuanto
destacar
resultados
parametros
construyendo,
explotacion de! sistema.

Deben
conviene
recogiendo
debe
datos
objetivos
a) Detectar fallos de sistemas
que
permiten
b) Identificar situaciones imprevistas
evaluar su funcionamiento.
c) Controlar situaciones de excepcion
el
y
el
creciente
tratamiento
cuyo
analisis
desarrollo
de
es
la
de
los
ingente
determinante
Sistemas
cantidad
a
la
de
de
hora
4.34
AUD1T0RJA.DE TECNQLOGtAS Y SiSTKMAS Db INFORM A O l r i M

c RA-MA
RA-MA
CAPITULO !4. AUDfTORiA DE TECNICA. DH SISTEMAS 43-5
d) Estabiecer alarmas
La
e) Anaiizar comportamientos
Auditoria
importante
Sirvan solo \mos pocos ejemplos para considerar la importancia de un
adecuado aprovechamiento de la informacion que facilitan los sistemas (LOG) que
permiten, con herramientas especificas, descartar faisas alarmas e identificar
aconsejen
el
de
tecnologica
en
de
ataques
"*
el
Organizativa
la
gran
(cambio
que
la
deberia
organization
redimensionamienlo
tecnologico
comportamientos fraudulentos o intentos de intrusion. En ocasiones los productos ,,

mas sofisticados incluyen motores inteligentes que correlacionan acciones en \
diferenles sistemas que son capaces de revelar intentos combinados
en
de!
magnitud
instalacion
logics
evolution
(fusiones,
area.
Tatnbien
cuando
modifica
ERP),
ha
cuando
negocio
que
de
reaiizarse
de!
se
ha
dejar
un
produce
drasticamente
cuando
podido
existe
cambio
adquisiciones...)
pasado
la
un
desactualizados
que
un
cambio
infraestructura
periodo
nuestros
de
tiempo
recursos
de
Tecnica de Sistemas (5 anos en organizaciones de cierta magnitud)
! instalaciones.
La
' Tratando de resumir cuanto antecede deberiamos agrupar los diferentes
tipos de auditoria de Tecnica de Sistemas en:
anual
establecidos
Qrganizativa
de
i
o Funciones y recursos adecuados
o Procesos, estandares y prccedimientos defmidos
puede
ser
y
vista
debe
ser
mas
dinamica,
ya
que
trata
de
verificar
de
estandares
de
de
defmidos,
dichos
como
se
seguridad
conviene
estandares
funcionamiento,
que
cumplen
convenientemente
www.nessus.org).
Ver
plataforma
con
comprobar
estan
"parches"
"Nessus".
aiineados
de
para
sistemas
versiones
tipo
estan
los
por
(analisis
los
En
asl
(que
se
mismo
evitar
procedimientos
desde
el
punto
tipico
automatizado
casos
en
verificar
construyen
ejemplo,
los
actualizados
que
para
que
que
con
existen
los
equipos
estabiecer
entomos
cada
usuario
pueda
instalarse en su PC lo que le parezca, sin pasar por un estandar defmido o por una
^ o Cumplimiento de estandares y procedimientos
aprobacidn
para
actividad
diaria
funcionamiento
o Adecuada actualizacion de sistemas
de
los
el
uso
de
ofrece
de
una
herramienta
sfntomas
los
Sistemas
procedimientos
que
de
de
que
la
desgastc
Informacion,
tienen
que
ver
requiera).
por
conviene
con
Tambien
fallos
verificar
dichos
cuando
continuos
fallos.
el
En
en
la
el
seguimiento
organizaciones
grandes este tipo de auditorias y Test de Intrusion [I] se realiza de manera gradual,
, Preventiva
}
Operativa
adecuado
que
programas
seguros
i Qper&tvva
Auditoria
que "no se baja la guardia" en e! quehacer diario y, por tanto, un control de tipo
o Vigtlancia continua de patrones de ataques
o Detection de alarmas por comportamientos sospechosos

)
programando,
por
comporientes
para,
precisa
sistemas
) de lo que se protege y el riesgo de perdida o deterioro de lo protegido. En este

sentido, el sector de actividad, la magnitud de la entidad, la distribucibn geografca
ana,
mensuales
disponer
criticos
(alguna
de
de
una
una
o
aplicacion
parte
revision
de
los
global
con
componente
sistemas
puede
focalizacion
comprobarse
La
Auditoria
preventiva
trata
de
estabiecer
una
verification
continua
(24x7) y en tiempo real de los ataques de que son objeto los SI. En un principle se
desarrollaron
alarmas
las
para
sondas
su
necesidad
de
actuar
- eonformar la ftsncion de Tdcniea de Sistemas y su control. .
concepto
hacia
IPS
cerrando
que
no
desviando
afecten
creciente
de
ios
detectan,
lo
que
reducida
de
tipo
comprobacion
y los factores de riesgo inherentes deben ayudar a estabiecer los criterios para
Pemritaseme, eomo autor de este capltulo, ilustrar con algunos ejemplos

los tipos de auditoria enunciados.
analisis
cada
varias veces al afio). .
, Seria irracional dejarse llevar por la paranoia de la seguridad y no

considerar que los medios y presupuestos empleados deben ser acordes con el valor
en
ejemplo,
los
con
IDS
por
rapidez
(Intrusion
(Intrusion
tecnicos
ante
ciertos
Prevention
ciertos
tipos
sistemas
productivos.
patrones
de
complica
comportamientos
los
especialistas.
Aqui
una
importancia
decisiva
muy
los
en
de
ataque
bastante
claros
Sistemas
la
No
la
a
le
ocuita
de
analisis
e
de
de
de
detectaban
y
la
evolucionar
el
capaces
como
de
la
casos
dudosos
por
de
Eventos
de
todas
que
que
Gestibn
interpretacidn
para
complejidad
positivos"
automatica
detectad&s que son ingentes. Pongamos simplemente un ejemplo del impacto. de!
actuar
maliciosos
nadie
"falsos
decisiones
que
complejidad
son
identificados
se
mcncionados
conelacidn
La
hicieron
que
cantidad
toma
y
System)
ataques
System)
trafico
la
Detection
espccializados.
las
se
queda
parte
de
cobran
alarmas
436 AUDrrORjA DE TECNOLOGIAS Y S1STEMAS DE !NF0RMACI6N
correo
electronico
recibidos
en
una
organization
situation
SPAM
de
se
que
que
analizan
procede.
organizaciones
riesgo
critico,
aconsejan
considerar
e!
de
suponer
colapso
Servicio"
de
la
el
mensaje
de
Un
efecto
remitente,
que
se
del
de
las
con
la
con
nivel
de
exposition
entidades
del
herramientas
ataque
de
correo
de
por
filtros
grises
poner
tecnicos
(hablando
un
de
objetivo
de
La
La
de
introducimos
nadie
hay
de
la
un
pararse
ya
la
un
interaction
utilization
momento
conectividad
crecimiento
en
altamente
que
cualificados
reflexion
"Have
en
permitirse
maigen
de
la
opinion
esta
sera
alto
nivel
anterior
mano"
apiicativos
se
disponer
en
descontrolada
o
evolucidn
de
efectuan
las
modification
de
de
Internet,
pensar
nuestros
y
del
que
en
ni
que,
procesos,
todos
control
(y
esos
de
tecnologia
que
en
incluyendo
la
presion
nuestros
la
los
mecanismos
comprobaciones
los
de
vez
abrimos
nuevos
auditoria)
control
necesarias
existentes,
de
la
procesos,
no
metodologk
que
nuevas
desarrollos
para
el
lujo
de
utilization
una
de
disponer
de
de
las
concienciacion
desde
de
las
ver
mas
hace
para
para
sino
confirmar
el
las
volumen
compafiias
funciones
de
tanto
un
(empresas
equipos
y
caracteristicas
estandarizacion
COBIT
el
que
de
disponer
no
form
an
propios
mejora
de
en
desarrollo
inedianas
la
de
pero
la
extenso
pequenas)
tampoco
futura
fuucionales
no
quedarse
que
como
de
que
competitividad.
evolution
aspectos
muy
En
ai
mi
requerira
de
control
(y
de
4.1.
Procedimientos
en
evitando
la
(y
auditoria)
instalacion
para
de
incompatibilidades
nuevos
y/o
fallos
competitividad
podemos
la
olvidar
verification
0GC-1TIL
Commerce
los
introducir
riesgos
(auditoria)
cada
inherentes
de
su
vez
mas
ello,
adecuado
se
altas
necesita
esferas
un
.de
grado
la
creciente
organization
de
hasta
de trabajadores y colaboradores para liegar a entender que el control y la auditoria
sensibilization
todo
el
conjunto
Auditoria
de
la
"IS
serie
Auditing
www.ogc.gov.uk/guidance_itil.asp,
(UK)
patrocina
el
desarrollo
Office
of
"Buertas
de
Government
Practicas"
travds
de la Metodologia ITIL.
No
debe
dejar
Project)
de
citarse
Foundation
la
(Open
Web
Application
que
da
soporte
OWASP
(www.owasp.org)
Security
a
una
comunidad abierta que se dedica a investigar y luchar contra las causas

de
obliga
de
Guidelines
inseguridad
desarrollo
del
importante
(ademds
amenazar
modo
no
incrementa
rentable
vislumbrar
tecnologia
de
por
de
las
software
cuanto
internos)
a
los
Extranets e Internet).
mi
y,
corregirlos
14.8 LECTURAS RECOMENDADAS
garantizar
cumplimiento.
A
para
tecnologias
cada
posteriores que siempre repercuten en el negocio negativamente.

Dado
gobiemos
actualizados
PYMES
basico
los
es
permite
para
Es cada
vez mas
importante
disponer
de
unos
estandares
contrastados
(auditados) para no "reinventar la rueda" continuamente y convertir la gestion de
los sistemas en una "Torre de Babel".
que
fallos
funciones
no
ISO 17799 www.iso-17799.com
Es
de
ciertas
dado
que los sistemas no se nos van de las manos.
verificar
auditoria).
cuestiona
que
flexibilidad
posibilidades
requieren
dia
vulnerabilidadcs
regulatoria
especializacion
Esta
un
SUEVOLUCION
pero
presion
(outsourcing)
recursos
ejemplo)
14.7 CONSIDERACIONES SOBRE LA TECNOLOGIA Y

en
las
parte de su nucleo de negocio (core business).
pueden
Hoy
creciente
extemalizacion
proauctos
movilidad,
detectar
miedo a las amenazas ante un nuindo inmerso en un cambio acelerado y continuo.
"Seguridad
Gestionada".
de
es
(Grey
consiguiente
concepto
su
consecuentemente, mejorar los SI.
dominio
los
continua
no trabajan en contra de la organization y las personas sino a favor de todos y que
correo
los
supuesto
una
consiguiente
con
listas
el
por
el
Ja
evitar
vigiiancia
taques
bajo
con
mensajes
SPAM
utilizadas
de
los
combinado
contra
intemacionales,
servicio
de
neutralizan
necesidad
fmancieras
extemalizacidn
80%
intentando
remitente
junto
alto
un
servidor
del
con
del
identidad
tecnificacion
que
del
(DoS).
identidad
la
mas
resultados,
como
la
que
contrastar
La
los
puede
conseguir
eliminarian
permiten
del
de
Hay
suplantacidn
que
que
empresa.
"Denegacion
la
correo
List)
que
puede
de
es
SPAM
CAPiTULO 14. AUDITORIA DE TBCN1CA DE SISTEMAS 437
RA-MA
RA-MA
aplicaciones
y
dan
de
Esta
una
servicios
constituyen
sistemas
Web.
presentan
una
aplicaciones
exposition
extemos
oportunidad
information
que
lideran
al
riesgo
el
muy
las
organizaciones
muy
amplia
soportan
para
(Intranets,
438 AUDiTORU D TECNQLOGIAS YS1STEMAS DE INFORMACIQN
CAPiTL'LO 14. AUDITORiA DE TUNICA DE S1STHMAS439

RA-MA
RA-MA
14,9 CUESTIONES DE REPASO

I Ambito de la tarea. En el capitulo TF.CN1CA DE SISTEMAS se
circumscribe a...
a) No sirven para prevenir problemas
a) Todo los que tiene que ver con los SI (Sisternas de Information)
b) Verifican la existencia de procedimientos y su cumplimiento
b) Irifraestructuras (lr> que se necessta para que las Aplicaciones

fimcionen)
c) No sirven para mejorar
c) Solo lo referente a Centres de Procesos de Datos (CPD)
2 Definition de la funeion
6 Auditorsa de la funcion
a) Recoger evidencias quejustifican sus recomendaciones
a) La exploration de las Aplicaciones
b) No tiene que ver con nosotros
b) La adquisicion y el mantenimiento de las Aplicaciones
c) Las dos respuestas anteriores son correctas.
c) La instaiacion y el mantenimiento de la infraestructura Informatica
7 Consideraciones sobre la tecnologia y su evolution
3 El nivel de servicio
a) La evolution tecnologica incrementa la necesidad de control
a) La Ttimica de Sisternas debe garantizar el adecuado
funcionamiento de la infraestructura
b) La Tecnica de Sisternas debe garantizar la fiabilidad de las
Aplicaciones
b) La presion regulatoria hace innecesarios los controles

c) La extemalizacion (o outsourcing) no tiene future en el area de la
Seguridad de los SI
c) El nivel de servicio no es io mas importante de un Sistema de

Information
4Losprocedimientos
a) Una tarea organizada se descompone en una serie de actividades o
acciones
a) ITIL, COBIT e ISO son lo mismo

b) ITIL, COBjT e ISO son incompatibies
b) Los procedimientos determinan c6mo realizar determinadas

acciones
c) Las dos rcspuestas anteriores son correctas
c) ITIL, COBIT e ISO desarroltan paradigmas de control diferentes
54g AUOfTORiA DE TECNOLOGlAS y SISTEMAS DE INFORMACION
5.
(.Que
elementos
obtencibn
introduciria
gestion
del
plan
de
en
R.4-MA
un
procedimiemo
consentimiento
traves
que
de
regulara
Internet
la
en
su
organizacion?
6.
Establezea
fugares
un
actuation
para
garantizar
que
del sitio web de su organizacion en que sea
information
adecuada
personales.
Confeccione
en
coherente
sobre
el
tratamiento
caractcr
previo
una
polltica
con
todos
Jos
necesario se da la
de
de
Capftulo 18
datos
privacidad
clara, transparente y completa.
5:"
-*7.
8.
oCdmo
cumpliria
con
e!
deber
de
informacion
previo
almacenamiento de una cookie en el ordenador de un usuario que
conecta a su sitio web?
al
se
Establezea
su
una
politica
de
conservation
de
datos
aplicable
organizacion.
9.
Prepare
un
plan
en materia de
bases
de
de
formation
education
sobre
sus
protection de datos dirigidos a los tecnicos
datos
de
su
organizacion.
Incluya
un
responsabilidades
de sistemas y
documento
con
Javier Garzas
el
compromiso de confidencialidad que Jos mismos deberan firmar.
10.
(.En
que
condiciones
podria
su
comerciales no solicitadas a sus clientes?
organizacidn
enviar
comunicaciones
18.1 JNTRODUCCION
Los
sistemas
estrategicos
para
complejos.
Este
funcionamiento,
las
infonnaticos
son
organizations,
cada
aumento
dentro
de
de
los
uno
de
vez
de
complejidad
niveles
de
calidad
los
recursos
mayor
mas
tamaflo,
la
necesidad
que
se
criticos
mds
precisen
sofisticados
y
y
de
su
correcto
segun
su
finalidad,
hace que hoy las auditorias de aplicacibn sean una herramienta imprescindible.
pueden
Mas
aun
siendo
liegar
causar.
Standish
Group
infonnaticos
una
nunca.
El
resto
economicas
(de
debido
los
aeroespacial
en
aceptable,
funcionalidades
lo
de
(desastres
aviones
famosos
(Ambulancias
reflexionar
2001)
el
ccntenares
como
los
comerciales,
a
seflala
que
solo
estimado,
casi
con
una
En
de
software
del
etc.).
de
Londres,
los
lectores
que
ejemplo,
consumiendo
previstas.
del
p6rdidas
por
que
pero
las
sentido,
tiempo
hace
varios
fallos
de
este
mientras
las
algunos
hacer
En
(Standish,
finalizan
calidad
conscientes
de
5,
muchos
otros
de
sobre
importancia
la
en
Denver,
con
humanas
mision
informacion tienen para el funcionamiento de la sociedad actual (que presenta una
asi
que
los
rnenos
vidas
de
que
con
p^rdidas
por
etc.)
fmalizar
las
como,
la
del
proyectos
a
repasan
parecidos,
Aeropuerto
software
los
Uegan
Tecursos
dolares)
el
"CHAOS"
planificados
no
se
sondas
en
de
recursos
parte
sectores
las
fallos
informe
28%
mis
2002)
diferentes
Ariane
Y
los
muchos
millones
en
el
cuarta
(NIST,
los
el
ejemplo,
a
el
Marte,
como
casos
tienen
que
sistemas
de
S50AUDiTQRiA
DE TECNOLOQIAS Y S1STEMAS DE INFORMAC16N
RA-MA
RA-MA
AUD1TQRJIA DE APLICACIONES 551

CAPITULO 18.
dependencia cada vez mayor de estos), asi

lo que enfatiza aun mas la importancia de la calidad.
como
para
eS
bienestar
de
las
personas,
Las audiiorias de apiicacion pueden cambiar la forma en que un proyecto o

un producto se esta gestionando (Bernstein, I9SI). En pafabras de (Buckie, 1977)
t en unaauditoria.*
anabzara el papel que juegan las metricas como herramien a ^ sop0tte a la

Tambibn se estud'sara la necesidad de disponeT de entorrios q ^ aplicaciones
auditoria. Mostraremos en profundidad un metodo para au ^ y ^ueJias
software. Para terminar comentando un cotijunto de recom
priclicas a la hora de auditar aplicaciones.
una auditoria tiene el efecto de lograr que el grupo involucrado en la misma se

proporcionar
mismo.
la
mentabce sobre el estado en que esta su trabajo, que necesidades tiene y de

oportunidad
de
expresar
los
miedos
y
problemas
asociados
al
18.2 PRINCIPALES MODFl.OSDE REFEREMCIA^^ ^

A lahora de citar modeios para la actividad de se ban ido
La necesidad de auditar aplicaciories es aim mayor si la empresa desarrolla

el software de rnanera extemalizada, tendencia que en !a actualidad esta tomando
cada vez mas auge (B. Shao & Smith David, 2007; Simhan, 2006). Trabajar con
empresas de desarrollo exiemas (lo que se suele conocer como externalizacion u
outsourcing) permite a las empresas ceritrarse en su principal linea de negocio
apiicacionse suele bacer referenciaa modeios que desoe subcategoria o

desauoUado bajolaidea de descomponer lacalidaden es el
caracteristicasmas senctHas. En estesentido. el modeto - ei qu6 ia calidad
desanoUado por McCall (McCall, Richards & Walters, 19 ), * ^jegorias, vease
de un producto software se descompone en factores agrupados

en la figura 18 .1.
(como, por ejemplo, el transporte, la energia, etc.) y gestionar los desarrollos como
un servicio externo. Esto puede proporcionar importantes ventajas economieas,
pero de no establecerse los procedimientos necesarios para controlar la calidad de
las aplicaciones recibidas puede producir un efecto contraproducente. Aunque Jos
desarrollos se cedan a empresas externas, por lo general (no siempre pero si en la

mayoria de las ocasiones) el paso a produccion queda centralizado o es
responsabilidad de la empresa cliente, por lo que es imprescindible disponer de
procedimientos para auditar las aplicaciones. Las empresas deben evaiuar ta
calidad de los productos software que reciben antes de pasarlos a produccion, para
ascgurarse
de
que
cumplen
el
nivel
de
calidad
(ftincionalidad,
mantenibilidad,
rendimienio, etc.) requerido.
Central y lyfllt 0i ictu
JittflrtOifl
a attoi
E M M n e l i a i i i mi e tni f t Cifttineti eniieueldn
El problems que encuentran las empresas a la hora de determinar la calidad
Com plic! Sn
de una apiicacion es la complejidad que conlleva reaiizar el estudio de un producto

miiiKii
software. Esta complejidad se increments si e) proceso por el cual se ha
Toimncw i nam
desarrollado la apiicacion es desconocido para los responsables de auditarla. Como

veremos posteriormente disponer de metricas del producto o apiicacion software es
la manera mas rapida y fiable de tener visibilidad del estado de la apiicacion;
confiar solo en modeios de calidad de procesos -como CMMI (Chrissis, Konrad, &
SVirum, 2003)- no ofrece plena visibilidad sobre la calidad del producto. Tambi&i
igUrQ /S1
es importante comentar que la extraccion de metricas debiera soportarse sobre una

infraestructura tecnologica adecuada que haga realista la medicion en periodos de
tiempo razonables y que obtenga sfntesis de datos que ayuden a ia toma de
decisiones.
En este capitulo se discutiran, en primer lugar, los principales modeios de
Modelo de calidad de (McCall et al, 1977)
AutoQt lectpttMdid :
l dun ft 0i<J
luSinnintocffln
c*acicci tapiutan
CintnMiS
not p. miquina
PiQip. softcW Kill 11*
CSmu/ileic. son unit
Pata comprobar la calidad

factores
lo normal
hacer usoun p
valores
y para
ello esesnecesario
medicion del software.
Por otro lado, en la calidad de una apiicacion software se

lectos diferentes-
referencia a la hora de guiar una auditoria de apiicacion. Posteriormente se

tres
el codigo fbe't' a P artn de las caracteristicas intrinsecas, como
de
sueten distinguir
552 AUDlTORiA DP, TECNOLOGIAS Y SISTEMAS DE- fNFQRiVIACION
RA-MA
CAPITULO 18. AUDlTORilA DE APLICACIONHS 553
RA-MA
calidad externa; inedible en el comportamiento del producto, como, por

ejemplo, en una prueba.
calidad en uso: medible durante la utilization efectiva por parte del
usuario en un contexto determinado.
Siguiendo
McCall,
un
descompone
la
caractedsticas
aspectos
la
modeio
con
e
eficiencia,
los
modelos
importante
jerarquicamente
pueden
externa
usabilidad,
de
referencia
calidad
que
relacionados
calidad
filosofia
de
usarse
la
calidad.
interna
en
como
la
una
es
serie
lista
ISO
sets
y
clasicos
destacar
una
En
en
mantenibilidad
mas
se
que
como
ISO
caracteristicas
comprobacion
eategorizan
caraeteristicas
portabilidad)
calidad,
norma
de
de
9126
de
la
los
subdividen
de
que
sub-
(checklist)
atributos
(funcionalidad,
se
el
9126
de
de
fiabilidad,
su
vez
en
subcaracteristicas, vease en la figura 18.2.
Figura 18.3. Proceso de evaluacion de un producto software (ISO, 1999)
Otro
modeio
Information
and
Governance
Institute
gobiemo
de
las
de
Related
y
TSI.
que
referencia
Technology),
en
COBlT
2007
4.1
se
destacar
es
el
desarroilado
lanzo
la
COBlT
por
el
4.1
de
version
estructura
en
cuatro
siguientes: *
Figura 18.2. Modeio para la calidad externa e interna (ISO, 2001)
Por
evaluation
otro
de
cuantificables
situa
en
diferentes
una
tambien
aplicacion
pueden
eseala.
niveles
insatisfactorio).
lado
una
de
medirse
La
la
norma
software,
usando
escala
satisfaction
ha
de
ISO
14598
apoyandose
metricas
de
los
de
dividirse
requisitos
da
en
una
la
(por
visi6n
ISO
calidad,
en
Planificar y organizar (PO, de Plan and Organise)
cuyo
rangos
del
9126.
valor
que
ejemplo,
en
proceso
Los
de
aspectos
medido
se
corresponden
satisfactory
Adquirir e implementar (AI, de Acquire and Implement)

Entregar y dar soporte (DS, Deliver and Support)
Monitor!zar y evaluar (ME, Monitor and Evaluate)
(Control
Objectives
Information
COBlT,
dominios
para
de
for
Technology
apoyar
actividad,
el
los
554 AUDITQ RIA DE TECNOLOGIAS Y SiSTEMAS P INFORMACION
RA-MA
18.3 LAS METRICAS COMO HERRAMIENTA BASICA

EN LAS AUDITORJAS DE APLICACIONES
ES NEGESARJO QUE TODOS

MEt
LOS PROCESOS DE TSl
CAPiTULO 18. AUDITORH' A DE APL1CACIONES 555
O RA-MA
MONITORIZAR Y EVALUAR EL.

RENDIMIENTO ".DE TSI
SEAN EVALUADQS
Las
REGULARMENTE EN
software
CUANTO A SU CALIDAD V
ME2
CUMPLIMIENTOCON LOS
MONITORIZAR Y EVALUAR EL
CONTROL tNTERNO
For
en
CONTEMPLALOS
(ME')
un
&
buen
medio
Basili,
1999)
para
y
evaluar
pueden
ser
auditar
aplicaciones
utilizadas
para
tomar
AjS
CONTROL. ESTE DOMINIO
EVALUAR
son
Morasca,
mejores decisiones (Kitchenham et at., 2002).
REQUERIMIENTQS DE
MONITORIZAR Y
metricas
(Briand,
ME3
ASPECTOS DE GESTION
GARANTIZAR
EL
CUMPLIMIENTO
LEGAL Y REGLAMENTARIO
evaluar
proceso
de
DEL RENDIMIENTO, DE LA
entrcgadus
MONITORIZACIDN DEL.
PROPORCIONAR GOBIERNO
CONTROL INTERNO, DEL
la
lo
general,
en
las
la
calidad
de
ios
production
o
del
documentos
manera
mas
auditorias
software,
que
son
rapida
de
aplicaciones
entregables,
productos
que
incluyen
producidos
fiable
tener
medicion
software
todos
durante
de
ia
del
el
los
de
vida
sobre
centrada
salidas
productos
ciclo
visibiiidad
esta
del
inteimedios
del
un
software.
producto
es
recogiendo metricas del producto. .
PARA TSi
CUMPL1MTENTO CON
ME4
No
NORMAS Y LECISLACION,
Y PROPORCI ON AR
sin
GOB1ERNO.
que
Tabla 18.1. Divisiones del area monitorizar y evaluar de COBlT
guias
de
para
la
actividad
establecer
la
de
"monitorizar
auditcrla.
La
tabla
evaluar",
18.1
de
muestra
obstante,
donde
con
pueden
mas
obtenerse
detalie
el
las
dominio
no
tenga
calidad
duplicado,
el
productivas
ENFOQUE DE MONITORIZACION
MONITORIZAR Y
las
MONITORIZAR Y
REPORTES E INFORMES PARA LOS NIVELES
ME1.S
la
EJECUTIVOS Y DE ALTA DIRECCI6N
RENDIMIENTO
DE TSI 1
ME 1.6
aplicacion,
software,
excepciones
cobertura
pruebas,
no
de
software
libre
permiten
auditar
estatico
gran
de
de
el
controladas
veremos
parte
las
de
largo
un
la
medicion
la
fiables,
posibililando
la
calidad
del
de
etc.).
el
del
estilo
ademas
infraestructuras
software
de
manera
software,
su
la
codigo
compilation
incidencias,
muy
hacer
continuation,
mantenibilidad,
pruebas,
control
de
codigo,
periodica
puede
de
con
altamente
diaria
un
estudio
en
profundidad
de
las
metricas
aplicacidn
cldsieas
de
"monitorizar
TSI"
ayuda
evaluar"
mediante
la
el
area
aportacibn
considerar en la auditoria de la aplicacion. (Vease tabla 18.2).
ME: Monitor aid Evaluate en ingles.
de
mas
donde
aun
el
si
el
receptor
desarrollo
del
es
software
realizado
debe
por
equipos
establecer
sus
externos
propios
fabricas
sistemas
de
control de la calidad.
ACCIONES CORRECT1VAS
Tabla 18.2. Divisiones del area Monitorizar y evaluar el rendimiento de TS
1,2
automatizar
manera
que
Como vimos, la medicion es pieza basica a la hora de auditar la calidad de
EVALUAR EL
de
las
como
de
tiempo
18.4 ENTORNOS PARA LA EVALUACION DE LA

CALIDAD DE LAS APLICACIONES
EVALUACION DEL RENDIMIENTO

MEt.4
ME1
Rendimiento
de
en
METODO DE MONITOR]ZACiON
ME1.3
Dentro
posible
software
costoso
Aunque,
an&lisis
ciclomdtica,
metricas
tan
automatizacidn remitimos al lector a (Piattini, Garcia, Garzas, & Genero, 2008).
INFORMACION DE MONITORIZACION
RENDIMIENTO
DETS
es
de
ser
medir.
que
Para
DEFINICION Y RECOPILACION DE LA
ME1.2
(e!
puede
totalmente automatizada,
MEI.l
EVALUAR EL
dia
lanzamiento
herramientas
ME1
en
producto
complejidad
proyecto,
recogidas
adecuada
sentido
hoy
del
programacion,
de "monitorizar y evaluar", asi como las partes en que se descompone.
realizar
infraestructura
afortunadamente
En la aplicacion de COBlT a la auditon'a de una aplicacion cabe destacar el
dominio
una
"Monitorizar
de
elementos
Si
bien
con
metricas,
anos
de
Evaluar
el
convicrtan en practica de
concretos
es que se tenga en consideration:
revisioncs,
experiencia,
mspecciones
en
la
controles
actualidad
lo
de
que
calidad
hace
que
son
Areas
estas
se
uso, util y de la que se pueden obtener amplios beneficios
5S6 AUDITORIA DE TECNQ LOGIAS V SISTEMAS DE INFORMACION
Definir
son
unos
objetivos
necesarios
por
claros
que,
RA-MA
medibles,
evitando
asi
determinando
riesgos
eomo
que
que
el
datos
exceso
de
CAPlTULO 18. AUD1TOR1SA DE APUCACIONES 557
& RA-MA
entomos
de
medicibn
que
forman
la
infraestructura
para
la
auditoria
de
las
aplicaciones.
information haga perder el objetivo final del programa de medicion.
18.5 UN METODO PARA AUDITAR APLICACIONES
2 Realizar las mediciones de manera periodica y frecuente,

permltiendo tomar acciones correctivas en el momento oportuno,
SOFTWARE
proporcionando la base de acciones proactivas mas que reactivas.

3
Automatizar
proceso
de
que
una
medicion
obstacuiizar
que
se
objetivos,
puede
el
ya
medicion,
may
muestre
para
posihilitar
costosa
de
en
manera
los
tiempo
elara
la
anteriores
muy
manual
informacion
de
18.5.1 Fase 1.- Definir el plan de la auditoria de la aplicacion

18.5.1.1 DEFINIR EL ALCANCE DE LA AUDITORIA, OBJETIVO Y
caracter estrategico o que por su coste en tiempo baje su periodicidad y
METODO
frecuencia.
4
Definir
diferentes
detalles
muestren
estrategicos)
la
construccidn
de
requiere
con
presentation
a
marco
un
un
el
analisis
de
llevar
para
practice,
que
torna
metodologico
tanto,
los
de
que
y
valores
la
obtenidos
soporte
metricas
la
La
medicidn
un
exacto
automatizar
los
tacticos
de
las
en
decisiones.
cabo
como
eficiente
pentiitan
perderse
(operativos,
la
permita
Por
modo
herramientas
y
que
eviten
niveles
para
soporte
2000).
que
los
precisa
un
de
abstraction,
todos
de
(Lavazza,
evaluadas
contaT
de
informacion
tanto
tecnologico
ser
niveles
es
dicbas
metricas
(Giles & Daich, 1995).

Con
permiten
mayor
obtener
menor
mediciones
Herramientas
e!
analisis
exito
y
Estas
de
del
existe
un
pruebas
de
Analisis
software
henamientas
muchas
gran
numero
una
de
herramientas
aplicacion
software.
que
Dinamico:
ejecutando
suelen
aqtmllas
el
requerir
codigo
el
uso
herramientas
fonna
de
tibrerias
que
realizan
dicho
software.
especiales
de
cabo e! analisis
Analisis
Estitico:
sin necesidad
de
aquellas
Dc
ejecutar
que
el codigo fiiente.
Este
llevan
tipo
de
abordar
objetivo
de
heterogeneas
auditoria
manera
en
la
la
misma.
dimensiones
conviene
general,
destacar
(operaciones
que
personas)
obtencidn
del
En
auditoria
determinar,
dos
la
en
una
elementos
estudiar.
ademas
computadora
aplicacion,
import
estos,
fiituras
las
calidad
de
etc.,
de
influiran
(el
de
con
evolucionar,
fuentes,
el
las
el
escritas
ocasiones
el
tiempo
los
calidad,
el
ha
un
evolucionado
conjunto
mucho
muy
en
solido
los
de
ultimos
anos,
herramientas
de
la medicion. Aunque en la pr&ctica estas herramientas se organizan formando
Por
en
la
software
actualidad
libre
para
auditoria
focalizar
parte
efectos
su
en
en
de
posibilidades
de
econdmico
que
la
falta
muchas
costes
en
de
su
diseiio
de
es
puede
bien
la
de
ser
el
aplicacion
auditada,
composicidn:
una
Ienguaje
un
las
que
es
fuentes
entendibie
Ienguaje
la
Ia
construction
aplicacion
misma,
en
evoiucidn,
de
control
todos
sobre
aplicaciones
tiempo
correcta
de
que
la
lo
ellos
este
vayan
pueda
acorde
se
productivo
puede
punto
ido
su
financieros
de
de
derivarse.
ha
describe
escalabilidad
perdiendo
recursos
la
sentido
otro
parte
van
lado,
los
dinamica
orientadas
ejecutables
productiva
a
recogen
el
funcionamiento
de
la
misma.
eomprobar
si
ei
correcta segiin los requisites que se definieran para el mismo.

area
la
aplicacion
por
ser
las
en
las
su
En
la
derivando
en
capacidad
de
implica
su
que
evolution.
este
encontrar
de
de
para
que
en
programa
mantenimiento
impacto
las
por
su
programactbn,
en
versiones,
mantenimiento
forman
El
plan
de
antes
ejecuta,
objetos/ejecutables
Respecto
analisis puede ser realizado sobre el codigo fuente o sobre el hytecode.
podemos
una
ejecutado por una computadora, generalmente codigo de maquina).
mayoria
herramientas
la
importante
que
Herramientas
tarea
y
Obietivo de la auditoria
Estas
inciuso pueden necesitar recompilar el codigo del programa.
de
hormas
que
alcance
sera e! objetivo del estudio, cual sera el metodo a usar, si sera dinamico o estatico.
las
herramientas de evaluacidn de la calidad se pueden dividir en dos tipos:
haber
objetivo
necesario
la
primera
el
puedan
adquisicion,
para
La
definir
Las
software
auditorias
se
de
de
cornporta
la
aplicacion,
aplicacion en
de
manera
558 AUDITORIA PE 7ECNQLOGIAS Y SISTEMAS DE INFQ RMACION
de
la
Tomando
como
auditoria
de
fiabilidad,
los
Sa
usabilidad,
anteriores,
base
el
estandar
aplicacion
Como
ya
ISO
puede
mantenibilidad,
RA-MA
9126
ser
ia
portabilidad
comentamos,
(ver
puede
seccion
18.2),
funcionalidad
eficiencia.
subdividirse
de
el
la
Si
bien
en
otros
CAPfTULO 18. AUDtTORtlA OF,APUCACIONES 359
RA-MA
Funcionalidad
objetivo
misma,
cada
Fiabilidad
Usabilidad
Mantenibilidad
Portabilidad
Eficiencia
su
uno
de
objetivos
de
Esiatica
Din&mica
menor nivel.
M6todo
Tabla 18.3. Ejemplo de alcance de la auditoria

Cuando
hablamos
referenda
al
conjunto
ejecucion
de
la
refieren
aplicacion
se
de
cuwple
Las
si
los
observar
pruebas
aplicacion.
comprobar
suelen
de
la
m4s
funcionalidad
cargas
aplicacion
inspecciones
auditorfas
requerimrentos
utilizar
la
de
de
podemos
tipicas
la
carga
masivas
que
en
este
aplicacion
de
dinamicamente
es
rendiraiento,
usuarios
realizar
caso
la
hacemos
mediante
la
las
que
se
si
3a
son
esperada
pruebas
para
simulados
las
que
observando
su
18.5.1.2 ESTIMACION Y PLAN1FICAR

Observando
del
alcance
Sa
aplicacion
instrucciones
las
Como
un
de
forman
caracter
una
calidad
el
Las
de
grado
influencia
observaremos
ficheros,
producto.
la
ocasiones
tienen
estatico
codigo,
el
observar
las
comentamos
de
(documentos,
que
orientadas
mayoria
estudio
etc.),
de
destacando
auditorfas
la
los
mas
directa
los
del
de
muy
alta
en
que
de
manera
general
estaticos
forman
son
que
este
caso
y
futura
Para
compleja.
etc.,
misma,
ya
las
en
en
que
evolucion
la
como
y
en
pudiera
pudiera
suelen
tambien
dependientes
denominate
pruebas
mientras
uno
los
que
los
los
estudios
se
les
dinamicos
suele
llamar
inspecciones.
Para
mdtodos,
una
Por
es
con
cada
dinamicos
auditoria
ejemplo,
realizar
en
para
Ia
anteriores
si
bien es
profundidad
de
alguna
auditar
pruebas
inspecciones
auditar
de
o estaticos,
sobre
fiabilidad
la
eficiencia
dinamicas,
o
el
pero
c6digo,
de
se
que
caracteristica
muchas
caracter
la
adecua
en la
o rendimiento
en
de
seguridad
objetivos
cierto
debera
de
la
se
uno
de
de
las
hacer
uso
aplicacibn
ocasiones
estatico.
aplicacion,
mas
mayoria
estas
Igualmente
utilizan
casi
los
de
!o mas
se
a
en
La
tabla
18.3
muestra
un
aplicacion
es
e!
definir
auditar
plan
en
funcion
temporal
de
uno
No
de
cualquier
desarroflo
de
los
para
elementos
para
realizar
una
obstante,
esta
puede
la
estimacion
experiencia
del
su
asociada
auditoria,
estudiar
podemos
aproximacion
ser
una
equipo
con
un
siempre
producto
es
encontrar
una
un
tarea
metodo
del
tiempo
que
la
las
tareas
mas
complejas
la
aplicacion
de
auditor
como
de
auditoria
vez
determinada
la
estimacion
de
la
auditoria
se
elabora
e!
plan
Es importante en esta tarea aprobar con el cliente la estructura org&nica de

la
auditoria,
comun
etc.,
del
que
cliente.
acciones
que
puede
El
la
temas tecnicos concretos.
El
equipo
estar
cliente
deben
auditoria.
compuesta
debera
comunicarse,
auditor
en
preparar
asi
tambien
como
puede
varias
la
fases
tanto
aplicacion,
planificarse
requerir
de
de
reunir
personal
su
anadirse
auditor
documentacion,
al
especialistas
plan
de
extemos
la
en
medida
18.5.1.4 DEFINIR LAS HERRAMIENTAS DE USO EN LA

AUDITORIA
pruebas dinamicas e inspecciones estaticas.
alcance de la auditoria.
la
tarea
18.5.1.3 DEFINIR FX EQUIPO DE LA AUDITORIA Y EL PLAN DE

COMUN1CACION
como
de
de
temporal y de recursos de la misma, en funcidn de las restricciones del proyecto.
ambos.
hora
su
adaptarse
complementan
igual
parte
siguiente
auditar.
dos
ocasiones
la
la
suceder,
para
cada
tanto
Una
recordar
sea
requerir.
los costes asociados a la misma.

Cabe
de
definido
suele
software,
con
diseno,
la
su
que
fuentes,
tipicas
programacion,
mantenibilidad
productos
tamano
recursos para la mlsim.
comportamiento.
Hn
el
previamente
ejemplo
de
las
combinaciones
que
defmen
el
Las
herramientas
de
apoyo
la
auditoria
tambien
deben
Entre estas estaran herramientas para pruebas de funcionalidad. carga, herramientas

de inspeccibn, extraccion de metricas, etc. Como en cases anteriores las
herramientas para auditar la calidad de la aplicacion tambien suelen cianficars^ ^
entre dinamicas y estaticas. ... ...
especificarse.,
560 AUDITORIA DE TECN'OLOGiAS Y SISTEMAS DE INFORM AC ION
De
marsera
resumida
ias
herramientas
RA-MA.
estaticas
recorren
el
codigo
fuente
la aplicacion obteniendo metricas y elementos que muestren su calidad.
de
CAPITULO 18. AUDITORIIA DE APLICACIONES 561
ffl RA-MA
tipo
de
herramientas
Por
su
parte
aplicacion mientras
Como
Variable local no utilizada
ejempio
tiempo
de
cobertura
Bucle "while" vacio
probado
son
podemos
a!.,
las
herramientas
se
ejecuta
eitar
analiza
Problemas del Javadoc en rnetodos
destacar
de
las
con
los
herramientas
desarrollo
2008)
se
proftmdiza
sobre
este
tipo
de
ciasificadas
y por
herramientas
si
la
como
dinamicas
no
hacen use
lo genera!
como
aplicacion
Purify,
produce
de
trabajan
IBM
problemas
del
sobre
codigo
Rational,
en
la
la
fuente.
que
en
memoria
del
Eclipse,
tambien
pruebas,
casos
como
o
de
es
el
conjunto
decir,
prueba
de
EclEmma,
Cobertura,
que
que
de
tanto
herramientas
por
ciento
orientadas
de
proporcionados
por
los
software
que
trabaja
calcula
libre,
el
porcentaje
de
la
medir
aplicacion
desarroliadores.
sobre
codigo
la
queda
Ejemplos
el
entorno
de
que
cubren
los
casos de prueba. (Vease en la figura 18.4).
Estilos javadoc
lavadoc en clases e interfaces
Estandares documentation
Bucles "for" que deberian ser "while"
Evitar asignaciones en parametros
Densidad en sentencias switch
Evitar inicializadores estaticos
Convenios para nombrar clases
esta
ejecucion
Cabe
et
equipo informatko sobre el que se ejecuta.
Sentencia eondicionai vacia
(Piattini
entornos).
Atributo privado que no es utilizado
(en
Etc.
Tabla 18.4. Ejempio de metricas tipicas en una inspeccion de codigo estatica
La
nurnerosas
variedad
de
herramientas
contemplan
pueden
Tabla
18-4
herramientas
lenguajes
son
un
trabajar
las
gran
en
rauestca
un
comerciaies
de
ejempio
y
de
programacion.
aplicaciones
numero
mod
de
PMD,
metricas
batch
(por
de
software
Un
tipo
libre
ejempio
Checkstyle,
y
este
a
lotes)
como
detecclones.
soportan
destacar
etc.,
problemas
de
que
de
de
dentro
software
calidad,
plugins
de
Existen
una
amplia
de
libre
que
que
tambidn
Maven
usada para automatizar la compilacion, construccidn,

etc., de
desarrollo software), la Figura muestra como ejempio un entorno basado en este
herramienta
Figura 18.4, KEM1S como ejempio de entorno de medicion de la calidad
estas
(una
un
18.5.2 Fase 2.- Ejecucion de la auditoria

La ejecucidn supone Ilevar a cabo ios objetivos y tareas, con las
herramientas defmidas, seguri el plan de la auditoria.
RA-MA
562 AUDITORIA DE TECNOLOCiAS Y S1STEMAS DE rNFORMAClON
Una de
una
reunion
las
actividades
inicial
de
considerar
arranque,
en
la
a] comienzo de
que
se
la auditoria
presente
al
equipo
CAriTULO 18. AUDITOR] iA OF. APLICACiONES 563
RA-MA
La figura 18.5 muestra
es mantener
el
cronograma
orientada
observa
suelen
de
organizar
las
en
tareas
torno
de
comprension
reuniones
de
extraction
revision,
observar
el
un ejemplo del resultado de una prueba
comportamiento
de
la
aplicacibn
de usuarios que trabajan de manera concurrente con la
detaliado para la ejecucion del proyecto, as! como los objetivos del mismo.
Muchas
en
de
las
information
que
se
se
examina
la
nivel
el
de
numero
detalle
es
de
alto
enores
y
por
pagina.
orientado
Como
puede
proporcionar
la
al
ir
creciendo
de auditoria
el
numero
misma. En la figura 18.6 se

observarse
informacion
en
estos
casos
el
necesaria
para
la
posterior resolucion de los probiemas.
aplicacion detectando e identificando anomalias, con el objetivo de:
Verificar que la aplicacion satisface una serie de atributos espetificos

de caiidad.
Verificar que la aplicacion es conforme a las normativas, estandares,
directrices, planes y procedimientos aplicables.
120 j
10G ;
Identificar las desviaciones respecto de los estandares y las

especificaciones.
30
Recoger datos sobre las apiicaciones (anomalia y esfuerzo).

OJ 60 <
En
aplicacion,
dtchas
la
ido
generando
que
la
para
describen,
incluso
se
reuniones
aplicacion
en
ban
su
su
la
se
sueJe
ejecucion
los
procesos
diferentes
gestion
de
la
con
como
respecto
las
trabajar
construccion,
analisis
ocasiones
controlado
subproductos
en
pudieran
los
usados
con
los
productos
ser
requisitos
para
versiones
su
los
que
la
o
plan
de
de
se
documentos
aplicacion,
el
fuentes
que
debe
construccion,
de
configuration,
ficheros
intermedios
de
cumplir,
por
diseno
etc.,
ejemplo,
sus
para
El
serie
analisis,
los
de
20 !
00:04:00 00,03:00 00:14-00 00:19:00 00:24:00

- Errors Users
Figura 18.5. Ejemplo de errores de la aplicacion en funcion del numero de

usuarios concurrenies
18.5.3 Fase 3.- Analisis, sfntesis y presentation de resultados

de
su
construccion.
uno
40
como
productos
proyecto
la
hubiesen
sintesis
puntos
mas
comentarios
presentacion
determinantes
en
los
que
de
se
del
la
informe
misma.
describa
El
ia
de
auditoria
auditor
situation,
el
es,
debera
riesgo
sin
duda,
elaborar
existente,
una
la
deficicncia a solucionar y, en su caso, sugerira la posible solution.

Una de las cuestiones a tener en cuenta es que la presentacion de los datos
y
los
in
requeriran
formes
los
asociados
lectores
deben
del
mismo.
esiar
preparados
Comunmente
para
suele
el
haber
nivel
dos
de
abstraction
tipos
lectores
que
del
informe, directivos, para los que se suelen presentar informes resunien a un nivel
de
abstraccion
resolution
dc
alto,
los
el
personal
probiemas
involucrado
detectados,
para
en
los
la
elaboration
que
se
de
preparan
la
aplicacion
informes
y
con
mayor detalle.
Figura 18.6. Ejemplo de tiempos medios de respuestapor cadapdgtna
i
*
"lit
mammm
564 AUPlTORiA DE TECNQLQGtAS Y S1STEMAS Dh INFORM ACIQ N
En
el
auditoria
suelen
informe
resumen
acompaflarse
informacion
Estos
del
de
informes
resumirse
orientado
lugar
importante
suelen
suponer
caso
ser
solucionar
el
La
directives;
se
como
y
a
la
la
la
Como
toma
hailazgos
18.4
se
que
de
se
cada
en
la
corroborar
de
se
hailazgos
e!
coste
hallazgo
CAi>iTULO )8. AUDlTORtiA DF. ARUCACiOKES 565
RA-MA
ejemplo
pueden
aplicacion y
posterior
hallazgo,
da
tin
los
la
decisiones
del
encontrados
muestra
observa,
dentro
de
severidad
prioridad
los
labia
han encontrado
orientada
hallazgo
directives
agruparse.
en que
campos
RA-MA
de
la
resultados.
las
Como
conclusiones
resultado
mas
se
presentar
importantes
las
un
que
informe
se
ha
final
llegado.
en
el
(Vease
que
en la
tabla 18.4).
otra
auditoria.
que
los
expongan
pudiera
18.6 RECOMENDACIONES Y BUENAS PRACTICAS
en fitneion
de los anteripres.
A
nuestra
modo
de
experiencia
conclusion
son
final,
de
buenas
importantes
la
cuantitativos
practicas
hora
de
recomendaciones
realizar
la
que
auditoria
de
en
una
aplicacion software:
A
modo
de
recomendacion
cabe
comentar
que
los
informes
deben
ser
siempre concisos, cuidando que la informacion que muestre sea significativa.
HALLAZGO
CAPA
ARQUITECT6NICA
Utilizar
metricas
gran
ayuda,
1<
I PUIORIPAD
>'
La
pcriodicidad
aplicacion
en
Probiemas en la
rnetodo
gestidn y uso de
Si
muy
Caches
Negocio
factores
aportando
ademas
obtenidos
argumentos
de
solidos
la
aplicacion
para
es
concienciar
de
sobre
el estado de la aplicacion.
COSTE i
SEVERIDAD
1-8.
es
con
la
muchas
que
infraestructura
periodicidad
se
ocasioncs
pretenda
vendrd
disponible
costoso
obtener
disminuira,
de
para
datos
ahi
realizar
medir
sobre
la
las
determinada
la
el
la
calidad
estado
irnportancia
auditorias
por
de
de
de
la
complcjidad
del
de
la
la
aplicacion
automatizar
aplicacion.
al
la
maximo
dicha recogida de datos para la auditoria.
JOINS y
ConsuUas
Datos
Complejas
.5
Con
1.6
una
datos
buena
para
problema
Database Link
Datos
hacer
1.4
las
de
con
infraestructura
auditorias
recopilar
ella,
por
un
lo
para
hay
excesivo
que
la
que
es
automatization
tener
presente
volumen
muy
de
que
de
la
es
facil
informacion
importante
tener
obtencion
claro
caer
no
los
de
en
saber
el
que
objetivos
alcance que persiguen las auditorias.

Gestidn de
Negocio
1.35
En
cada
auditoria
quidn,
segun
Sesiones
cada
Presentacidn
Servidor de
Presentacidn
Para
ciertas
de
12
las
Segurida
Tambien
d
Datos
o de Tablas
auditoria,
Acceso a EJBs
Negocio
Tabla 18.4. Ejemplo de informe de auditoria

Una
vez
elaborados
los
informes
estos
seran
comentados
discutidos
definir
que
abstraccidn
implicard
que
la
informacion
informacion
mayoria
de
mostrar,
que
se
las
organizaciones
ia
por
actividad
frecuentemente
en
muchas
su
periodicidad,
de
audi
tar
se
recurre
ocasiones,
la
bien
etc.,
aplicacion
esta
lo
cuando
requiera
ocasioncs
option
por
mas
y
en
existan
la
para
complejidad
conveniente
empresas
por
que
ultimo
sera,
por
que
nunca
ejemplo,
se
debe
alinear
perder
objetivos
de
de
vista
negocio
el
es
especiaiizadas.
buscar
objetivo
con
increraentar la productividad y rentabilidad del desarrollo, aumer.tar la calidad del
..
los responsables directos de las areas afectadas con el fin de comunicar y
de
un
actor
extemo que otorgue mas objetividad a la auditoria.
1.6
Esto
auditorias,
externalizar
Particionarnien
importante
nivel
varios informes finales resultantes de la auditoria.
Aplicaciones
Filtros de
situation.
es
el
con
planes
final
de
de
!a
mejora,
<66 AUDITOR)A DE TECNOLOGi AS Y S1STF.MASDE INFORMACiON
software
la
competencia,
satisfaction
etc.
Todos
soluciones
de
diferentes
propuestas
ingenieria
del
relacionados
del
software,
la
van
las
Cabrera,
partes
decision
de
cualquier
surgiendo,
una
maximization
(o
disefio
de
del
respecto
que
una
pretende
del
valor
sistema;
reingenieria)
de
metodologica
deberia
y,
un
en
sistema
estar
en
estimacion
productividad del software, Ra-Ma.
orientar
las
aportado
a!
sentido,
software,
de
una
caracter
auditorias
la
B.
su
Shao,
cada
la
creciente,
aplicacion
debido
la
tendencia
robustas
pueden
procedimentacion
auditoria
procedimientos
tiene
de
la
hacia
criticidad
la
acompanadas
de
las
aplicaciones
externalizacion,
de
disponer
de
entornos
metodos
encontrarse
modelos
de
un
amplio
seguimiento
de
las
caracteristicas
auditoria
sean
auditorias,
si
bien
pecuiiaridades
adaptados
es
propias
las
importante
que
recordar
implicar&n
condiciones
especificas
que
de
que
M-
para
(Eds.).
Medicion
(2008).
mejorar
la
calidad
&
Smith
(2007).
The
impact
of
offshore
outsourcing
for
L.,
Software
Morasca,
S.,
Object-Based
&
project
Basili,
high-level
management
V.
(1999).
IEEE
design.
Journal
audits.
Defining
and
Transactions
of
Validating
on
Software
Buckle,
J.
K.
Chrissis,
M.
Managing
(1977).
Software
Projects.
New
York:
American
B.,
Konrad,
M.,
&
Shrum,
S.
CMMI:
(2003).
Guidelines
for
Process Integration and Product Improvement: Addison Wesley Professional.

Garzas,
J.,
Cabrera,
D.,
&
Piattini,
M.
T.
(1995).
La
(2007).
ingenieria
del
software
basada en valor.
los
Giles,
A.
E.,
&
B.
A.,
Daich,
G.
Universal
CrossTalk
MetricsTools.
(February).
Afortunadamente
infraestructura
fiable
obtenga
de
metodo
esenciai
de
J.
Genero,
Elsevier.
cada
aplicacion. '
modelos
B.,
Bernstein,
L.
(1981).
Systems and Software, 2(4), 281 -287.
solidez, como los modelos ISO o COBlT, que son de una gran utilidad a la hora de
establecer
David,
&
metodos
Engineering, 25(5), 722-743.
estrategico
actualidad
J.,
y
on IT workers in developed countries. Communications of the A CM, 50(2), 89 - 94.
automatizados.
En
Garzas,
tecnicas
18.9 B1BUOGRAFIA
Measures
necesidad
de
F.,
software:
por
18.7 CONCLUSIONS
su
del
la
Briand,
Existe
Garcia,
las
"valor". '
software,
M.,
en
guiada
Piattini,
las
Basada
este
CAPITULO 18. AUDITORIIA DF. APLICACIONES 567
la
de
orientation
Software
que
aportan
cada
nueva
del
la
en
valor
una
2007),
{stakeholders)
de
de
Piattini,
basandose
compeiitiva
el
real
"Ingenieria
&
construction
con
enfoque
interesadas
decision
ventaja
aportacion
denominada
soluciones
de
cualquier
incluso
crear
que
(Garzis,
conjunto
usuario,
aspectos
software
Valor"(lSBV)183
propuestas
del
ellos
ingenieria
RA-MA
RA-MA
manera
para
calidad
en
y
actualidad
automatica
rapida
tener
de
la
y
que
implemente
fiable
metricas
visibilidad
sobre
procesos
es
como
del
el
CMMI
realista
un
mismo,
disponer
entorao
que
se
producto,
ya
que
no
plena
dan
de
de
auditoria
muestra
apoyarse
seguridad
Kilchenham,
una
y
como
un
solo
en
sobre
la
Eman,
K.,
et
al.
(2002).
Pfleeger,
S.
Preliminary
L.,
Pickard,
Guidelines
for
L.,
Jones,
Empirical
P.,
Hoaglin,
Research
in
D.,
El
Software
Engineering. IEEE Transactions on Software Engineering, 28(B), 721-734.
Lavazza,
L.
(2000).
Providing
Automated
Support
for
the
GQM
Measurement Process. IEEE Software, 17(2).
calidad del producto.

McCall,
software

Piattini,
M.,
&
Garzas,
J.
(2007).
acquisition
Fdbricas
de
software;
tecnologias y organizacion, Ra-Ma.
"J C.o/iocida tambien por sus siglas en ingies VBSE (Value-Based Software Engineering).
experiencias,
MA 01731.
quality,
J.
A.,
volume
manager:
Richards
III:
Inform
P.
K.,
Preliminary
tecnico
&
Walters.,
handbook
on
RADC-TR-77-369,
G.
F.
software
vol.
Ill,
(1977).
Factors
quality
Hanscom
far
in
an
AFB,
568 AUDITORJA DE TECNOLOGiAS Y SiSTEMAS DE iNFORMACION
NIST.
Infrastructure
(2002).
for
Planning
Software
Report
Testing-.
02-3.
The
National
Economic
Institute
of
Impacts
Standards
of
&
Inadequate
Technology.
Program Office Strategic Planning and Economic Analysis Group.

Piattini,
y
estimacion
M.,
del
Garcia,
software:
F.,
Garzas,
tecnicas
St
J.,
y
M.
para
(Eds.).
mejorar
productividad del software, Ra-Ma.

Simhan, R. T. E. (2006). IBM Tops list of global outsourcing Companies.
The Hindu Business Line
www.thehindubusinessline.eom/2006/05/26/stories/2006052602760400.htm.
Standish. (2001). Extreme CHAOS D. Standish Group International. En
http://www.standishgroup.eom/sample__research/PDFpages/extreme_chao.s.pdf
(ultimo acceso en abril de 2006).

1. ^Que efecto puede producir una auditoria en el grupo involucrado en la
misma?
2. i,Por que es importante contar con auditorias de aplicacion en empresas

que han exteraalizado el desarrollo de su software?
3. iQue tres tipos de aspectos se suelen distinguir en la calidad de una
aplicacion?
4. i,Que caracteristicas del modelo de McCall aplicaria a la hora de
auditar el rendimiento de una aplicacion?
5. En el caso anterior, ^qu6 alcance, en base a la norma ISO 9126, daria a
la auditoria y que metodo utilizaria?
6. C OBI T 4.1 se estructura en cuatro dominios de actividad. ^Cual de
ellos se adecua mas a la auditoria de una aplicacibn?:
- Planificar y organizar (PO, de Plan and Organise)

- Adquirir e implementar (AI, de Acquire and Implement)
- Entregar y dar soporte (DS, Deliver and Support)
- Monitorizar y evaluar (ME, Monitor and Evaluate )

7. ^Que beneficios da realizar las mediciones de manera periodica y
frecuente?
Genera,
metodos
CAPITULO 18. AUD1TORUA DE APL1CACIQNES 569
RA-MA
RA-M A
(2008).
la
Medicion
calidad
8. ^Por que es necesario definir diferentes niveles de abstraccion en

medicion?
9. (,Por que crees que benefic-ia disponer de un entorno automatizado para
apoyar las auditorias de aplicacidn?
10. i,Que objetivo final debe guiar una auditoria. de aplicacion?
Capitulo 19
DESARROLLO Y MANTENLMIENTO DE
SISTEMASINFORMATICOS
Daniel Mellado
Mario Piattini
19.1 INTRODUCCION
La
intemo
necesidad
es
aceptada
consecution
de
encargada
de
veriflcar
de
objetivos
comprobar
su
que
una
ampliamente
correcta
organization
como
marcados.
la
La
existencia
dcflnicidn
cuente
garantia
de
fiincion
de
estos
aplicacidn,
con
una
procedimiento
gestidn
eficaz
auditora
es
procedimientos
determinando
de
control
orientada
precisamente
de
control
las
deficiencias
el
departamento
la
la
de
que
existan al respecto y ios riesgos asociados a estas carencias de control.

Una
informatica
todas
un
las
SI
delimitar
de
es
fases
hasta
el
entendera
las
areas
de
desarrollo
la
que
que
ambito
que
que
tradicionalmente
o
desarrollo
se
deben
seguir
este
es
constmido,
de
estos
este
tema
incluyen
desde
aparecc
aparece
y
auditoria
del
el
ciclo
en
mantenimiento.
implantado
sobre
todo
que
de
la
entra
Esta
necesidad
en
del
de
de
abarca
disponer
mantenimiento.
desarrollo
vida
fiincion
de
Para
mantenimiento,
software
excepto
se
la
explotacion y la retirada de servicio de las aplicaciones.
El
desatTolIo
mantenimiento
de
sistema.s
es
un
proceso
ser controlado adecuadamente. Por este motivo, el auditor informatico deberia ser
costoso
que
debe
572 AUBlTORiA DE TECNOLOGIAS V SISTEMAS DE INFORMACION
RA- MA
tenido en cuenta en el diseno y construction de controles en los sistemas. Ademas

el auditor asesorara a la Direction y a los integrantes del area de desarrollo
involucrados en el nuevo SI, sobre la convenlencia de determinados controles y \a
peor adecuacion de otros. De forma general, las tareas del auditor cuando realice
una revision en esta area seran: comprender adecuadamente y evaluar la
metodologi'a seguida en el desarrollo del SI, identificar las fases de dicha
metodologfa, evaluar la adecuacion entre el proceso de desarrollo de aplicaciones y
los objetivos de la organization, revisar el cumpiimiento de estandares y norm as de
control intemo en el desarrollo de aplicaciones y determinar si se cumplen las
normas de seguridad y control de cambios.
En este eapitulo nos centraremos en el desarrollo y mantenimiento de SI,
sin que se haya tenido en cuenta el tipo de SI que se quiere obtener (sistema
operative, software empotrado, software de comunicaciones, etc.), las
caracteristicas de la organization, la metodoiogsa que use de forma estandar, la
poHtica de adquisicion de software o desarrollo a medida, y otros muchos factores,
dcsarrollados con ampiitud en ingenicri'a de los Sistemas de Information delpresente terr.ario, tendremos diversas formas o modelos de desarrollo de Software.
Sin entrar en detalles acerca de los mismos, y teniendo en cuenta ademas que el
control de cada proyecto variara fundamentalmente si se elige una solution a
desarrollar o adquirida, si podemos apuntar una serie de objetivos de control que el
auditor tendra en cuenta en las distintas etapas, que de forma general, pasa un SI.
19.2 PLANTEAMIENTO Y METODOLOGIA

Bxisten una serie de circunstancias que hacen especialmente importante el
area de desarrollo y mantenimiento de sistemas y por tanto, tambien a su auditoria,
frente a otras funciones o areas dentro del departamento de informatica:
El gasto destinado a software es cada vez superior al que se dedica a
hardware.
El software como producto es muy difTcil de vaiidar. Un mayor control
en el proceso de desarrollo y mantenimiento incrementa la calidad del
mismo y disminuye los costes de mantenimiento.
Las aplicaciones informaticas que son el producto principal obtenido al
final del desarrollo pasa a ser la herramienta de trabajo principal de las
areas informatizadas, convirtiendose en un factor esencial para la
gestion y la toma de decisiones.
RA-MA
CAPiTULO 19. DESARROLLO Y MANTEN1MIEN1U Ub SI >Ti
La etapa de mantenimiento consume la mayor parte de los recursos

empleados en un proyecto software, por tanto, esta etapa debe ser
especialmente considerada cn la auditoria informatica y siendo la
mantenibilidad el factor critico de estudio de la auditoria de
mantenimiento de! SI. Entendiendo por mantenibilidad al factor de
calidad que engloba todas aquellas caracteristicas del software
destinadas a hacer que el SI sea mas facilmente mantenible y por tanto
se consiga una mayor productividad.
El indice de proyectos de desarrollo que no alcanzan los objetivos

marcados es demasiado alto, lo cual denota la inexistencia o mal
funcionamiento de los controles en este proceso.
Para tratar la auditoria del area de desarrollo y mantenimiento es necesario
en primer lugar acotar las funciones o tareas que son responsabilidad del area.
Teniendo en cuenta que puede haber variaciones de una organization a otra, las
funciones que tradicionalmente se asignan a este area son:
Planification del area y participation, en la medida que corresponda,
en la elaboration del plan director de informatica o plan estrategico de
informatica.
Desarrollo de nuevos sistemas y mantenimiento de los existentes. Esta
es la funcion principal y la que da sentido al irea. Incluira para cada
uno de los sistemas la planificacion y viabUidad, analisis, diseno,
constructidn, impiantacion y mantenimiento.
Estudio de nuevos lenguajes, tecnicas, metodologias, estandares,
herramientas, etc. relacionadas con el desarrollo y adoption de los
mismos cuando se considere oportuno para mantener un nivel de
vigencia adecuado a la tecnologia del momenta.
Establecimiento de un plan de formacion para el personal adscrito al
area.
Establecimiento de normas y controles para todas las actividades que
se reaiizan en el area y comprobacion de su observancia,
Una vez conocidas las tareas que se realtzan en el irea de desarrollo y
mantenimiento, se abordar& la auditoria de la misma desglosandola en:
574 AUDITOR] ADETECNOLQGf AS Y SISTEMASDE INFORMACiON
RA-MA
Auditoria de la organization y gestion del area de desarrollo y

xnancenimiento.
Auditoria de la planificacion y gestion del proyecto.
Auditoria de la fase del estudio de viabilidad.
Auditoria de la fase de anaiisis.

Auditoria de la fase de diseno.
Auditoria de la fase de construction.
Auditoria de la fase de implantation.
Auditoria de la fase de mantenimiento.
La metodologia que se apiicara es la propuesta por la ISACA (Information
Systems Audit and Control Association), que esta basada en COBlT {Control
Objectives for Information and Related Technologies),
la cual proporciona un
conjunto estructurado de buenas pr&cticas y metodologias para su aplicacion, cuyo
objetivo es facilitar el gobierno de las TIC (ITGI, 2007a y 2007b). COBlT esta
basado en la evaluacion de riesgos, de matiera que partiendo de los riesgos
potenciales a los que esta sometida la actividad, en este caso el desarrollo o
mantenimiento de SI, se determinan una scric dc objetivos de control de alto nivel
que minimicen esos riesgos.
Para cada objetivo de control de alto nivel, agrupados por cada una de las
fases del ciclo de vida del software identificadas en Metrica versidn 3 (MAP,
2007), se especifican uno o mas objetivos de control de detalle o tambitii
denominadas practicas de control, que contribuyen a lograr el cumpiimiento de
dicho objetivo de control de alto nivel; para lo cual nos hemos basado tambien en
la propuesta de Rodero (2001). Asi mismo, se aportan una serie pruebas de
cumpiimiento que permitan comprobar la existencia y correcta aplicacion de dichos
controles. Sera la funcion del auditor determinar el grado de cumpiimiento y
madurez de cada uno de ellos.
El estudio global de todas las conclusiones, pruebas y evidencias obtenidas
sobre cada control permitiran al auditor obtener el nivel de satisfaction dc cada
objetivo de control, asi como cuales son los puntos fuertes y debiles del mismo.
Con esa information, y temendo en cuenta ias particularidades de la organizacion
en estudio, se detcrminaran cuales son los riesgos no cubiertos, en que medida los
RA-MA
CAPiTULO 19, DESARROLLO Y MANTENIMIENTO DES1 575
son y que consecuencias se pueden derivar de esa situation. Estas

conclusiones,
junto con las recomendaciones formuladas, seran las que se plasmen en el informe
de auditoria.
En defmitiva, los auditores como requerimiento general deben
proporcionar una garantia y recomendaciones en relation a los controles en una
organizacion:
proporcionar una garantia razonabie de que se alcanzan los objetivos

de control, .
identificar si existen debilidades significativas en estos controles,
sustanciar el riesgo que puede estar asociado a estas debilidades, y,
finalmente,
recomendar o asesorar a la Direccion sobre las acciones correctivas
que deberian ser tomadas.
19.3 AUDITORIA DE LA ORGANIZACION Y GESTION

DEL AREA DE DESARROLLO Y MANTENIMIENTO
Los proyectos de desaiTollo, a pesar de que tengan entidad propia y se
gestionen con cicrta autonomia, necesitan apoyarse en ei personal del area y los
procedimientos establecidos. La irnportancia de estos aspectos ha motivado que sea
necesario establecerse objetivos de control que faciliten la auditoria de la
organizacion y gestion del area.
Objetivo de Control OGl: procesos, organizacion y relaciones: el area
de desarrollo debe tener definidos los procesos del area, su organizacion y las
relaciones con el exterior.
OG1-C1: deben establecerse de forma ciara las funcioncs del area de
desarrollo dentro del departamento de informatica. La direccion del area debera
participar en el comite de direccion del departamento de informatica a la hora de
determinar la prioridad de los programas de inversion en TIC alineados con la
estrategia del negocio, seguimiento de los proyectos horizontales/transversales al
departamento y resolution de conflictos de recursos. Se debe comprobar que:
576 AUDITORJA DE TEONGJ-OGIAS Y SiSTEMAS DE JNFORMACJ(3 N
OKA - MA
Existe ei documento que contiene las funciones que son competencia

del area de desavrollo, que esta aprobado por la Direction de
informatica y que se respeta.
OG1-C2: debe especificarse ei organigrama con ta relacion de puestos del
area, as{ como el personal adscrito y el puesto que ocupa cada persona. Asi mismo
dicha organizacion del area deben corresponderse con las necesidades y objetivos
del negocio en cada momento. Ademas, debe exislir un procedimiento para la
actualizacion del organigrama y para la promocion de personal. Se debe comprobar
que:
Existe un procedimiento de revision que se aplica periodicarnente para
comprobar que la organizacion del area se adapta a las necesidades y
objetivos del negocio en cada momento y al dinamismo de las TIC.
Existe un organigrama con la estructura de organizacion del drea. Para
cada puesto deben describirse los roles y responsabilidades, es decir,
las funciones a desempenar y los requisitos minimos de formacion y
experiencia, as! como la dependencia jerarquica del mismo.
como existen otros miembros del personal entrenados para poder

realizar esas funciones en un momento dado.
OG1-C4: debe establecerse el marco de trabajo de los procesos del area de
desarrollo que permita la ejec-ucion y puesta en practica del plan estrategico (o plan
director) de las TIC. Este marco debera incluir la estructura de los procesos y sus
relaciones, propiedad, madurez y medidas de rendimiento, mejoras, conformidades,
objetivos de calidad y planes para conseguirlos. Se debe comprobar que:
El marco de trabajo que permite la definition y seguimiento de los

objetivos de los procesos, sus medidas, centrales y madurez han sido
definidos e impiementados, asi como formalmente documentados y
aprobados.
QGl-CS: las relaciones con el exterior del departamenlo deben produeirse
de acuerdo a un procedimiento. Deben mantenerse contaetos con proveedores para
recibir information suficicnte sobre productos que puedan ser de interes. Y debe
existir un protocolo para la contratacion de servicios externos (recursos humanos,
hardware, software o servicios). Se debe comprobar que:
Existe un manual de organizacion que regula las relaciones entre

puestos.
Existen los protocolos, estan aprobados y se hacen uso de ellos.
Existe la relacion de. personal adscrito al area, incluyendo el puesto

ocupado por cada persona. Se deben cumpiir los requisitos de los
puestos.
Se esta en contacto con un nuinero suficiente dc proveedores para

recibir informacion objetiva y completa y el tiempo invertido no
excede lo razonable.
' Estan establecidos los procedimientos de promocion de personal a

puestos superiores, teniendo siempre en cuenta la experiencia y
formacion.
Existe un proceso de supervision para asegurar que los roles y sus
responsabilidades o funciones se realizan correctamente, de manera
que permita valorar si el personal cuenta con la suflciente autoridad y
recursos para poder desarrollar sus funciones adecuadamente.
debe definirse e identificarse al personal TIC clave y
minimizarse la dependencia para la realization de funciones criticas para el area en
personas individual es. Se debe comprobar que:
OG1-C3:
Existen procedimientos forrnales que recojan esas funciones criticas y

el conocimiento mas critico esta suficientemente document-ado; asi
La selection del proveedor se hace de forma objetiva y evita

situaciones de monopolio por parte de un unico proveedor.
El protocolo inciuye un contrato-tipo que prevea los riesgos mds
frecucntes cuando se contiatan servicios externos y en todo caso
incorpora penalizaciones en caso de iucumplimiento de contrato por
parte del proveedor.
Esta definido cudndo, como y que tipo de trabajos pueden ser
externaiizados y cual es su forma de implementation, seguimiento y
reception.
El personal extemo que intervendra en los proyectos cumplira, a!
menos, los mismos requisitos que se exigen a los empleados del area.
578 AUDITORJA DE TECNOLOGIAS Y SISTEMAS DBINFORMACION
RA-MA
Una persona del area supervisa el trabajo realizado, certiflcandolo

antes del pago o confonriidad.
Debe ser compatible con los estandares establecidos en el area.
Los eonsultores y demas personal contratado de asistencia tecnica
conoce y cumpfe con la politica de seguridad del area y que dichos
requisitos de seguridad se recogen por contrato.
OG1-G6: deben establecerse los roles y responsahilidades para la gestion
del aseguramiento de la calidad, gestion de riesgos, seguridad y conformidad, Se
debe comprobar que:
El grupo de aseguramiento de la calidad cuenta con los sistemas de
aseguramiento de la calidad apropiados, as! como los controles y
asesoramiento de expertos.
Las responsabilidades y roles asi como los procesos para la gestion de
riesgos y seguridad han sido correctamente establecidas, formalizadas
y documentadas y satisfacen los requisitos del area. Y son ejccutados
por persona! con la suficiente formacion y experiencia en la materia.
Objetivo de Control OG2: gestidn de Recursos Humanos TIC. El area
de desarrollo debe contar con unos recursos humanos adecuados para gestionar el
desarrotlo y mantenimiento de SI. Esto se consigue mediante practicas definidas y
acordadas para la contratacion, entrenarniento o formacion, evaiuacion del
rendimiento, promocion y recepcidn/abandono de personas. Este proceso es critico
debido a que las personas son uno de los activos mas importantes para toda
organization, de manera que una buena gestion del area de desarrollo dependent
entre otros factores de la motivation, formacion y aptitud de su personal adscrito.
OG2-C1: deben existir procedimientos de contratacion objetivos. Se debe
comprobar que:
Existe un plan de gestion de recursos humanos TIC que recoge los
roles y perfiles necesarios en el area para cumplir sus objetivos y que
es revisado al menos anualmente.
RA-MA
CAPiTULO 19. DESARROLLO Y MANTENIMiENTO DESI 579
Las personas seleccionadas cumplen los requisitos del puesto al que

acceden.
OG2-C2: debe existir un plan de formacion que este en consonancia con
los objetivos tecnologicos del area y alineados con los objetivos del negocio. Se
debe comprobar que:
Se tiene aprobado un plan de formacion a corto, medio y largo plazo
que sea coherente con ia politica tecnologica.
Incluye toda la information relevante para cada actividad fonnativa:
fechas, lugar, material, medios, etc.
Las actividades formativas se evaluan por parte de los asistentes y esta
evaiuacion se tiene en cuenta a la hora de redefmir el plan de
formacion.
Contempla la formacion de todos los empieados y tiene en cuenta el
puesto que ocupa.
El plan de trabajo del area tiene en cuenta los tiempos de formacion.

OG2-C3: debe existir un protocolo de recepcion/abandono o cambio de
trabajo de las personas que se incorporan o dejan el area o que cambian de fiincion.
Se debe comprobar que:
El protocolo existe y se respeta para cada incorporacion/abandono.
Para la incorporation, incluye al menos los estandares definidos,
manual de organizacion del area, definicion de puestos, etc.
En los abandonos de personal se garantiza la proteccion del area y la
transferencia de conocimiento que asegure la continuidad de las
funciones.
OG2-C4: debe existir una biblioteca y una hemeroteca accesibles por el
persona! del area asi como acceso a internet. Se debe comprobar que*
Esian disponibles un numero suficiente de libros, publicaciones
periodicas, monogramas, etc. de reconocido prestigio, ya sea en
formato electronico o papel, y el personal tiene acceso. a elios.
Las ofertas de puestos del area se difunden de forma suficiente fuera de

la organizacion y las seiecciones se hacen de forma objetiva.
580 AUDtTORiA PE TECNOt.OGIAS Y SISTEMAS D INFORM ACiON
RA-MA
OG2-C5; e! personal debe estar motivado en la realization de su trabajo.

Este aspecto es diflcil de vaiorar y no es puramente tecnico. Se debe comprobar
que:
Existe algun mecanismo que permita a los empleados

sugerencias sobre mejoras en la organization de! area.
hacer
No existe una gran rotation de personal y hay un buen ambiente de
OG2-C6: debe existir un procedimiento de evaluation periodico de los

recursos humanos TIC propios y contratados del area. Se debe comprobar que:
El persona! cuenla con la cualificaciun descrita en ios roles
identificados en el area, en base a su formation y experiencia.
Se minimiza la dependencia de personas individuales clave para ciertas
funciones mediante la captura del conocimiento (documentation),
compartiendo dicho conocimiento entre la plantilia y con
planificaciones exitosas.
El rendimicnto del personal en funcibn de sus objetivos individuales
. derivados de las mctas del drea es el adecuado y que no cae por debajo
de unos minimus razonables, as! como que el absentismo laborai es
similar a! del resto de la organization.
RA-MA
CAPiTUI.O 19. DESARROLLO Y MANTFNIMIENTO DE SI 581
Se revisa y actualiza con periodieidad en fimcion de las nuevas

situaciones Se difunde a todos los empleados para que se sientan participes del
mismo, a! resto del departamento y los departamentos a los que les
atahe.
OG3-C2: la realizacion de nucvos proyectos debe basarse en el plan
director TIC y en el plan de sistemas en cuanto a objetivos, rnarco general y
horizonte temporal Se debe comprobar que:
Las fechas de realizacion coinciden con las del plan estrategico.

La documentation relativa a cada proyecto que hay en el plan
estrategico se pone a disposition del director de proyecto una vez
comenzado el mismo. Esta informacion debe contener los objetivos,
los requisites generales y un plan inicial.
Objetivo de Control OG4: direction de la Polftica Tecnologica: el area
de desarrollo debe participar en la direction de la politica tecnologica del
departamento de informatica.
Existe una remuneration o reconocimicnto en base a la consecucidn de

los objetivos de rendimiento logrados.
" OG4-C1: deben analizarse las nuevas regulaciones/regjamentaciones en'

materia de TIC asf como las tecnologias existentes y emergentes y determinar que
politica tecnologica es la apropiada para la consecucidn de los objetivos del area, y
para el desarrollo de nuevos sistemas o mantcnimicnto de los existentes
compatibles con )a arquitectura de los sistemas actuaies o realizar un estudio de las
estrategias de migration en su caso. Se debe comprobar que:
Objetivo de Control OG3: plan estratdgico de Tecnologias de la

Information del area: el area de desarrollo debe participar en la definition del
Existe un proceso de analisis de las regulaciones y tecnologias y el

tiempo invertido.no excede to razonable.
plan estrategico o plan director de Tecnologias de la Informacion.

OG3-C1: el area debe tener y difundir su propio plan a corto, medio y
largo plazo, que sera coherente con el plan director de TIC del departamento de
informalica y con el plan de sistemas, si este existe. Se debe comprobar que:
El plan existe, esta actualizado, es claro y realista.
Los estandares tecnologicos corporativos encajan con las arquitecturas

de los SI existentes en mantenimiento.
Periodicamente se comprueba e! nivel tecnologico, para ver si es
coherente con ei plan director TIC y con el plan de sistemas y si esti en
linea con el de otras organizations similares.
Objetivo de Control OGS: gestidn de las lnversiones TIC: el area de
desarrollo debe llevar su propio control presupueslario en lo relative a la gestion de
las inversiones en TIC. Se debera comprobar que;
Los recursos actuaies, mas los que se estd planificando que se

incorporen al area, son suficientes para su cumplimiento.
582 AUDlTORiA DE TECNGLOGiAS Y StSTEMAS DEINFORMACION
RA-MA
RA - MA
CAPiTULO 19 DESARROLLO Y MANTENIMIENTO DE SI 583
Se hace un presupuesto por ejercicio y se cumple y que esta en

consonancia con IDS objetivos a cumplir.
OG6-C3: debe tenerse implantada una metodologla de desarrollo de ST

soportada por herramientas CASE. Se debe comprobar que:
Exists un proceso de priorizacion en la ccnfeccion del presupuesto

para la asignacion de inversiones y recursos TIC a adquisiciones,
proyectos de desarrollo y mantcnimiento, que maximice el ROI de
dlchas inversiones TIC.
La mctodologia cubre todas las fases del desarrollo y mantenimiento y

es adaptable a distintos tipos de proyecto.
Existe un proceso de gestion de costes comparando los costes actuales

en desarrollo y mantcnimiento y adquisiciones con lo presupuestado.
Dicho proceso debera reportar las desviaciones existentes de manera
que debera haber una estimation del impacto de estas sobre los
programas a fin de facilitar las acciones correctivas a tomar.
Objetivo de Control OC6: gestion de la Caiidad: el area de desarrollo
debe disponer de unos procesos de desarrollo regidos por los estandares y

principios de ingenieria del software ampliamente aceptados.
OG6-C1: debe existir un registro de problemas que se producen en los
proyectos del area, incluyendo los fracasos de proyectos completes. Sc debe
Existe un catalogo de problemas, incluyendo para cada uno de ellos la

solution o soluciones encontradas, proyecto en el que sucedio, persona
que lo resolvio, etc.
El catalogo es accesible para todos los miembros del area, esta
actualizado y tiene uno 0 varios indices que faciliten la busqueda.
Se registran y controlan todos los proyectos fracasados (aquellos que
comienzan y no llegan a su fin), asi como los recursos invertidos en los
mismos.
OG6-C2: debe mantenerse y comunicarse periodicamente al area las
modificaciones del plan global de caiidad a fin de promover la mejora continua. Se
debe comprobar que:
El plan existe y se actualiza periodicamente.
Existen y se ejecutan actividades de mejora continua segun los
estandares, practicas, procedimientos y politicas de caiidad del
departamento adoptadas por el area de desarrollo.
La metodologia y las tecmcas asociadas a la misma estan adaptadas al

entomo tecnologico y de organization del area de desarrollo.
Se ha adquirido, homologado e implantado segun las norm as del area

una herramlenta/s CASE que se adapta a la metodologla elegida y que
cumple con los requisitos minimos exigibles a una herramienta de este
tipo.
Se ha formado al personal sobre esta metodologla y su adaptation, asi
como sobre las tecnicas asociadas a la herramienta CASE.
Existe un procedimiento que permita determinar en que proyectos el
uso de la herramienta CASE es ventajoso.
Esta claramente especificado de que forma el uso de la herramienta
altera las fases de desarrollo tradicionales.
La herramienta CASE es capaz de mantener el diccionario de datos y
cumplir con la sintaxis e integridad de los datos.
La herramienta CASE cumple con los requisitos de confidencialidad
necesarios sobre la documentation asociada al proyecto.
OG6-C3: debe existir un mecanismo de creacion y actualizacion de
practicas y estandares de caiidad asi como de practicas, estandares de desarrollo y
mantenimiento. Se debe comprobar que:
El mecanismo para la creacion y actualizacion de practicas y

estandares esta documentado y es conocido en el Srea.
Estan definidas las practicas de analisis y diseno, e incluye las tdcnicas
y herramientas a usar, etc. Asi como tambien hay una guia o practicas
de programaciOn para cada uno de los lenguajes homologados. Y para
la realizacion de prucbas (validacidn dc los requisitos, planes de
pruebas, pruebas unitarias, de regresion y de integracion).
584 AUDI JOR1A DE TECN0L001AS Y SISTRMAS DE INFORMACtQN
<
RA - MA
C RA-MA
CAPiTUI.O 19. DESARROLLO V MANTENIMIENTO DE S_585
de
!QS
OG6-C6: debe existir un rnodelo corporativo de la arqurtectura de

informacion que se actualice regularmentc y defina los sistcmas apropiados que
optimicen el uso de la informacion. Se debe comprobar que;
Hay un estandar para ei diseno del esquema y diccionario de datos,

para la interfaz de usuario, interoperabilidad y escalabilidad del SI;
eficiencia del rendimiento del SI.
Existc un diccionario de datos corporativo con las reglas de sintaxis de

la organizacion, e! esquema de clasificacion de los datos y sus niveies
de seguridad correspondientes.
Hay un estandar general para toda la documentacidn generada,

incluyendo documentation tecnica (analisis, diseno, documentacidn de
los programas...), manuales de usuario, etc.
Se garantiza la consistencia y seguridad de la informacidn de los SI

con los recursos proporcionales y dicha informacion se alinea con la
estrategia y objetivos de la organizaci6n.
Los estandares y practicas son conocidos por las personas que deben
usarlos y se respetan. Cuando se produce una modification, esta se
difunde dentro del area.
OG6-C7: los lenguajes, compiladores, herrainientas CASE, software de

pruebas, software de control de versiones, etc. usados en el area deberi ser
previamente homologados. Se debe comprobar que:
OG6-C4: debe existir un procedimiento de monitorizacidn y medicidn del

cumpiimiento de los estandares y practicas de calidad asi como de los de desarrollo
y mantenimiento. Se debe comprobar que:
Existe un mecanismo para la adquisicion y homologacion de cualquier

nuevo producto software usado en el desarrollo o mantenimiento. Se
deben evaluar al menos los siguientes parametros: productividad,
portabilidad a otros entomos, transicion desde los productos actuates,
solvencia del proveedor, riesgo de cambio, cumpiimiento de los
estandares del area, compatibilidad con el entorno tecnoldgico, coste,
etc.
Bxisten conyenios sobre !os aspectos mas importanles

programacion: modularidad, nomenclature, formato de
comentarios, documentacidn asociada, estilo de programacion, etc.
Se realizan informes ejecutivos periodicamente sobre la calidad de los

SI eii e! area.
Estan definidas mdtricas de calidad y dstas estan alineadas con los
objetivos de calidad del area y ayudan en la consecucion de los
objetivos de negocio.
Se realizan inspecciones en los hitos de los proyectos para verificar el
cumpiimiento de los estihdares y practicas.
OG6-C5; debe practicarse la reutilizacion del software. Se debe comprobar
que:
Existe un repositorio con todos los produccos software susceptibles de

ser reutilizados: librerias de funtiones, clases de objetos, componentes
software,
documentos
(catalogo
de
requisitos
comunes,
arquitecturas...), etc.
Se esta en contacto con un numero suficicnte de proveedores para

recibir informacion objetiva y completa y el tiempo invertido no
excede lo razonable. Y la seleccion del proveedor se hace de forma
objetiva y evita situaciones de monopolio por parte de un unico
proveedor.
Cuando se homologa un nuevo producto de desarrollo se forma al
personal del area que lo vaya a manejar.
Se registra la informacion mas importante acerca de la configuracion

de los productos recien adquiridos.
19.4 AUDITORIA DE PROYECTOS DE DESARROLLO Y

MANTENIMIENTO
La auditoria de cada proyecto de desarrollo o mantenimiento tendra un
plan distinto dependiendo de los riesgos, complejidad del misino y recursos
El repositorio o catalogo es conocido y accesible por todos los
miembros del area, esta actualizado y tiene uno o varios indices que
faciliten la busqueda.
586 AUDITORiA DE TECNOLOGIAS Y SISTEMAS DE fNFORMAClON
RA-MA
RA-MA
disponibles para realizar la auditoria. Esto obliga a que sean la pericia y

experiencia del auditor las que determiner! las actividades del proyecto que se
controlaran con mayor intensidad en funcion de los pararnetros arsteriores.
En el documento de aprobacion estan deftnidos de forma clara y

precisa los objetivos del mismo y las restricciones de todo tipo que
deben tenerse en cuenta (temporales, recursos tecnicos y humanos,
presupuesto, etc.) y su alineacion con el plan de sistemas.
En este apartado se definen objetivos y tecnicas de control generales

aplicables a cualquier proyecto. El auditor decidira los objetivos mas importantes
en funcion de las caracteristicas del proyecto y de la fase a auditar.
Como se puede observar los controles de auditoria han sido agrupados por
cada una de las fases del ciclo de vida del software identificadas como procesos en
Metrica version 3, as! mismo se especifican uno o mas objetivos de control de
detalle o tambien denominadas practicas de control, que contribuyen a lograr el
cumplimiento ce dicho objetivo de control de auditoria ce alto nivel.
Se han identificado las unidades de la organizacion a las que afecta.

"$
Los objetivos de control que se consideran en este apartado son los

siguientes.
Se le ha comunicado al director su nombramiento junto con toda la

informacion relevante del proyecto.
P1-C3: el proyecto debe ser catalogado y, en funcion de sus caracteristicas,
se debe determinar el modelo de ciclo de vida que seguira. Se debe comprobar que:
Sc ha catalogado y dimensionado el proyecto segiin las normas
establecidas.
Se han evaluado los riesgos asociados al proyecto, especialmente
cuando se van a usar tecnologias no usadas hasta el momento.
Se ha elegido el ciclo de vida mas adccuado al tipo de proyecto de que
se trata.
P
&
ff
Pl-Cl: debe existir una orden de aprobacion del proyecto que defina
ciaramente los objetivos, restricciones y las unidades afectadas. Se debe comprobar
que:
Existe una orden de aprobacion del proyecto reffendada por un organo

competente. El estudio de vvabilidad debe habcr seguido el cauce
establecido.
Se ha hecho uso de la informacidn historica que se dispone tanto para

dimensionar el proyecto y sus riesgos como para seleccionar el ciclo de
vida.
'y
B
Objetivo de Control PI: el proyecto de desarrollo debe estar aprobado,

definido y pianificado formalmente.
P1-C2: debe designarse un responsable o director del proyecto. Se debe

comprobar que:
La designacion se ha llevado a cabo segun el procedimiento
establecido.
Aunque los objetivos de control se han catalogado en funcion de la fase del

proyecto a la que se aplican, en el caso de 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. Las tdcnicas a utilizar y los elcmentos a inspeccionar,
normalmente los productos y documentos generados en cada fase, seran los
mismos en ambos casos. La unica diferencia es que en el primer caso las
conclusiones que vaya aportando el auditor pueden afectar al desarrollo del
proyecto, aunque nunca participant en la toma de decisiones. Respecto a la
auditoria de un proyecto de mantenimiento, se detalla mas adelante y se
corresponde con e! apartado que describe la auditoria de dicha fase o proceso-
19.4.1 Auditoria de la gestion y planificacion del proyecto
CAPlTULO 19. DESARROLLO V MANTENIMIENTO DE S! 587
P1-C4: una vez determinado el ciclo de vida a seguir, se debe elegir el

equi'po tecnico que rcalizara e! proyecto y se determinara el plan del proyecto. Se
debe comprobar que:
La designacion del equipo de desarrollo se ha llevado a cabo segun el
procedimiento establecido.
Los participates que pertenezcan a otras areas (sistemas,

comunicaciones, ofimatiea, etc.) se han solicitado. segun el protocolo
existente.
588 AUDITORIA PE TECN'OLOGiAS Y SISTEMAS DE INFQRMACiON
RA - MA
Si participa persona! externo, los perfiles profesionales son adccuados

a las funciones que van a realizar. El contrato cumple el protocolo de
contrataci6n.
Se ha comunicado a todos los miembros del equipo de desarrollo los
objetivos del proyecto, la responsabilidad que tendran en el mismo, las
fechas en las participar&n y la dedicacion (completa/parciai).
El plan de proyecto realizado es realists y utifiza la informacidn
historica de la que se disponga para realizar estimaciones.
Objetivo de Control P2: el proyecto se debe gestionar de forma que sc
consigan los mejores resultados posibles teniendo en cuenta las restricciones de
tiempo y recursos. Los criterios usados seran coherentes con los objetivos de las
unidades afectadas.
P2-C1: los responsabies de las unidades o areas afectadas por el proyecto
deben participar en la gestidn de! proyecto. Se debe comprobar que:
Se ha constituido formalmente el eomite de direction del proyecto y en
el estan incluidos los responsabies de todas las unidades afectadas y la
oficina de proyectos.
El comite tiene una periodicidad de reunion minima, y en cualquier
caso siempre que lo exija e! desarrollo del proyecto, debe tener
competencia para asignacion de recursos, la revision de la marcha del
proyecto y para modificar e! plan del proyecto en funcion de las
revisiones.
Las reuniones se hacen con un orden del dia previo y las decisiones
tomadas quedan documentadas en las actas de dicho eomite.
El numero de reuniones y la duration de las mismas no superan un
limite razonable comparado con la envergadura del proyecto.
P2-C2: se debe establecer un mecanismo para la resolution de los
problemas que puedan plantearse a lo largo de! proyecto. Se debe comprobar que:
Existen hojas de registro de problemas y que hay aiguna persona

del
proyecto encargada de su reception, asi como un procedimiento
conocido de tramitacion.
C RA-MA
CAPITULO 19. DESARROLLO V MANTENlMtENTO P SI 589
Hay un nretodo para catalogar y dar prioridad a los problemas, asi

como para trasladarlos a la persona que dc los debe resolver,
informando si es necesario al director del proyecto y al comite de
direccion.
Se controla la solution del problema y se deja constancia de la misma.
P2-C3: debe existir un control de cambios a lo largo del proyecto. Se debe
comprobar que:
Existe un mecanismo para registrar los cambios que pudieran

producirse, asi como para evaluar el impacto de los mismos.
La documentacion afectada se actualiza de forma adecuada y se lleva
un control de versiones de cada producto, consignando la ultima fecha
de actualizacion.
Se remite la nueva version de los documentos actualizados a los
participantes en el proyecto.
P2-C4: cuando sea necesario reajustar el plan del proyecto, normalmente
en un hito a! finalizar una fase, debe hacerse de forma adecuada. Se debe
comprobar que: ' '
Se respetan los limites temporales y presupuestarios marcados al inicio
del proyecto. Si no es asi debe ser aprobado por el comite de direccion.
Se han tenido en cuenta los riesgos del reajuste.
Se ha hecho uso de la informacion historica que se dispone en el area
sobre estimaciones.
Se notifica el cambio a todas las personas que de una u otra forma
participen en el proyecto y se vean afectados.
Si existe un plan director TIC o plan de sistemas, se actualizara en
consecuencia.
P2-C5: debe hacerse un seguimiento de los tiempos empleados tanto por
tarea como a lo largo del proyecto. Se debe comprobar que:
590AUDITOR1A DETECNOLOGlAS YSISTEMAS DE INFORMACI6N
RA-MA
Existe un procedimiento que permite registrar ios tiempos que cada

participate del proyecto dedica al mismo y qud tarea realiza en ese
tiempo.
Las productividades que se obtienen para distintos empleados en las
mismas tareas son similares y estan en consonancia con la informacion
historica.
Existe un procedimiento para analizar las desviaciones y proponer
acciones correctivas.
P2-C6: 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
metodologia usada. Se debe comprobar que:
Antes de ccmicnzar una nueva etapa se ha documentado la etapa previa
y se ha revisado y aceptado, especialmente en las fases de an&iisis y
discfio.
La
documentacLon
establecidos en el area.
cumple
los
estandares
procedimientos
Se respeta el plan establecido y en caso contrario se toman las medidas

oportunas o se precede a la aprobacion de una modificacidn del plan.
Se respeta el uso de recursos previamente establecido.
P2-C7: cuando termina el proyecto se debe cerrar toda la documentacion
del mismo, liberar los recursos empleados y hacer balance. Se debe comprobar que:
La documentacion del proyecto es completa
perfectamente para accesos posteriores.
y esta catalogada
Los recursos, tanto personales como materiales, se ponen a disposicion

del area o departamento del que provienen.
RA-MA
CAPiTULO 19. DESARROt.LO Y MANTENIMIENTO PES) S9I
La nueva aplicacion se incorpora al catalogo de aplicaciones existentes

con toda la informacion relevante dc la misma.
19.4.2 AUMTORIA DE LA FASE DE ESTUDIO DE

VIABILIDAD
El objetivo del estudio de viabilidad del sistema es el anaiisis de un
conjunto concreto de necesidades para proponer una solucion a corto plazo, que
tenga en cuenta restricciones economicas, tecnicas, legales y operativas. Por lo
tanto, el auditor debera controlar que:
Objetivo de Control VI: antes de la definition del proyecto deben
estudiarse los requisitos que se han de satisfacer y estudiarse, si precede, la
situation actual, identificando seguidamente las altemativas de solucion y
seleccionando aquella que satisfaga mas eficaz y eficientemente los requisitos
identificados, lo cual puede derivar en la definicion de uno o varios proyectos que
afecten a uno o varios SI y con soluciones basadas en desanrollo a medida,
adquisicidn de productos software del mercado o soluciones mixtas.
Vl-Cl: debe haberse establecido el alcancc de las iniciativas requcridas

para satisfacer las necesidades planteadas por el cliente o usuario. Se debe
comprobar que:
Existe un dccumento que recoge la descripcion general de la necesidad
planteada por ei usuario y los objetivos generales (y en el caso de
existir plan de sistemas se tomara como referencia los requisitos y
arquitectura de informacion del mismo) as! como las posibles
restricciones tdcnicas, legales, operativas y economicas.
Se han determinado formalmente el grupo de usuarios que participara
en el proyecto, identificandose sus perfiles y dejando claras sus tareas
y responsabilidades.
V1-C2; debe estudiarse la situacibn actual y determinarse los sistemas
afectados Se debe comprobar que:
Se han realizado los modelos del sistema.
El comite de direction y el director del proyecto hacen balance del

proyecto, estudiando los posibles problemas y sus causas, los cambios
del plan, etc. Toda esta informacidn se registra en los archivos
historicos sobre estimaciones y problemas.
Se ha reaiizado un diagndstico de la situacion actual.
592 AUDlTORjA DE TECNOLOGIAS Y SiSTEMAS DE INFORMACION
RA- MA
V1-C3: los usuarios y responsables de las unidades a las que afecta el

nuevo sistema estableceran de forma clara los requisitos de! mismo. Se debe
comprobar que:
Se ha realizado un plan detallado de entrevistas con el grupo de
usuarios y con los responsables de las unidades afectadas que permita
conocer como valoran el sistema actual y lo que esperan del nuevo
sistema.
Se han identificado las directrices tecnicas y de gestion, a partir del
plan de sistemas en el caso de que el proyecto pertenezca ai ambito de
este. Estas directrices seran: politicas tecnicas (de gestidn de proyectos,
de desarrollo, de arquitectura), politica de seguridad, directrices de
planificaciori, gestion de la calidad y gestion de cambios.
Existe un catalogo de requisitos que estan justificados y cada requisito
tiene una prioridad y esta clasificado en funcional y no funcional.
EI catalogo de requisitos ha sido revisado y aprobado por el grupo de
usuario y los responsables as: como por el comite de direccion.
V1-C4: se deben estudiar y valorar las distintas altemativas de soluciOn
que satisfacen los requisitos identificados anteriormente y analizar sus ventajas e
inconvenientes. Se debe comprobar que:
Existe un documento en el que se describen las distintas altemativas y
cada alternativa esta descrita desde un punto de vista logico (al menos
modelo logico de procesos) y es coherente con los requisitos
establecidos.
Si existe en el mercado algun producto o productos que cumplan con
unas minimas garantias los requisitos especificados, una de las
altemativas debe ser su adquisicion.
Si no Io impiden las caracteristicas del proyecto una de las altemativas
debe ser el desarrollo del sistema por parte de una empresa externa.
RA- MA
CAPITULO i9. DESARROLLO Y MANTENiMIENTO DE SI 593
Vl-CS: debe seieccionarse la solution que satisfaga mas eficaz y

eficientemente los requisitos identificados. Sc debe comprobar que:
El comite de direccion ha seleceionado una alternativa como la mas
ventajosa y es realmente la mejor para la organizacion y se ha recogido
formalmente su decision y argumentation asociada.
Se ha actualizado el plan del proyecto segun los criterios ya
comentados.
19.4.3 Auditoria de la fase de analisis

El objetivo de esta fase es la obtencion de una especificacion detallada del
sistema de informacion que satisfaga las neeesidades de informacion de los
usuarios y sirva de base para el posterior disefio del sistema y de una forma
independiente del entomo tecnico.
Para lo cual se consideran los siguientes objetivos de cmitrol:
Objetivo de Control Al.* se debe eiaborar una especificacion detallada
que permita describir con precision el sistema de informacidn.
Al-Cl: debe realizarse un plan detallado de sesiones de trabajo con el
grupo de usuarios del proyecto y los responsables de las unidades afectadas para
recopilar la informacion necesaria. Se debe comprobar que:
Las tecnicas que se utilizan para la recopilacion de esta informacion es

ia adecuada en funcion de las caracteristicas del proyecto y los tipos de
usuario a entrevistar. Entre ellas podemos citar las reunvones,
entrevistas. Joint Application Design (JAD), etc.
Se remite e! guion a los entrevistados con tiempo suficiente para que
estos puedan preparar la entre vista y la documentaci6n que deseen
aportar a la misma. Y el gui6n inciuye todas las cuestiones necesarias
para obtener la informacion sobre las funciones deseadas y probiemas
que se quieren resolver.
A1-C2: a partir de la informacion obtenida de las entrevistas se debe
realizar la descripcidn inicial del SI y obtener el catalogo de requisitos detallado
del mismo. Se debe comprobar que:
Se ha evaluado las ventajas e inconvenientes de cada alternativa de

forma objetiva (anIisis coste/beneficio por ejemplo), as! como los
riesgos asociados. Teniendose en cuenta el impacto de cada alternativa
en la organizacion, desde el punto de vista tecnico, organizativo y de
operation asi como los beneficios esperados y costes asociados.
Existe un catalogo de requisitos, que estan justificados y detallados.
594 AUDITORiA DE TECNOLOGI AS Y SiSTEMAS PE INFORMACION
RA-MA
CAPiTUI.O 19. DESARROLI-Q V MANTCNIMIENTO DE
RA-MA
SI
595
Cada requisito tierte una prioridad y estan clasificados en funcionales y

no funcionales.
La interfaz de usuario se ha aprobado por el grupo de usuarios y por el

comite de direccion.
La especificacidn del sistema incluye los requisitos no funcionales: de

seguridad, rendimiento, disponibilidad, implantacibn, etc.
AI-C6: debe especificarse el plan de pruebas que el nuevo sistema debe

superar para ser aceptado. Se debe comprobar que:
A1-C3: se estructura el sistema de informacion en subsistemas de analisis,

para facilitar la especificacion de los distintos modelos y la traza de requisitos. Se
debe comprobar que:
Se han definido los requisitos del entomo de pruebas y el alcance de

las pruebas.
La descomposiciort de los subsistemas esta orientada a los procesos de

negocio.
Se han asignado los requisitos a cada uno de los subsistemas
identificados, y consecuentemente actualizado el catalogo de
requisitos.
A1-C4: se debe realize el modelo del sistema que sirva de base para el
diseno. En el caso de analisis estructurado, mediante la elaboracidn y descripcion
detallada del modelo de datos y de procesos, y en el caso de un analisis orientado a
objetos, a traves del modelo de clases y el de interaction de objetos, mediante el
andlisis de los cases de uso. Se debe comprobar que:
Los modelos son correctos tecnicamente y que se han realizado con la
tecnica adecuada.
Existe un diccionario de datos o repositorio y es correct y se gestiona
. de forma de automatizada, respet&ndose en su gestion todos los
procedimientos de gestion de cambios.
A1-C5: se deben especificar todas las interfaces entre el sistema y el
usuario, tales como formatos de pantalias, di&logos, formatos de informes y
formularios de entrada. Se debe comprobar que:
Se ha elaborado el plan de pruebas de aceptacion del sistema, que fate

es coherente con el catalogo de requisitos y con la especificacion
foncional del sistema y que es aceptado por el grupo de usuarios y por
el comite de direccion.
Gbjetivo de Control A2: se debe garantizar la calidad de los distintos
modelos generados en el proceso de analisis del SI, y asegurar que los usuarios y
los analistas tienen el mismo concepto del sistema.
A2-C1: se debe de verificar la calidad tecnica de cada modelo y asegurar la
coherencia entre los distintos modelos. Se debe comprobar;
La calidad formal de los distintos modelos, comprobando si son
conforme a la tecnica seguida para la elaboracion de cada producto y a
las normas determinadas en el catalogo de normas.
La falta de ambigiiedades o duplicacion de informacion.
Se ha realizado una validacion de los distintos modelos con los
requisitos especificados para el sistema de informacion, tanto a traves
de! catalogo de requisitos, mediante la traza de requisitos, como a
traves de la validacion directa del usuario.
A2-C2: debe realizarse una validacion formal de la especificacion de
requisitos y de los modelos del analisis del sistema. Se debe comprobar que:
Los usuarios confirman que los requisites especificados en el cat&logo
de requisito, asi como los casos de uso, son validos, consistentes y
completes.
Se han descrito con suficiente detalle las interfaces: pantalias a traves

de las cuales el usuario navegara por la aplicacion, incluyendo todos
los campos significativos, menus, botones, etc.; asi como informes y
formularios asociados si existen. Si hay normas de diseflo o estilo de
pantalias, informes, formularios, etc.. en el area, se verificara que se
respetan.
Una vez que el catalogo de requisitos ha sido especificado

formalmente el comite de direccion y de usuarios lo aprueba,
596 AUDITORIA DE TECN'OLOGIAS Y SISTEMAS DE INEGRMAULHS
S RA-MA
constituyendo a partir de este mornento el "contrato" entre estos y e!

equipo que desarrolla el proyecto.
.RA-MA
CAPJTULO 19. PESARROLLO-Y MANTENiMiRNTO PES! 597
requisites establecidos de volumenes, tiempos de respuesta, seguridad,

etc.
Cualquier petition de cambio en los requisite que pueda surgir

posteriormente debera ser evaluada y aprobada.
D1-C2: se debe realizar un diseno detallado de los subsistemas de soporte

y del sistema de informacion especifico. Se debe comprobar que:
La actualization del plan de proyecto seguira los criterios ya

comentados, deiall&ndose en este punto en mayor medida la entrega y
transition al nuevo sistema.
Se ban identificado los mecanismos genericos de diseno, asi como

las librerias y clases reutilizables.
19.4.4 Auditona de la fase de diseno

El objetivo de la fase de diseno del SI es la definition de la arquitectura del
sistema y del entomo tecnologico que Ie va a dar soporte, junto con la
especificacion detallada de los componentes del sistema de information.
Objetivo de Control Dl: se debe definir una arquitectura del sistema que
sea coherenle con la especificacibn funcional que se tenga y con el entomo
tecnologico.
D1-C1: el particionamiento fisico del sistema de informacibn, asi como su.
organization en subsistemas de diseno, la especificacion del entomo tecnologico, y
sus requisitos de operation, administration, seguridad y control de acceso deben
estar definidos de forma clara y ser conformes a los estandares y norm as del
departamento de informatica. Se debe comprobar que:
Estan perfectamente diferenciados y definidos los subsistemas

especlficos del sistema de information (en adelante, subsistemas
especificos) y los subsistemas de soporte.
Estan definidos todos los elementos que configuran el entomo

tecnologico (servidcres, PC, perifericos, conexiones de red, sistemas
gestores de bases de datos, middleware, herramientas CASE, etc.)
junto con su planificacidn de capacidades (capacity planning) y sus
requisitos de operation, administracion, seguridad y control de acceso.
Exists un cat&logo de excepciones, de requisites, normas y estandares
originados como consecuencia de la adoption de una determinada
solution de arquitectura o infraestructura.
Los elementos seleccionados estn dentro de los estandares del

departamento de informatica y son capaees de responder a los
El tamano de los modules o clases es adecuado y el factor de

acoplamiento entre ellos es minimo y la cohesion interna es
maxima.
Los modulos o clases, se disenan para poder ser reutilizados cn el
futuro por otros SI.
BI-C3; se debe disenar la estructura de datos adaptando
especificaciones del sistema al entomo tecnologico. Se debe comprobar que:
las
El modelo de datos tiene en cuenta el entomo tecnologico y los

requisitos de rendimiento para los volumenes y frecuencias de acceso
estimados, migration de datos.
Si incluye algun incumplimiento de las normas, esta justificado.
D1-C4: debe realizarse una verification y aceptacidn formal de la
arquitectura del sistema. Se debe comprobar:
La consistencia entre los distintos modelos y conseguir la aceptacidn
del diseno por parte de los responsables de las areas de Explotacidn y
Sistemas.
Objetivo de Control 02: se deben generar todas las especificaciones
necesarias para la construction del sistema de informacion:
D2-CI: se deben generar unas especificaciones de construccion. Se debe
comprobar que:
Se ban fijado formalmente las directrices para la construccion de los
componentes del sistema, asi como de las estructuras de datos.
598 AUDITORIA DE TECNQLOGIAS Y S1STEMAS DEjNFORMAClON
RA-MA
D2-C2: se debe especificar el procedimiento de migracion y carga inicial

de datos asi como los requisites de operacion. Se debe comprobar que:
Se definen los procedimientos de migracion y sus componentes
asociados, con las especificaciones de construccion oportunas.
Se definen los requisitos relativos a la propia implantacion del sistema
en el entomo de operacibn y aquellos relacionados con la
documentation que el usuario requiere para operar con el nuevo
sistema.
D2-C3: debe realizarse la especificacion tecnica del plan
de
pruebas.
Se
debe comprobar que:
Existe el plan de pruebas y contempla todos los recursos necesarios

para llevarlas a efecto.
Es adecuado para validar cada uno de los componentes del sistema,
incluyendo pruebas de caja blanca. Tendran en cuenta las posibles
condiciones logicas de ejecucion, ademas de posibles fallos del
hardware o software de base y ataques de seguridad.
Permite validar la integracidn de los distintos componentes y el sistema
enconjunto.
D2-C4: se debe realizar una aprobacion formal del disefio del sistema por
el comite de direccion. Se debe comprobar que:
Se realiza la presentation del disefio al comite de direccion y se
registra la aprobacion del mismo.
Se actuaiiza el plan de proyecto scgun los criterios ya comentados.
19.4.5 Auditoria de la fase de construccion

En esta fase se construiran los productos software que satisfagan las
necesidades identificadas y cumplan con los requisitos especificados. Asi mismo,
se pondran en marcha todos los procedimientos necesarios para que los usuarios
puedan trabajar con el nuevo sistema.
Objetivo de Control CS-1: los componentes
desarrollarse usando tecnicas de programacidn correctas.
que
se
desarrolien
deben
CAPiTUI.O 19. DF.SARROILO Y MANTEN1MIENTODE SI 599
RA- MA
CS1-C1: se debe preparar adecuadamente el entomo de desarrollo y de

pruebas, asi como los procedimientos de operacion y seguridad. Se debe
comprobar que:
Se han creado e inicializado las bases de datos o ficheros necesarios y
que cumplen las especificaciones de construccion del sistema
obtenidas en la fase de diseno.
En ningun momento se trabaja con information que se encuentra en
explotacion.
Se han preparado los editores, compiladores, herramientas, etc.
necesarios y estan disponibles los puestos de trabajo y acceso a los
equipos, redes, etc.
Se han preparado los procedimientos de copia de seguridad y
restauracion.
Estan disponibles todos los elementos logicos y fisicos para realizar las
pruebas unitarios y de integracion.
Estan documentados todos los procedimientos de operacion, seguridad

y control de acceso al SI para cuando el sistema este en explotacion. Y
estos procedimientos tienen en cuenta los estandares y normas del
departamento de informatica, recogidos previamente en el catalogo de
normas y estandares.
CS1-C2: se debe programar, probar y documentar cada uno de los
componentes identificados en el diseno del sistema. Se debe comprobar que:
Se han desarrollado todos los componentes y se han seguido los
estandares y normas de programacidn y documentacion del &rea
(codigo comentado y documentado).
Se ha probado cada componente de forma unitaria siguiendo el plan de
pruebas y se ha generado el informe de prueba. Si los resultados de las
pruebas no son satisfactorios, se modifica el codigo y se vuelve a
realizar la prueba. Si se detecta un falio de especificacion o disefio, el
proyecto se actualizard segun el procedimiento estabiecido para ello.
ha realizado la codificacion
y prueba de los
procedimientos de migracion y carga inicial de datos.
Sc
componentes
600 AUDITORI A DE TECNOLOGiAS Y SISTEMAS DE INFQ RMAC'IQN
RA-MA
RA-MA
CAPiTULO 19. DESARROLLO Y MANTEN1MIENTO DE SI 60S
CS1-C3: deben realizarse las pruebas de integracion para verificar si los

componentes o subsistemas interactuan correctamente a traves de sus interfaces,
tanto intemas como extemas, cubren la funcionalidad establecida, y se ajustan a los
requisites especificados en las verificaciones correspondientes. Se debe comprobar
que:
CS2-C2: se deben especificar los perfiles de usuario requeridos para el

nuevo sistema. Se debe comprobar que:
Se han ilevado a cabo y realizado un informe segun lo especificado en

el plan de pruebas.
Para cada perfil se ha definido el rango de fechas y la dedication

necesaria.
Se han evaluado las pruebas y se han tornado las acciones correctoras

necesarias para soiventar las incidencias encontradas, actualizandose el
proyecto en consecuencia.
CS2-C3: se deben desarrollar todos los procediniientos de usuario con

arregio a los estandares del area. Se debe comprobar que:
CS1-C4: deben realizarse las pruebas de sistema para comprobar la

integracion del sistema de information globalmente. Se debe comprobar que:
Las pruebas verifican el funcionamiento correcto de las interfaces entre
los distintos subsistemas que 3o componen y con el resto de sistemas de
informacidn con los que se comunica, asi como e! cumplimiento de la
especificacion de requisites, de acuerdo a las verificaciones
establecidas en el plan de pruebas para el nivel de pruebas del sistema.
Se ha generado un informe de pruebas de sistema y se han evaluado las
pruebas y tomandose las acciones correctoras necesarias para soiventar
las incidencias encontradas, actualizandose el proyecto en
consecuencia.
No han participado los usuarios, solo participd el equipo de desarrollo,
Objetivo de Control CS-2: los proyectos de desarrollo deben definir los
procediniientos y formation necesarias para que los usuarios puedan utiiizar el
nuevo sistema adecuadamente.
CS2-C1: el desarrollo de los componentes de usuarios debe estar
Estan definidos los distintos perfiles de usuario requeridos para la

implantacion y explotacion del nuevo sistema.
Estan desarrollados todos los procedimientos de usuario, recopilados

formando el manual de usuario, y son coberentes con las actividades
descritas en la especificacion del sistema.
Cada procedimicnto describe claramente que realiza, el perfil de
usuario asociado, asi como los recursos que son necesarios (equipos,
consumibles, perifericos especiales, espacio, etc.).
Los manuales de usuario y el resto de procedimientos cumplen los
estandares del area y lie van asociado su control de versiones.
CS2-C4: a partir de los perfiles actuales de los usuarios, se deben definir
los procesos de formacion o selection de personal necesarios. Se debe comprobar
que:
La comparacion de perfiles de usuarios y recursos requeridos con los
actuales es realista y los procedimientos que se derivan son adecuados
y estan aprobados por los responsables de las unidades afectadas.
Los procedimientos de formacion estan individualizados y se adaptan a
cada persona, y se le ha comunicado a cada usuario el plan de
formacibn que seguira.
Se han definido y preparado los recursos necesarios para impartir la
formacidn (aulas, medios audiovisuales, tutoriales, etc.).
CS2-C5: se deben definir los recursos materiales necesarios para el trabajo
de los usuarios con el nuevo sistema. Se debe comprobar que:
En el plan de proyecto esti inciuido ei plan para el desarrollo de

los procediniientos de usuario e incluye todas las actividades y
recursos necesarios.
Los procedirrientos se han realizado despues de la
del SI y antes de su implantation.
602 AUDlTORiA DE TECNOLOGf AS Y SISTEMAS DE fNFORMACiON
Se ban determinado los recursos

(consumibies, perifericos, espacio, etc,).
RA-MA
necesarios
para
cada
usuario
Se han comparado con los recursos existentes y se ha pianificado e)

alquiler, leasing, adquisicidn, etc. de los recursos no disponibles dentro de plazo.
19.4.6 Auditoria de la fase de implantaci6n y aceptacion

Esta fase tiene como objetivo principal la entrega y aceptacion del sistema
en su totalidad y la realization de todas las actividades necesarias para el paso a
produccidn del mismo.
Objetivo de Control IA-1: el sistema debe ser aceptado foimalmente por
ios usuarios antes de ser puesto en explotacion.
IA1-C1: el plan de implantacidn y aceptacion se debe revisar para
adaptarlo a la situation final del proyecto. Se debe comprobar que:
ORA-MA
CAPl'TULO i9. DESARROLLO Y MANTENlMiENTO DE SI 603
Las pruebas de implantacidn del sistema participan los'usuarios de

operacion y con ellas se verifica si el SI cumple las especificaciones
funcionales as! como detalles de diseno interne, como si interactua
correctamente con el entorno, incluyendo interfaces con otras
aplicaciones, recuperation ante fallos, copias de seguridad, tiempos de
respuesta, etc.
Las pruebas de aceptacion se realizan por y para los usuarios y
permiten veriftcar si el sistema se ajusta a sus necesidades.
Se han evaluado los resultados de las pruebas y se han tornado las
acclones correctoras necesarias para solveiitar las incidencias
encontradas, actualizandose el proyecto en consecuencia.
IA1-C3: se debe determinar los servicios, y niveles para cada uno, que
requiere e! sistema que se va a implantar, y el acuerdo que se adquiere una vez que
se inicie la produccion. Se debe comprobar que:
Se establece un plan de formation con la formation necesaria para el

equipo de implantacion, en funcidn de los distintos perfiles y niveles
de responsabilidad identificados y se cuenta con la infraestructura y
recursos hurnanos para llevarla a cabo.
Estan definidos los servicios que requiere el sistema y han sido

acordados con la participacion de los maximos responsables del
usuario y de operacion. Y se ha hecho la distincion entre servicios de
gestion de operaciones (servicios por lotes, seguridad, comunicaciones,
etc.) y servicios al ciiente (servicio de atencion a usuario,
mantenimiento, etc.).
Esta incluida la instalacion de todos los componentes desarrollados, asi

como los elementos adicionales (formacion, librerias, utilidades, etc.).
Se ha especificado los niveles de servicio con los que se va a valorar la

calidad de esa prestaeion.
Incluye la initialization de datos y la conversion si es necesaria.
Se ha establecido formalmente el acuerdo de nivel de servicio,

considerando los recursos necesarios, plazos de restablecimiento del
servicio, coste y mecanismos de regulacibn que estan asociados a cada
servicio especificado.
Se revisa el plan
adecuadamente.
de
implantacion
original
se
documenta
Especifica los recursos necesarios para cada actividad, asf como que el
orden marcado para las actividades es compatible.
Se ha tenido en cuenta la information historica sobre estimaciones.
IA1-C2: se deben realizar las pruebas de implantation y aceptacion del
sistema que se especificaron en fases anteriores. Se debe comprobar que:
1A1-C4: el sistema debe ser aprobado formalmente antes de ponerse en

explotacion. Se debe comprobar que:
Se ban realizado las pruebas de implantacion y aceptacion.
Se ha fijado e! acuerdo de nivel dc servicio.
El grupo de usuarios y el eomite de direccion firman su conformidad:;n
Se prepara el entorno real de operation y los recursos necesarios para

realizar las pruebas.
604 AUDITORlA DE TECNOLOGlAS Y SI STEM AS DE INFORMACION
RA-MA
RA-MA
CAPiTUI.O ! 9. DESARROLLO Y MANTENIMIENTO DE SI 605
Objetivo de Control IA-2: el sistema se pondra en explotacion

formalmente y pasara a estar en mantenimiento solo cuando haya sido aceptado y
este preparado todo el entgmo el que se ejecutara.
El mecanismo existe y esta aprobado por el director de proyecto, por el

comite de direction y por el area de desarrollo y mantenimiento (o area
de mantenimiento si esta existe de forma separada).
IA2-C1: se deben instalar todos los procedimientos de explotacion. Se

debe comprobar que:
Tiene en cuenta los tiempos de respuesta mdximos que se pueden

permitir ante situaciones de no funcionamiento.
Se ban instalado ademas del sistema principal todos los procedimientos

auxiliares, como copias, recuperation, etc., tanto manuales como
automaticos.
El procedimiento a seguir ante cualquier problems o para el

mantenimiento del sistema sera conocido por todos los usuarios.
Hstan documentados de forma correcta.
19.4.7 Auditorfa de la fase de mantenimiento
Los usuarios finales han recibido ia formacion necesaria y tienen en su

poder toda ia documentation necesaria, fundamentalmente manuales
de usuario.
El objetivo de esta fase cs 13 obtencion de una nueva version de un sistema

de informacion desarrollado a partir de las peticiones de mantenimiento que los
usuarios realizan con motive de un problema detectadb ert el sistema o por la
necesidad de una mejora del mismo.
Se han eliminado procedimientos antiguos que scan incompatibles con

ei nuevo sistema.
IA2-C2: si existe un sistema antiguo, el sistema nuevo se pondrd en
explotacion de forma coordina con la retirada del antiguo, migrando los datos si es
necesario. Se debe comprobar que:
Hay un periodo de funcionamiento en paraielo de los dos sistemas,
hasta que el nuevo sistema este foncionando con todas las garantias.
Esta situation no debe prolongarse mas tiempo del necesario.
Los datos se convierten de acuerdo al procedimiento desarrollado y se
verifica la consistencia de la information entre el sistema nuevo y el
antiguo.
L42-C3: 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. Se
debe comprobar que:
El indice de utilization del sistema es adecuado a los volumenes que se
esperan para cada una de las areas afectadas por el nuevo sistema.
A2-C4; para terminar el proyecto se pondrii en marcha el mecamsmo de
mantenimiento. Se debe comprobar que:
Objetivo de Control M-l: la gestion del proceso de mantenimiento de

sistemas de informacion debe ser eficiente y eficaz para conseguir mantener el
coste del mantenimiento de los SI del drea bajo control.
Ml-Cl: debe existir una estrategia y un plan para la gestion del

mantenimiento de los SI del area y de sus infraestructuras tecnoiogicas. Se debe
comprobar que:
El plan existe y esta aprobado por la direccion del area y se re visa
periodicamente.
EI plan acordado es compatible con el proceso de gestidn de cambios y
de problemas.
Existe un procedimiento definido y acordado por todas las areas
participantes (sistemas, comunicaciones, desarrollo, mantenimiento,
etc.) en el plan de mantenimiento a fin de facilitar que ia gestidn de los
cambios o ejecucidn de las peticiones de mantenimiento asf como
gestidn de los problemas de los SI se haga de una manera eficaz y
eficientemente.
M1-C2: se deben revisar periddicamente los contratos y acuerdos de nivel
de servicio y monitorizar su grado de cumplimiento. Se debe comprobar que:
606 AUOfTORtA
DE
TECNQLQGI AS V S I S T EM A S D E I N FO R M A C I O N
CRA-MA
Se realizan informes periodicos en un formato comprensible para la

direccion en las que se refleja el grado de eumplimiento de los
acuerdos de nivel de servicio del SI y de los proveedores y donde se
reflejen las desviaciones respecto de lo acordado o contratado.
Esld recogido en algun procedimiento la actualizacion dc los acuerdos
de nivel de servicio en funcion a los cambios de requisitos que se
realizan por el mantenimiento del SI.
Objetivo de Control M-2: todos los cambios, ya sean incidentes,
problemas o peticiones de mantenimiento, incluido el mantenimiento corrective de
emergencia o cambios relacionados con la infraestructura tecnologica del entorno
de production, deben de ser gestionados formalmente y de una manera controiada
a ftn de asegurar la mitigation del riesgo debido a los impactos negatives en la
estabilidad e integridad del SI en produccion.
M2-C1: se debe establecer un sistema estandarizado de registro de
informacion para las peticiones de mantenimiento, con el fin de controlar y
canalizar los cambios propuestos por un usuario o cliente, mejorando el flujo de
trabajo de la organization y proporcionando una gestidn efectiva del
mantenimiento. Se debe comprohar que:
Existe un catalog de problemas y de peticiones de mantenimiento
sobre los sistemas dc informacion.
Todas las peticiones de mantenimiento son presentadas de una forma
estandarizada, para permitir su clasificacion y facilitar la identification
del tipo de mantenimiento requerido.
En cada petition de cambio se recoge al menos la identification,
origen y tipo de petition, se le asigna una priori dad inicial y se le
incorpora una description, jo mas precisa posible, que facilite su
posterior analisis.
De cada peticion de mantenimiento se determina el tipo de

mantenimiento y los sistemas de informacion a los que inicialmente
puede afectar, se comprueba su viabilidad, de acuerdo a las
prestaciones de mantenimiento estabiecidas para dichos sistemas de
informacion y en funcion a dichos criterios se acepta o rechaza la
peticion y se tegistra formalmente.
CAPiTULO 1 9 . D ES A R R Q L L O Y M A N T EN I M I EN T O DE S I 6 0 7
RA-MA
Para cada peticion de mantenimiento aceptada se detennina de quien es

la responsabilidad de atender la solicitud para proceder a su estudib
posterior, es decir, se le asigna un responsable de mantenimiento.
De cada peticion de mantenimiento se recogen los suficientes datos
como para poder ofrecer analisis estadisticos de peticiones recibidas o
atendidas en un determinado periodo, sistemas que se han visto
afectados por los cambios, en que medida y el tiempo empleado en la
resolucidn de dichos cambios.
M2-C2: se debe llevar a cabo un diagnOstico y analisis del cambio para dar
respuesta a las peticiones de mantenimiento que son aceptadas. Se debe comprobar
que:
La informacion registrada es correcta.
Si se trata de una peticion de mantenimiento correctivo, y segun el
acuerdo de nivel de servicio establecido para los sistemas de
informacibn afectados, se evalua hasta que punto es critico el
problema. Si el problema es critico, su analisis y solucion comicnza
inmediatamente con el fin de reanudar rapidamente el nivel de servicio.
Y el procedimiento de actuacidn establecido no exime de una revision
posterior del problema para valorar los posibles efectos secundarios,
establecer una solucibn definitiva y actualizar todos los productos
implicados y su documentacion.
Si se trata de una peticion de mantenimiento evolufivo, se delimita su
alcance determinando si es una modificacion a los sistemas de
informacion inicialmente afectados o de una incorporacion para cubrir
nuevas funcionalidades no contempladas.
En funcion del impacto sobre los sistemas de informacion afectados se
determina la necesidad de desviar la peticion de mantenimiento
evolutive hacia el proceso Estudio de Viabilidad del Sistema o Analisis
del Sistema de Informacion asi como a valorar la existencia de
opciones de productos o servicios del mercado mas idoneos.
La defmicion de la solucion incluye el estudio del impacto de la
solucion propuesta para la peticiOn en los sistemas de informacion
afectados.
mediahte
el
analisis
de
dicho
encargada del proceso de mantenimiento valora el esfuerzo
estudio,
la
persona
608 AUDITOR1A DE TECNOLOG1AS Y SISTEMAS DE INFORMACION
RA-MA
aproximado y coste preeliminar necesario para la implementacion de la

modiflcacion y una fecha limite de implantacion.
Se elige, junto con el usuario, la solution mas adecuada, y se obtiene la
aprobacion o rechazo de ia petition.
M2-C3: se debe de identificar de forma detallada cada uno de 3os
elementos afectados por el cambio mediante el analisis de impacto. Se debe
comprobar que:
Se realiza un analisis que determina que parte del sistema de

informacion se ve afectada, y en que medida, y deja claramentc
definido y documentado qud componentes hay que modificar, tanto de
software como de hardware.
Se identifican las actividades y tareas de los procesos de desarrollo
Estudio de Viabilidad del Sistema, Analisis del Sistema de
Informacion, Diseno del Sistema de Informacion, Construction del
Sistema de Informacion e Implantacion y Aceptacion del Sistema que
es precise realizar, en funcion del plan de mantenimiento establecido
para los SI implicados.
Se establece un plan de trabajo en el que se determina el coste
asociado, los plazos estimados para su implementacion con las fechas
de comienzo y Fin y la composition del equipo de trabajo inicial
necesario
Se defmen puntos de control que permiten hacer un seguimiento del
plan de trabajo durante la implementacion de la modificacidn,
determinando con que frecuencia y en que situaciones se llevara a
cabo.
Se especifican las pruebas de regresion con el fin de comprobar que los
cambios que se lleven a cabo en los componentes afectados, no
produzcan efectos no deseados o errores sobre el mismo u otros
componentes.
M2-C4: se realiza el seguimiento de los cambios que se est&n llevando a
cabo en los procesos de desarrollo, de acuerdo a los puntos de control del ciclo de
vida del cambio establecidos previamente. Se debe comprobar que:
CAPiTULO 19. DESARROLLO Y MANTENIMIENTO DE SI 609
RA-MA
Solo se han modificado los elementos que se ven afectados por el

cambio y que se ban realizado las pruebas correspondientes,
especialmente las pruebas de integration y del sistema.
Se realiza un informe de la evaluation del cambio para su posterior
aprobacion.
Se realizan las pruebas de regresion que especificadas en la actividad
anterior, comprobando que ningun sistema no modificado, pero con
posibilidades de verse afectado, ha variado su comportamiento
habitual.
La aprobacion de la peticion se realiza al finalizar las pruebas de
regresion, y despues de comprobar que todo lo que ha sido modificado
o puede verse afectado por el cambio, ftmciona eorrectamente.
19.5 CONCLUSIONES
A pesar de ser una de las actividades principals de la informatica, el
desarrollo de software no ha conseguido alcanzar de forma general unos
parametros de calidad , aceptables, asimismo el mantenimiento de ios SI
desarrollados es una de las partidas presupuestarias mas importantes dentro de los
departamentos de informatica. En ambos casos, es en las primeras etapas del
desarrollo del software, y especialmente durante las especificaciones del software y
en la Hamada Ingenieria de Requisitos, donde se plasman los primeros pasos de los
aspectos que van a determinar el esfuerzo y la calidad del software y por tanto su
futura mantenibiiidad, lo cual redundard en la produciividad de la organizacion.
La organizacion y gestidn del drea de desarrollo y mantenimiento se
corivierte en uno de los elementos criticos a tener en cuenta por ei auditor.
En este capitulo se han expuesto distintos objetivos de control a modo de
ejemplo, que puedan servir de ayuda al auditor, que los apiicara segun los
considere adecuados en fimcidn del proyecto y de las peculiaridades de cada
organizaci6n.

ITGl (2007a/ Control Objectives
IT Governance Institute, EF.UU.
(COBIT 4.1).
for
Information
and
related
Technology
610 AUDITORIA DE TECNOLOGiAS Y StSTF.MAS OEINFORMACION
5. Analice la influencia de la gestion de configuracion en el desarrollo y

mantenimiento de sistemas. ^,Que tipo de controles estableceria para la
gestion de configuracion?
ITGI (2007b/ IT Assurance Guide using COBIT. IT Governance Institute,

EEUU.
Estos dos iibros del ITGI recogen los principals objetivos de control de la
auditoria de sistemas de information, entre los que se incluyen varios relacionados
con el desarrollo y mantenimiento de sistemas.
19.7 BIBLIOGRAFIA
Il'GI (2G07a). Control Objectives
IT Governance Institute, EEUU.
for
Information
and
related
Technology
(COBIT 4.1).
EEUU.
Planificacion,
version 3).
1/9/2007.
Desarrollo
Disponibie
Mantenimiento
en:
de
sistemas
de
Metodologia
de
(Metrica
Accedido el
informacion
http://www.csi.map.es/csi/metrica3/.
6. (.Cuales pruebas de cumplimiento Ilevaria a cabo sobre la documentation

generada durante el desarrollo y mantenimiento de un sistema
information?
7. (.Cuales de ios ciclos de vida existentes (por ejemplo, cascada, espiral,

incremental, etc.) presenta mas riesgos en el desarrollo de sistemas de
infoimacidn?
8. Analice la importancia de la trazabilidad (de requisitos a productos
finales y viceversa) en la auditoria y control de sistemas informaticos.
ITGI (2007b). IT Assurance Guide using COBIT. IT Governance Institute,
MAP (2007). Ministerio de Administraciones Pubiicas.
CAPITULQ 19. DESARROLLO Y MANTENIMIENTO DE-S1 611
RAMA
RA- MA
Rodero, J.A. (2001). Auditoria del desarrollo. M. Piattini y E. del Peso

(2001). Auditoria Informdtica: Un Enfoque Practico. 2* ed. Editorial Ra-Ma.

1. Estabiezca las diferencias y similitudes entre los objetivos de control para
el desaiTollo y para el mantenimiento de sistemas informaticos.
2. Defina las principales funciones para el area de desarrollo y
mantenimiento de sistemas, y una posible estructura organizativa para la
misma.
3. (.Que tipo de formacidn y experiencia deberia tener una analista? (,Y nil
jefedeproyecto?
4. i,Qu^ tipo de objetivos de control, pruebas de cumplimiento y pruebas
sustantivas Ilevaria a cabo para auditar la reutilizacion de software en el
desarrollo de sistemas informaticos?
9.
(,C6mo
Ilevaria
cabo
la
revision
de
las
pruebas
de
implantacion
aceptacion de un sistema?
10. /.Que diferencias pueden existir de cara a auditar el mantenimiento

preventive, el mantenimiento corrective urgente y el mantenimiento
perfectivo?

Auditori A

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Auditori A

Uploaded by

Copyright:

Available Formats

4<M$ AUDITOR!.* DE TECNOLOGJAS Y S1STF.MA.

13.10 CUESTIONES DE REPASO

2. Defina un procedimiento para ia adquisicion de SGBD.

mercado y los SGBD.

visuales que acceden a bases de datos?

14.1 AMBITO DE TECNICA DE SISTEMAS

reducido a una parcela muy precisa y con un desempeno muy restringido.

que dispongo, eran:

408 AUDITORIA DE TECNOLOGI AS Y SISTBftAS DE INFQRMACION

explotacion como planificadores, paquetes de seguridad, middleware...).

objetivo de nuestros sistemas, estableceriamos, segun mi criterio, el ambito de TS.

14.2 DEFINICION DE LA FUNCION

para acondicionar los componentes del apartado siguiente.

elementos especificos de seguridad (Firewall, IDS, IPS...).

Comunicaciones, como aspectos no cubiertos en los apartados mencionados.

colaboran en la realization del trabajo correspondiente a la funcion concreta.

Aplicaciones (Informatica de Gestion).

CAPiTULO 14. AUDITORIA DE TECNICA DE SISTEMAS 409

mantener en adecuado orden de utilizacion la infraestructura informatica.

Todo de acuerdo con lo ya comentado en el apartado anterior -en cuanto a

necesario para que estas fimcionen correetamente.

4!0 AUDITORIA DE TECNOlOGiAS YSISTEMAS PH 1NFQRMACION

CAPm/i.O 14. AUD1TORJA DE TECN1CA. PE SiSTEMAS 411

* 14.3 EL NIVEL BE SERVICIO

) constituye ei objetivo de los SI (Sistcmas de Informacidn) v que su consecucion se

* Con el rendimiento adecuado

^ expresa en terminos de nive! de servjcio. Toda nuestra actividad deberia estar

fundam.entada en ei logro de ese objetivo y, tanto los procedimientos de actuacion,

supondria una disponibilidad del 99,5%.

) es capaz de determinar objetivamente ei mayor 6 manor grado de eficacia del

utilidad del servicio.

* por cuantas incidencias, de cualquier tipo, impacten en el normal desenvolvimiento

de versiones del sistema operativo, puesta en servicio de nuevas herramientas,

averias de maquina, fallos de corriente o elementos de acondicionamiento,

! arranque o modificacidn de enlaces de comunicaciones, inclusion de nuevos

usuarios o cualquier tipo de problema con el hardware o el software puede

' degradar el servicio, con el consiguienie perjuicio para ia organizaeidn, que no

correspondiente a ese mismo componente.

1 podra desarrollar sus funciones adecuadamcnte o en el tiempo preciso, con el

14.4 LOS PROCEDIMIJENTOS

dificil de calcular, pero, en cualquier caso, importante.

vez que en la busqueda de la calidad se convierte en el aspecto clave de la geslion

Y lo que tales clientes necesitan es la garantia de que el SI cumple su funcidn

adecuadamcnte, puesto que, cada vez mas, es el fundamento de toda la actividad de

Podemos efectuar una clasificacion en:

412 AUDlTORiA DE TECNOLOGiAS Y S1STEMAS DE INFORMACION

CAPITULO 14. AUDlTORiA DE TECNiCA DE S1STEMAS 4 i3

X Requisites para otros componentes

mantenimiento del elemento.

5. Seguridad y Control "

actualizacion de nuevas versiones de software).

pero como ejemplo, podemos pensar en e! Sistema Operative de una maquina. .

REOUIS1TOS PARA OTROS COMPONENTES

adecuado del elemento en cuestion:

Planificacibn. Procedimiento general de! suministrador adaptado a la

Documentation. Inventario de componentes del elemento y normas de

comportamiento de otros componentes del SI.

en los back-up en cuanto

limitaciones que en cuaiquiera de estos aspectos pudieran existir.

Pruebas. Verificaciones a realizar y sus resultados.

servicio: cluster, mecanismos y comprobacion de back-up...).

Comprenderia el conjunto de aeciones necesarias para la puesta al dia de!

414 AUDITORJA DE TECNOLOGIAS Y SISTEMAS DK INFGRMAClON

CAPiTULQ 14. AUDiTORiA DE TECNICA DE SISTEMAS 415