Está en la página 1de 49

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

18.8 LECTURAS RECOMENDADAS


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

18.10 CUESTIONES DE REPASO


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.

19.6 LECTURAS RECOMENDADAS


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.

19.8 CUESTIONES DE REPASO


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?