=-;_rE_

gFA.Mri

CAPTULO

12

AUDITORA DEL DESARROLLO

Jos Antonio Rodero Rodero

1. INTRODUCCION
Lanecesidad de que una organizacin cuente con procedimientos de control in'
aceptada ampliamente como garanta de una gestin eficaz orientada a Ia con'
iii,"
"r de los objetivos marcados. La funcin auditora es precisamente la encargada
iiiCucin
de comprobar Ia existencia de estos procedimientos de control y de verificar su coir..tu d"finicin y aplicacin, determinando las deficiencias que existan al respecto y
liiils "r*o. asociados a estas carencias de control.

,...

Teniendo en cuenta que cada organizaci1npuede descomponerse funcionalmente

distintos departamentos, feas, unidades, eto., es necesariO que loS mecanismos de
interno existan y se respeten en cada una de las divisiones funcionales para que
:sts cumplan adecuadamente su cometido y hagan posible que la organizacin en su

,.,,,

conjunto funcione de manera correcta.

Aplicando la divisin funcional al departamento de informtica de cualquier entid.d, nu de las ireas que tradicionalmente aparece es la de desarrollo. Esta funcin
todas las fases que se deben seguir desde que aparece 1a necesidad de disponer
que ste es construido e implantado.
rde un determinado sistema de informacin hasta
Fara demitar el mbito de este captulo sobre auditora del desarrollo, se entender
;que el desarrollo incluye todo ei ciclo de vida del software excepto la explotacin, el
linantenimiento y la retirada de servicio de las aplicaciones cuando sta tenga lugar.

ii,i

i se entiende por ingeniera del software "el establecimiento y uso de principios

dc ingenierfa robustos, orientados a obtener software econmico que sea fiable, cumpla los requisitos previamente establecidos y funcione de manera eficiente sobre m-

-_!

rvsvrvn

r1r|vNvrArrL\:

uN b,t\UQUE PRACTICO

AU L'T

U-I(rA UE,L UbARROLLO

quinas reales" (Fritz Bauer), la auditora del desarrollo tratar de verificar la exi
y aplicacin de procedimientos de control adecuados que permitan garantizar
desarrollo de sistemas de informacin se ha llevado a cabo segin estos principi
ingeniera, o por ei contrario, determinar 1as deficiencias existentes en este setrtido.

Un 1.5 ft rc us ttl y como se entreg'

cambios'
n g,O 9b e un despus de algunos
o se rehizo'
abandon
gJ
se
96 o us y iuego
n f
us'
se
r47 % i ontrsg Pero nunca

El planteamiento de este captulo est orientado al desarrollo de sistemas

formacin en el sentido tradicional, sin que se hayan tenido en cuenta las peculi
des del desarrollo de otro tipo de software como puedan ser sistemas operativos,

al fil
que son eI producto principal obtenido
Lns aplicacione informticas,
reas
las
principal_de
de trabajo
del dorarrolro, pa'an u-*., ru ierramienta

wae de comunicaciones, software empotrado, etc. Tampoco se ha tenido en

gestin de Ia calidad en el desa:rollo, pues hay un captulo dedicado a ta1 efectoi
conceptos generales de control interno y auditora que ya se abordaron en la parte tr
libro (por ejemplo, criterios para la realizaci1n del informe, recomendaciones en
trato con los auditados, necesidad de independencia del auditor, preparacin y reali
cin de las entrevistas, etc.).

formatizadas,convirtindoseenunfactoresencialparalagestinylatoma

entreg'
Un 29 9b re pag pero nunca se

dscisiones.

. PLANTEAMIENTO Y METODOLOGIA
I

Paratratarlaauditorade)fueadedesarrolloesnecesario'enprimerlugar'
t::,T*::

q"t Td:'ll

del
funciones o tareas que son responsabilidad
las funciones que tradicionalmento
variaciones de una orgunifucion a otfa,

12,2.IMPORTANCIA DE LA AUDITORIA DEL DESARROLLO

al fueade desarrollo son:

Aunque cualquier departamento o xea de una organizacin es susceptible de
uditado, hay una serie de circunstancias que hacen especaimente importante al
ds dcsanollo, y por tanto tambin su auditora, frente a otras funciones o reas
dcl dcpartamento de informtica:

EI gasto destinado a software es cada vez superior al que se dedica

del

rea

y participacin' en la medida que corresponda'

elaboracin del plan estratgico de informtica'

funcin principal y la-que-da se

Desarrollo de nuevos sistemas' sta es la
uno de.los sistemasl
al area de desarrollo. Incluir para cada
"*l11lT;
se supondr funcin
o, construccin e implantacin' El mantenimiento

Los avances en tecnologas de 1os computadores han hecho que actualmen

el desafo ms importante y el principal factor de xito de la informtica sea
mejora de la calidad del software.

Planificacin

il*

ware.

ora

rea.

Estudio de nuevos lenguajes, tcnicas, metodologa:'

:*ndf-:1

cuand'o
ior-J".uoo11o y adopcin de los mismos
tegn0
la
a
adecuado
vigencia
nivel de
considere oporhmo para mantener un

ga del momento.

A pesar de lajuventud de la ciencia informtica, hace aos que se produjo

denominada "crisis del software". Incluye problemas asociados con el
rrollo y mantenimiento del software y afecta a un gran nmero de organi
ciones. En el rea del hardware no se ha dado una crisis equivalente.

El software como producto

es muy

difcil de validar. Un mayor control en

.Establecimientodeunplandeformacinparaelpersonaladscritoalrea.

.
eL1

proceso de desarrollo incrementa la calidad del mismo y disminuye 1os

li,
i"

de mantenimiento.

que
ps6lsgimiento de norrnas y controles para todas las actividades
,en el rea y comprobacin de su observancia'

el
una vez conocidas las tareas que se rearizanen

,r;nTn";;"";;" Gi"r"""la

irea de desarrollo, se

-__- ^4,
en dos grandes apartados, que ms

biviairan con ms detalle:

El ndice de fracasos en proyectos de desarrollo es demasiado alto, lo cual denota la inexistencia o mal funcionamiento de los controles en este procesoil
Los datos del Government Accounting Office Report (EE.UU.) sobre diversos
rn\p.tne rlc cnf'hqrc frzqlnrqr{nc cn

millnnec p dlqrcc\ cnn ilrrctratirnsl

irt. _ Auditora de la organizacin y gestin del rea dededesarrollo.

informacin.
i., _ ;;d; " provlo* de desarrotlo de sisremas

$e

261 AUDITORAINFOIi.M'l'l('A lrN l'Nl'o(Jt rl I'll^( llr ('

O RA-lvlA

CAPITULO 2: AUDITORIA DEL DESARROLLO 265

RA.MA

pueden derivar de esa situacin. Estas conclusiones, junto con las recomendaciones
formuladas, sern las que se plasmen en el informe de auditora.

De estos dos apartados srr lrui nl'ri (1nlrslri ett t'l st'itttttltl ltlr tratarse de la funcin principal del rea, auncluc lll tlc lerrclst' en ('rtcnlir (ltlc tllln lrttena organizacin y

se

gestin es imprescindible paru trrc los l)r'oyr'('l(ls lcn.liut trtrir t:ltlitlltr-l aceptable.

En los apartados siguientes se agrupan los distintos objetivos de control en varias

series, detallndose para cada uno de ellos sus controles asociados y pruebas de curn-

l)ol la ISACA (Information

La metodologa que so aplicrrrii cs lir tt'ortt('slir

Systems Audit and Control Associatirln), tttrr rrslrl hits;ttllt t:tt la cvaluacin de riesgos:
partiendo de los riesgos potenciales a los cuc r:si sotttctitlir una actividad, en este caso
el desarrollo de un sistema de inlornllcirirt, se tlclct'rttinttl tttta scrie de objetivos de
control que minimicen esos riesgos.

plimiento. El esquema seguido es el siguiente:

Organizacin y gestin del rea de desarrolio (serie A, aptdo. 4)
Proyectos de desarrollo de sistemas de informacin
Aprobacin, planificacin y gestin del proyecto (serie B, aptdo. 5.1)
Anlisis
Anlisis de requisitos (serie C, aptdo. 5.2.1)
Especificacin funcional (serie D, aptdo. 5.2.2)
Diseo
Diseo tcnico (serie E, aptdo. 5.3.1)
Construccin
Desarrollo de componentes (serie F, aptdo. 5.4.1)
Desarrollo de procedimientos de usuario (serie G, aptdo. -5.4.21
Implantacin
Pruebas, implantacin y aceptacin (serie H, aptdo. 5^5,I )

Paracadaobjetivodecontrolseespccil'iclulr.ullolttiistcuicasdecontrol,tam-..r
bin denominadas simplemente controles, quc contritrLlyan a lograr el cumplimiento
de dicho objetivo. Adems, se aportan una serie de prucbas de cumplimiento que peI- '"1
mitan la comprobacin de la existencia y correctl aplicacitin de dichos controles. EI .,1i
esquema para cada objetivo de control es:

OBJETIVO DE CONTROLX : ...

C-X-l: Tcnica de control 1 del objetivo de control x

Pruebas de cumplimiento de C-X-1

C-X-m: Tcnica

...

de

control m del objetivo de control x '.'

I. AUDITORIA DE LA ORGANIZACION Y GESTION DEL

nea DE DESARRoLLo

Pruebas de cumplimiento de C-X-m

Una vez fijados los objetivos de control, ser funcin del auditor determinar el
grado de cumplimiento de iada uno de ellos. Para cada objetivo se estudiaran todo-srii
los controles asociados al mismo, usando para ello las pruebas de cumplimiento proii
puestas. con cada prueba de cumplimiento se obtendr alguna evidencia' bi-en ::a
ir".tu o indirecta, sobre la correccin de los controles' Si una simple comprobactn
no ofrece ninguna evidencia, ser necesarialarealizacin de exmenes ms
'

dos.

En los controles en los que sea impracticable una revisin exhaustiva de los eleporquei
mentos de verificacin, bien porque los recursos de auditora sean limitados o
el nmero de elementos a inspeccionar sea muy elevado, se examinar una muestr6'
representativa que permita inferir el estado de todo el conjunto'

El estudio global de todas las conclusiones, pruebas y evidencias obtenidas. so

cada control permitirn al auditor obtener el nivel de satisfaccin de cada objetivo
control, as cmo cules son los puntos fuertes y dbiles del mismo. Con esta in
cin, y teniendo en cuenta las particularidades de Ia organizacin en estudio' se
minar cules son los riesgos no cubiertos, en qu medida lo sOn y qu consecu

Aunque cada proyecto de desarrollo tenga entidad propia y se gestionc cou cicrtu
fi,aptonoma, para poderse llevar a efecto necesita apoyarse en el personal dcl fircu y r:rr
ii',;,llgs proceimientos establecidos. La importancia de estos aspectos ha motivatlu quc sc
,'' dique un apartado exclusivo a la organizacin y gestin del rrea de clesarrollo. Sc
.'consideran ocho objetivos de control (serie A):

,',

OBJETIVO DE CONTROL A1:El rea de desarrollo debe tener unos cornctitkrs

asignados dentro del departamento y una organizacin que Ie permita el curnplinricnto
delos mismos.

C-A1-1: Deben establecerse de forma clara las funciones del irea de desarrollo
,,&ntro

del departamento de informtica. Se debe comprobar que:

Existe el documento que contiene las funciones que son competencia del ftta
de desarrollo, que est aprobado por la direccin de informtica y que se respeta.

lob AUUtIuKIA

CAPITULO

INI'URMAiICA: UN ENFOQUE PRACTICO

C-AL-Z: Debe especificarse el organigrama con la relacin de puestos aet arelii

as como el personal adscrito y el puesto que ocupa cada persona. Debe exisr on p.ocedimiento para la promocin de personal. Se debe comprobar que:
i

261

fuera de la or[.as ol'crtirs tlc ltucstos clel rea se difunden de forma suficiente
objetiva'
forma
de
gauizaciirn y las selecciones se hacen

que acceden.
Las personas seleccionadas cumplen los requisitos dei puesto al

con ios obc-L2-2: Debe existir un plan de formacin que est en consonancia
que:
comprobar
debe
Se
jetivos tecnolgicos que se tengan en el rea '

y largo plazo que sea

Se tiene aprobado un plan de formacin a corto, medio
coherente con la poltica tecnolgica'

Existe la relacin de personal adscrito al rea, incluyendo el puesto ocupadorti

por cada persona. Se deben cumplir los requisitos de los puestos.

fechas'
Incluye toda la informacin relevante para cada actividad formativa:

Estn establecidos los procedimientos de promocin de personal a puestos su-,

,..,
periores, teniendo siempre en cuenta la experiencia y

y esta evaLas actividades formativas se evalan por parte de los asistentes

luacin se tiene en cuenta a la hora de redefinir el plan de formacin.

en cuenta el puesto
Contempla la formacin de todos los empleados y tiene

'i't,

Existe un manual de organizacin que regula las relaciones entre

AUDITORIA DEL DESARROLLO

Existe un organigrama con la estructura de organizacin del rea. Para cad

puesto debe describir las funciones a desempear, los requisitos mnimos dL
tbrmacin y experiencia, y 1a dependencia jerrquica del mismo.

12:

puestos. .i

formacin.

etc'
horarios, lugar, ponentes, asistentes, material, medios necesarios'

t li'
:l!

C-A1-3: El rea debe tener y difundir su propio plan a corto, medio y largo
zo, que ser coherente con el plan de sistemas, si ste existe. Se debe comprobar

pla'r!,i

que:

que ocupan.

El plan existe, es claro y realista.

l,os rccurs()s actuales, ms los que est planificado que se incorporen al rea
srrn srrl'icicntes para su cumplimiento.

.
.

para las personas que

C-A2-3: Debe existir un protocolo de recepcin/abandono
que:
rrr;,i ,se iflcoPoran o dejan el rea. Se debe comprobar
]!:,']lii i
I
r - ---:^f,^ -. ^^ -^^^^| para
incr
^o{o incorporacin/abandono'
. El protocolo
existe y se respeta --.o cada

flir

Sc rr-:visa y actualiza con periodicidad en funcin de las nuevas situaciones.

Sc clil'unde a todos los empleados para que se sientan partcipes del mismo,
rcsto del departamento y a los departamentos a los que les atae.

iiii-,.

comprobar

manual de
Pafa la incorporacin, incluye al menos los estndares definidos,
etc'
puestos,
organizacin del rea, definicin de

ririirf:.

En los abandonos de personal se garantiza la proteccin del rea'

ir!,|,l

Se debq,

que:

Se hace un presupuesto por ejercicio, y se

rriii.r .
I

a1..,

:i,

C-Al-4: El rea de desarrollo llevar su propio control presupuestario.

El plan de ftabajo del rea tiene en cuenta los tiempos de formacin'

ilii.',;,,t,

'

,,1

i,

cumple.

personal
c-L-4:Debe existir una biblioteca y una hemeroteca accesibles por el

1,:,,del rea. Se debe

comprobar que:

El presupuesto est en consonancia con los objetivos a cumplir.

.'
'

,'tl

OBJETIVO DE CONTROL A2: El personal del rea de desarrollo debe conta''

Este
C-A2-5: El personal debe estar motivado en la realizacin de su trabajo'
que:
comprobar
debe
Se
tcnico'
;|."i.pe.to es difcil de valorar y no es puramente

!!ii.,r

con [a tbrmacin adecuada y estar motivado para la realizacin de su trabajo.

C-A2-L: Deben existir procedimientos de contratacin objetivos. Se debe comprobar que:

peridicas,
Estn disponibles un nmero suficiente de libros, publicaciones
acceso a ellos'
monograf?as, etc. de reconocido prestigio y el personal tiene
as-

lll,, o
ir.

sobre
Existe algn mecanismo que permita a los empleados hacer sugerencias

mejoras en la organizacin del rea'

ro AUUII(Jr(rArr\-rui(-lvrArlLA: ul\ til\l't rtJt)li l'lti\l

lt l,

Si no existe plan de sistemas se debe comprobar que:

No existe una gran rotacin dc rcrsorrll y lury trrr hlrt:n irnrbiente de trabajo.

El rendimiento del personal nr cac ror tlc:hirio tlt ttnos rttrrimos razonables yi,.
el absentismo laboral es similrr al dcl r*sto dc lit ot'rtttizitcin

teniendo siempre como alternativa

OBJETIVO DE CONTROL A3: Si existe un plrrrt tlc sistcrnas, los proyectos que
I ,r.',
y lo lnant.enclliirt itctualizado.
f

: lleven a cabo se basarn en dicho plan

C-A3-1: La realizaciin de nuevos proyectos dcho basarsc en el plan de

r cuanto a objetivos, marco general y horizonte temporal. Sc

.
o

cle

be comprobar

sistemasr.

que:

1a

no realizacin del mismo.

la

organizacin que tienen competencia para

aprobar formalmente la realizacin y prioridad de los nuevos proyectos, as
como el caucs para reasignar prioridades si fuese necesario. La decisin,
afirmativa o negativa, se obtendr en un tiempo razonable y se comunicar a

Estn designadas a reas de

los promotores.

Las fechas de reaiizacin coinciden con las del plan dc sistemas.

ii,t,.' OBTETIVO DE CONTROL A5 La

asignacin de recursos a los proyectos debe

iilcerse de forma reglada.

La documentacin relativa a cada proyecto que hay en el plan de sistemas seii

pone a disposicin del director de proyecto una vez comenzado el mismo;r
Esta informacin debe contener los objetivos, los requisitos generales y un.
plan

inicial.

liitt,

C-AS-I: Debe existir un procedimiento para asigriar director y equipo dc clcsu,ill;,nollo a cada nuevo proyecto. Se debe comprobar que:

, ".,

C-A3-2: El plan de sistemas debe acfualizrrse con la informacin que se genera

,largo de un proceso de desarrollo. Se debe comprobar que:

Hay un procedimiento para estudiar la justificacin y llevar a cabo el esfudio

de viabilidad de cada nuevo proyecto, incluyendo un anlisis coste/beneficio y

Los cambios en los planes de los proyectos se comunican al responsable

mantenimientodelplandesistemaspor1asimplicacionesquepudieratener.

OBJETIVO DE CONTROL A4: La propuesta y aprobacin de nuevos

El procedimiento existe y se respeta.

a
:

Se tiene en cuenta a todas las personas disponibles cuyo pert'il ser adccuaclo
los riesgos de cada proyecto y que tengan disponibilidad para participar.

de

Existe un protocolo para solicitar al resto de las reas (sistemas, comunicaciones, etc.) la participacin de personal en el proyecto, y se aplica dicho protocolo.

'iii

proyectosr,,l

:be realizarse de forma reglada.

C-A4-L: Debe existir un procedimiento para la propuesta de realizacin de nue-

los recursos materiales

)s proyectos. Se debe comprobar que:

Existe un mecanismo para registrar necesidades de desarrollo de nuevos sis',j

temas y en todo caso se aportan los siguientes datos: descripcin, necesidad,l'i
departamento patrocinador, riesgos, mafco temporal, coste de |a no realiza:.
cin, ventajas que aporta, adaptacin a los planes de negocio, etc.
'i
Se respeta este mecanismo en todas las

propuestas.

se respeta.

OBJETM DE CONTROL A6: El desarrollo de sistemas de informacin debe

lir

i,.:hacerse ap
aplicando
l'ilrl

El procedimiento existe y

principios de ingeniera del software ampliiamente aceptados

ri

[r,,,

C-A6-1: Debe tenerse implantada una metodologa de desarrollo de sistemas de

informacin soporlada por herramientas de ayuda (CASE). Se debe comprobar que:

C-A,4-2: Debe existir un procedimiento de aprobacin de nuevos proyectos que

epender de que exista o no plan dd sistemas. Si hay un plan de sistemas se debor
ll
omprobar

que:

La metodologa cubre todas las fases del desarrollo y es adaptable a distintos

tipos de proyecto.

Se parte de las pautas, prioridades y planificacin que ste marque para el de-;
sarrollo de cada nuevo

sistema.

.i

ill

710 AUDITORA INFORMTICA:

UN ENFOQUE PRCTICO

c,qptut-o l2: AUDITORA DEL DESARROLLo

O RA-MA
O RA'MA

La metodologa y las tcnicas asociadas a la misma estn adaptadas al entorno

tecnolgico y de organizacin del rea de desarrollo.

Hay un estndar general para toda la documentacin generada, incluyendo

documentacin tcnica (anaUsis, diseo. docurfentacin de los programas,
cuademos de carga, etc.), manuales de usuario, procedimientos de operacin,

l,

Se ha adquirido, homologado e implantado segn las normas del rea una heramienta CASE que se adapta a la metodologa elegida y que cumple con losr:
requisitos mnimos exigibles a una herramienta de este tipo

.
.

CASE

es capaz de mantener el diccionario de

'. .

Hay un estndar para la interfaz de usuario, incluyendo diseo de pantallas,

informes, etc.

Los estndares son conocidos por las personas que deben usados y se respetan. Cuando se produce una modificacin, sta se difunde dentro del rea.

i.

las,i

datos.

C-A6-3: Los lenguajes, compiladores, herramientas CASE, software de control

de versiones, etc. usados en el irea deben ser previamente homologados' Se debe
comprobar que:

, .
,.

Lrr ltcrrarnienta CASE mantiene los requisitos de confidencialidad necesarios

sohr.o llr clocumentacin asociada al proyecto.

('-A(r-2: l)cbc existir un mecanismo de creacin y acfualizacin de estndares,'i.

i,t ( ()r() t.sr;irrtllrros ya definidos para Ias actividades principales. Se prestar especial

ll

,l
r

,rtr.(.r() ;r lrrs llcrramientas y lenguajes de programacin no c1sicas. Se debe compronlccanismo para creacin de nuevos estndares est documentado y es conocido en el rea.

'

Hay un estndar para la realizacin del anlisis y diseo, e incluye las tcnicas
y herramientas a usar, etc.

Cuando se homologa un nuevo producto de desarrollo se forma al personal

del rea que lo vaya a manejar.

il

Se registra la informacin ms importante acerca de la configuracin de los

productos recin adquiridos.
L,c's

productos homologados son suficientes para conseguir los objetivos mar-

cados.

l)cridicamente Se comprueba el nivel tecnolgico, para ver si es coherente

c el plan de sistemas y si est en lnea con el de otras organizaciones simila-

('-A6-4: Dcbc practicarse la reutilizacin del software.

racin es prcticamente imposible si no se estandariza la programacin.

etc.

Hay un estndar de programacin para cada uno de los lenguajes homologaos. se prestar especial atencin a las herramientas denominadas RAD (Rapid Appiication Dvelopment), ya que las secuencias posibles de ejecucin
son muy numerosas (normalmente se activan rutinas por eventos o triggers
(disparadores) y el orden no se puede pfever a priori) y la validacin y depu-

t
t

l',r tlttt'.

. lll

il

il

],I

modularidad, nomenclatura (de funciones, variables, tablas, columnas, etc'),

formato de los comentarios, documentacin asociada, estilo de programacin'

iil

Existe un mecanismo para la adquisicin y homologacin de cualquier nuevo

producto software usado en ei desarrollo. Se deben evaluar al menos los siguientes parmetros: productividad, portabilidad a otros entornos, transicin
esde los productos actuales, solvencia del proveedor, riesgo del cambio,
cumpiimiento de los estndares del irea, compatibilidad con el entorno tecnolgico (SO, protocolos de comunicaciones, SGBD, etc'), coste, etc'

'

Existen convenios sobre los aspectos ms importantes de Ia programacin:

it

j-

Existe un procedimiento que permita determinar en qu proyectos el uso de la

herramienta CASE es ventajoso.

. Ll herramienta
.

etc.

Se ha formado al personai sobre esta metodologa y su adaptacin, as como

sobre las tcnicas asociadas y la herramienta CASE.

Est claramente especificado de qu forma el uso de la herramienta altera

fases de desarrollo tradicionales.

211

Se debe comprobar que:

llxistc: urr catlogo con todos 1os productos software susceptibles de ser reutilrz,rrtrs: libreras de funciones, clases si se utiiiza programacin orientada a
olriclos, programas tipo, componentes software, etc.

t,.l r'rlrilo!,rl es conocido y accesible por todos los miembros del irea, est acr,r,rlr r.,1r r rienc rrnn n vnrios nrlices oue faciliten la bsoueda.

il

272 AUDITORn mrOnv'l'l(,A trN

tlNt,( x.rr rt, t,uCTtco

cepruLo

12:

AUDIToRA DEL DESARRoLL3 2?3

,;ii

Existe un catlogo dc lirs lrrlic:rci()nes lisponibles en el rea, tanto de rur

r.ii;
lizadas como de lrs irrkrririrllrs, con toda la informacin relevante e tas

El protocolo incluye un contrato-tipo que prevea los riesgos ms frecuentes

cuando se contratan servicios externos. y en todo caso incorpora penalizacio-

mlsr,rl

mas.

,r.ri

nes en caso de incumplimiento de contrato por parte del proveedor.

,a

c-A6-5: Debe existir un nrclkrd. quc permita catalogar y estimar los tiempos
oei]

El personal externo que intervendr en

cada una de las fases de los proycclos. Sc debe comprobar que:

tr1;

El mtodo usado es corrccto, est bien ajustado y documentud,

1os

t,tt,li

ud""rud-.i,ii

Una persona dei irea supervisa el trabajo realizado, certificndolo antes del

Las desviaciones producidas er cacla proyecto se usan para ajustar los pari,
metros de catalogacin y estimacin manteniendo un histrico de los mismos-,,r

Debe ser compatible con los estndares establecidos en el rea.

pago.

se producen en los proyectos

del rea, incluyendo los fracasos de proyectos completos. se eue comprobar

cumplir, aI menos,

mente.

C'A6-6: Debe existi un registro de problemas que

..

1os proyectos

mismos requisitos que se exigen a los empleados del rea.

qu,

!;,,l,,i,l

OBJETM DE

La

organizacin del rea debe estar sernprc

forma regular. Se dehc corrrrrolllrl

Existe un catlogo de problemas, incluyendo para cada uno de ellos la sotu.i

cin o soluciones encontradas, proyecto en el que sucedi, persona que lo resolvi, etc.
,r,i,i

Existe el procedimiento de revisin, se aplica con una periodicidad adccuatlr

y se adapta al dinamismo de la tecnologa informtica.

.1,'|'.i

El catlogo

COI\|TROL A8:

i,:4daptada a las necesidades de cada momento.

es accesible para todos los miembros del rea, est actualizado yli
tiene uno o varios ndices que faciliten la bsqueda.

se registran y controlan todos los proyectos fracasados (aquellos que comien i

fin), as como los recursos invertidos en los mismos. ,.i

Cuando se producen modificaciones se documentan, incluyendo la f'echa de

acfualizacin, y se difunden dentro del rea.

zan y no llegan a su

OBJETM DE CONTROL A7: Las relaciones

con el exterior del departamentol

tienen que producirse de acuerdo a un procedimiento.
,ri

,
I

Se est en contacto con un nmero suficiente de proveedores para recibir una

informacin objetiva y completa, y el tiempo invertido en est;s tareas no ex-

cede lo razonable.

c'A7-2: Debe existir un protocolo para contratacin de servicios extemos.

se',!

debe comprobar que:

Existe el protocolo, esf aprobado y se hace uso de

1.
i

La seleccin del proveedor se hace de forma objetiva y evita situaciones

monopolio por parte de un nico proveedor.

de,

,ii

AUDITORN OE PROYECTOS DE DESARROLLO DE S.I

Como se plante en apartados anteriores, cada desarrollo de un nuevo sistema de

i,, informacin ser un proyecto con entidad propia. El proyecto tendr unos objetivos
l"^ marcados y afectar a determinadas unidades de la organizacin. Debe tener un res-

C-L7'1' Deben mantenerse contactos con proveedores para recibir informacin,:

suficientesobreproductoSquepuedanserdeinters.Sedebeomprobarque:

iili;iir,'

i-.I.:TZ.S.

ponsable y ser gestionado con tcnicas que permitan conseguir los objetivos marcados,

teniendo en cuenta los recursos disponibles y las restricciones temporales del mismo.
En esa gestin deben participar todas las partes de la organizacin a las que afecte el
sistema.

La auditora de cada proyecto de desarrollo tendr un plan distinto dependiendo

de ltrs riesgos, la complejidad del mismo y los recursos disponibles para realizar la
auditora. Esto obliga a que sean la pericia y experiencia del auditor las que determinen las actividades del proyecto que se controlarn con may.or intensidad en funcin
de los parimetros anteriores.

274 AUDITORA n,rOntrrtCA: uN ENFOeUE pRCTrcO

CAPITULO I2: AUDITORIADELDESARROLLO 275

En este apartado
delmrn objetivos ytcnicas de control generales
aplicables,
13
a cualquier proyecro. Er
auditor decidir los objetivos ms imporr*.
las caractersticas del proyecto y de la fase
".-arl""" Jj,.i.ii;
a

Se han identificado las unidades de la organizacin a las que afecta.

auditar.

Se debe com-

como se puede observar en el esquema de agrupacin

de objetivos de contror
propuesto en el apartado 3, dentro del
desarrollo de sistemas de informacin se h;*r
enrre las.cuates se encuenrrar,
L:]i:::,:,.:T:j.:l,1,lisiones,
rruccitin
e implantacin. Esras fases, ampriamente
aceptadas
para cl desarrollo, son e_n-:ollcreto
",
ras qu" propone ra -------"^"b
merodol"g;;;
sistctnas de informacin Mtrica versin
2.1.
:,i:j

La designacin

*i;:;;;;;,;"#

i"g;;;;;,,iorlti
d.;""dHi

Adems de estas fases, se ha aadido una

subdivisin que contiene tos ouj"tiuoji
a la aprobacion, pranirii".il y gestin der
pro.i
yecto' La aprobacin der proyecto es un
hlcho previo ar
tras que la gestin se aplica a lo largo
de su dlsarrollo. La planiticacin se realizal
antes de iniciarse, pero sufrir cambioi
a medida que er proye

I"::,:''::'"*:"i::"]::l::TL*"s

Aunque los objetivos de contror se han catarogado

en funcin de ra fase d"t p;i
la auditoa de un proyecto de desarrolto se puede
hacer en
;;,:':l,i,ll..:::...:,Lf1,..i,

i TyT

ros Llementos a

rnspcion.*,

lilljll il, y.,, tlrcume.tos

;;ll.::,1::_T. generados en
rht'trs
cada fase der desarroilo,

ll::,::::l

T:j*i:.:":.

q:". en er.prime,

mismo.

"","

Se ha catalogado

r,

iinil.:l

ilit

*rqr.

,rrr.u

p*iffi

;ilil:
iLlf

Se han evaluado los riesgos asociados al proyecto, especialmente cuando

van a usar tecnologas no usadas hasta el momento.

se

i .

Se ha elegido el ciclo de vida ms adecuado al tipo de proyecto de que se tra-

ta.

Se prestar especial atencin si se elige un ciclo de vida basado en prototipir-

rri

do. En este caso deben cumplirse los requisitos necesarios para aplicarlo corr
xito (dificultad de los usuarios para expresar los requisitos y disponibilidad
tlc una herramienta de construccin rpida de prototipos) y debe existir un
ircucrdo con los usuarios sobre el alcance del prototipo y el objetivo que sc
rcrsiguc con el mismo.

0BIETIVO DE coNTRoL Br: El proyecto de desarrollo

debe esrar aprobadoi

(l-lll-4:

,.

[.lnr vez.

determinado el ciclo de vida a seguir, se debe elegir el equipr

y se determinar el plan del proyecto. Se debe com,

tcltico rlttr: r'r.:rrlizlrr cl proyecto

pfohiu.(lr(.:

c'81-1: Debe existir

una orden de aprobacin der proyecto

que defina craramente los objetivos, restricciones y las unidades
afectadas. se eue ."*p."u*

'

y dimensionado el proyecto segn las nornas establecidas.

Se ha hecho uso de la informacin histrica que se dispone tanto para dimensionar el proyecto y sus riesgos como para seleccionar el ciclo de vida.

Se consideran en este apartado dos objetivos

de control (serie B):

[rlr]

d:

ll

lil ir'

12'5'1. Aprobacin, pranificacin y gestn

der proyecto

cabo segn el procedimiento establecido.

r:ii I

li.lilll

,"., i;;;i;o,ir';;""fi
r".-.o".r,,ro,". "'l

,i-1,
rrr.r r:rrrrl. cl
auditor pueden afectar al desarrolio del proyecto,
r;i crr l;r lorlra cle tlecisiones del

t,r:il

.i;iirri,

,";J,;;iff;'J
;;"r",** ffi#

lievado

Se le ha comunicado ai director su nombramiento junto con toda la informacin relevante del proyecto.

comienzoffi;il"#;.*,j

"";;;;;;"d.'

se ha

I ,rr

tlcsi:,lirciin del director del proyecto y del equipo de desarrollo se ha llcr cirho scgn el procedimiento establecido.

vrrkr

"p:*:il

del proyecto refrendada por un rgano

3Li:'j:^r:i
-":d_"1 de viabilidad
petente.
El estudio
debe haber seguido el cauce establecido.

com_

Iin cl documento de aprobacin estn definidos

de forma clara y precisa
.bietivos de1 mismo y las restricciones de todo
tioo oue dehen renerqe

l,us prrrlicirantes que pertenezcan a oas reas (sistemas, comunicacioncs,

o l i n rirt

ir:rr. ctc. ) se han solicitado segn el protocolo existente.

lir prrticira personal externo, los perfiies profesionales son adecuados a llx

O n,"t-tr,l^

cAp[TULo t]: AUDITORiA DEL DESARRoLI_o r_-

O RA-MA

se ha comunicatl. a t.cr.s I.s miembros del equipo de desarrollo

los objetivos
del proyecto, la resronsnbilicrad que tendrn en er mismo,
las fechas .n lu*.,,,
que participarn y la dcclicacin (completa/parcial).

,,,, 9*1-1

o"be existir un conrrol de cambios a lo largo del proyecro.

se

comproDar que:

debe

:I

El plan de proyecto realizaclo

que se disponga para realizar

es realista y

utiliza la informacin histrica

estimaciones.

:, r
,.
r
r-r,
:

la :

.,,,,r:riii1

0BJETIV0 DE col\trRoL 82: El proyecro se debe gestionar de

forma qr.
consigan Ios mejores resultados posibtes teniendo en
vrr wuvlra
cuenta=las
ral rsLrluululres
restriccion", Ue
A"',1"*1,,,;
Ugln:t,,ilt
po y recursos' Los criterios usados sern coherentes
con los objetivos e tas uniaeiiir

,.

,,1:,

ilr

C-BZ'L: Los responsables de las unidades o ireas afectadas por

el proye"to .-'.

que:

:;,,

se ha constituido formarmente er comit de direccin der proyecto

y en l es.
tn incluidos los responsables de todas las unidades afectaas.
:,riirl

El comit tiene una periodicidad de reunin mnima, y en cualquier

caso,
siempre que 1o exija el desarrolro der proyecto, debe teneicor"p","nru
f*aiilri
asignacin de recursos,

la revisin de ra marcha der proyecto

el plan del proyecto en funcin de las revisiones.

Hay un mtodo para catalogar y dar prioridad a ros problemas,

pora
as
trasladarlos a la persona que ros debe resorver, informando
"o*o
si es neces*io ,
director del proyecto y al comit de direccin.

se controla la solucin del problema y se deja constancia

de la misma.

Se remite la nueva versin de los documentos actualizados

a ios participantes

en el proyectO.

c'82-4: gyurd?

sea necesario reajustar el plan del proyecto, nornralr(:rc

.l
nazar un modulo o tase, debe hacerse de forma adecuada. Se debe
cornprohirr trrt.:

l.i

se respetan los lmites temporales y presupuestarios nlarcad,s

irr
proyecto. Si no es as debe ser aprobado por el comit ds
direce iti,.

trrr

i.i.i.

se ha hecho uso de la informacin histrica que se dispone en

el rea sobre

estimaciones.

se notifica el cambio a todas las personas que de una u otra forma

participen
en el proyecto y se vean afectados.

El nmero de reuniones y la duracin de ras mismas no superan

un timite rai,
zonable comparado con la envergadura del proyecto.

Existen hojas de registro de problemas y que hay alguna persona

del
encargada de su recepcin, as como un procedimiento
conocido de
cin.

cin.

;:

Las reuniones se hacen con un orden del da previo y ras

decisiones tomada
quedan documentadas en las actas de dicho comit.

se actualiza de forma adecuada y se lleva un

con_
trol de versiones de cada producto, -consignando la ltima fecha
de acfualiza-

Se han tenido en cuenta los riesgos del reajuste.

ip;;Jdrfi;''

c'B.2'2: se debe establecer un mecanismo para la resolucin

de los proble
que puedan plantearse a lo largo del proyecto.
Se ebe comprobar que:

La documentacin afectada

rl:'

afectadas.

ben participar en la gestin del proyecto. Se debe comprobar

Existe un mecanismo para registrar ros cambios que pudieran

producirse, as
como para evaluar el impacto de los mismos.

Si existe un plan de sistemas, se actualizar en consecuencia.

rl+l'ril C-82-5:
1i,1

Debe hacerse un seguimiento de los tiempos empleados

tanto por tarea
co*o a lo largo del proyecto. Se debe comprobar que:

Existe un procedimiento que permita registrar los tiempos

que cada participante del proyecto dedica al mismo y qu tarea
realiza", .." ii".po.
Las productividades que se obtienen para distintos empleados
en las mismas
tareas son similares y estn en consonancia con
la informacin histrica.
debe controlar que se siguen las etapas del cicro de vida
adoptado pai * ^, 5:?.1'6: se
y Qul se generan todos los documentos

fi,.l.li:-1..,o
stt,
)c dcbe comprobar

asociados

que:

"

,u;";;;;;

,-

__^.

"..,^ ur.vryrAtrcA:

uN ENFOeUE PRCTICO

l:,r:,

@RA"MA

Antes de comenzar una nueva

etapa se ha r{ncr,_o-r^r^ r^
re vi s ado y

;;;;,

;:::Jfi:?[l'f

,1:,1,,:: T:XTff i:

--

cepruLct

rz,

euorroR oel- orro**oiil

Il,#Ivi

\d

La documentacin cumple
los estndares establecidos
en el rea.
se respeta el plan estabrecido
y en caso contrario se toman
las medidas
tunas o se procede a la
aprobaciO, a" unu iroOficaciOn
del plan.

Se respeta el uso de recursos

previamente establecido.

,rl

:1r..,, A partir der conocimiento del sistema.actuar y sus probremas

asociados, junto
.,""*a
se determinarn ras posibres
::i*,11-;i,,"""
alte-rnativas:::
lu":"".utirrugur
.ro. ."ni,'rtt"r[u;t:"""j|H:ffi'Jlt":r'lj1: solu- ciones

ffi I';:"*:*:

ms

adecuada. Se consideran dos objetivos

Oe cntrol (serie C):

::::

ii;

DE
CI: Los usuarios v responsables de las
iir"
unidades
^.9^{{{:!vg
atecta el nuevo',NTROL
Ias que
sistema establecern A. fo.rouit*-u.i,rr?"quisitos
del mismo.
.

c-82'7: Cuando termina el proyecto

se-debe cerrar toda ,a
mismo' liberar los recursos
documentacin
empleados y
hacer batanc"

s" a".probar

que:

La documentacin del provecto

, !
cmrro a,
es completa
-.a
^-+< catalogada
y est
perf-ectament
por,".io."xtoyecto

para accesos

Existe un documento aprobado por

el comit de direccin en er que
se determina formalmente el grupo de usuarios
que pa.tlcipa. en el proyecto.

L-os recursos. tanto personales

como materiales
j:^_
c" ponen
n^a a
ales' se
^ disposicin
rea o departu**
oil
qu"

llr

provienen.

l"ll comit de direccin

v el
csrucjiando los posibles

dire.r^. ,r^r *_^-.

elegidos son suficientemente represenrarivos

de ras distintas fun_
_!:t-::l*t"clones
que se lrevan a cabo en las
unidades afectadas po.

hacen balance der p.oyeci

j:1;H,13x'Jrt1,:::l

ffi'riff::": ],|lr:l::t:
::':;lll-?"l;Ji.'i'::,,:::":,.-,;;;;:;;;.::,
u.i, e re gi tra ., . ;hi;"
;i, ::;.:;I i:"i:
I ;ffi :"I ;1rm
rrirhlcmas
s

"in*ro

.ir,".nn.

Se les ha comunicado a los usuarios

su participacin en el proyecto,
informndoles del mbito del mismo y
de qu es lo que se espera de ellos,
as como la dedicacin estimada que les
,rp*A.a
esta tarea.

l.a nueva aplicacin ,:,.r:_":T"r,"

al.carlogo de aplicaciones

toda la informacin relevante

de Ia misma.

tiilr
exisrentes

12.5.2. Auditora de la
fase de anlisis
La fase de anlisis. pretende
obtener un conjunto de
que describan las nec.esid-ades
especificaciones formatres,i
de lri"""i0, que deben
ser cubiertas por el nuevo
sistema de una forma
indep"ri""t.^"i;;"
tcnico.

Esta fase se divide en dos

mdulos:

ffi

c-c1-2: se debe

j?,n;:*

En este mdulo se identificarn

requisitos del nuevo sistema.

Se inclu
los
no
funcionales, disringuiend"
de eilos su importancia
"ornoil;;"d,
y prioridad.

.los

l'

::

"*

;;;

"'

':ilffiffiffi;

':que:

Existe un plan consensuado con

er comit de direccin que detalra
para cada
entrevista la fecha,
lugar, tipo de entrevista (individual,
l?ru/
en grupo, por
cscriro, erc.) y un guin
" r"Jurp.Ir*iu.

"n

.ii;

J;;;.'

sc rllrtrevista a todos ros integrantes

en er grupo
*vs.*rv. yr a< todos ros res_
c 'r - de
-- usuarios
ponsahlcs t]c las unidades

afeitadas.

12.5.2.1. Anlisis de
Requisitos del Sistema (ARS)
tanto_ los requisitos
funcionales

:1""1" :^"j ]

r-earizar un pran detallado de

entrevistas con el grupo de usua_
uni dade s arec tadas que permita
c on o ce
+

sc .cr,irc cl guitin a los entrevistados

con tiempo suficiente para que
r)*[)ur.r ra enrrevista v ra documenracin que desee,

lllilli:il

l')l riri,

lu'r

lri

stos

aporrar a la

rrrcrrr-yc rrxrirs rus cuestiones

necesarias para

lrr.rrrrrs

tl('('c\t lt I rs()l

V(.f

tur: c,r cnrrevistado

realiz.

obbner informacin

so_

r*o*mas

que

ilffi;;?i"r

280

ALTDIToRA INFORM'l'l('A:

llN

lLNl (

)(.)llll l'1{cTICo

Una vez documentatlrs lils cntrevistas, se contrastan Ias conclusiones de laS

mismas con los entrevisttdos.

C-CL-3:

partir cle la inlorrnacin obtenida en las entrevistas, se debe

zE t

l,,t

C-CZ-L: Dados los requisitos del nuevo sistema se deben definir las diferentes
alternativas de construccin con sus ventajas e inconvenientes. Se evaluarn las alternadvas y se seleccionar Ia ms adecuada. Se debe comprobar que:

docu-:

Existe un documento en el que se describen las distintas alternativas.

mentar el sistema actual as como los problemas asociados al mismo. Se debe ob

tambin un catlogo con los requisitos del nuevo sistema. Se debe comprobar que: 'l.i

Hay ms de una alternativa, y en caso contrario, que no existe realmente otra

posible.

Se ha realizado un modelo fsico del sistema actual, incluyendo los objeti

y funciones de cada unidad, as como sus flujos de entrada y salida de i
a

macin.
Se han catalogado los problemas del sistema actual as como que estos
blemas son reales.

Cada alternativa est descrita desde un punto de vista lgico (aI menos modelo lgico de procesos) y es coherente con los requisitos establecidos.

,al

Si existe en el mercado algn producto que cumpla con unas mnimas garantas los requsitos especificados, una de las alternativas debe ser su c()nlprir.

.a
ti

Se han realizado el modelo

CAPITULO I2: AUDI lOlttA DEL DESARKULLU

RA.MA

'

lgico de datos y el modelo lgico de procesos

sistema actual, as como que stos son correctos y que se han llevado a
con las tcnicas usadas en el rea.

Si no lo impiden las caractersticas del proyecto una de las altcrnativus tk'lx'

ser el desarrollo del sistema por parte de una empresa externI.

i'.

i: a

Existe el catlogo de requisitos que estnjustificados.

Cada requisito tiene una prioridad

y est clasificado en funcional o no funcill

nal.

dos.

El comit de direccin ha seleccionado una aiternativa como la ms ventajosa

y es realmente la mejor para la organizacin.

C-C2-2: La actualzacin del plan de proyecto seguir los criterios ya comenta-

El catlogo de requisitos ha sido revisado y aprobado por el grupo de usuano$

y por el comit de direccin, constituyendo a partir de este momento el "con',
lrato" entre stos y el equipo que desarrolla el proyecto.
C-C1.-4: Debe existir un procedimiento formal para registrar cambios en los re-,
quisitos del sistema por parte de los usuarios. Se debe comprobar
',

que:

El procedimiento existe y est aprobado.

Es coherente con el procedimicnto de control del cambio general para el pro-'

yecto.

OBIETIVO DE CONTROI. Ll2.lin cl proyecto de desarrollo se utilizarla?L::'

ternativa ms favorable para conscgtrir tue el sistema cumpla los requisitos estableci'
dos.

rlc lilrrrrr

objetiva (anlisis coste/beneficio por ejemplo), as como los ricsgos asocia.

Los requisitos son concretos y cuantificables, de forma que pueda de

se el grado de cumplimiento al final del proyecto.

Se han evaluado las ventajas e inconvenientes de cada alternativa

282

AUDITORE WT'ONUTTCA: UN ENFOQUE PRCTICO

O RA.MA

OBTETM DE CONTROL Dl: El nuevo sistema debe especificarse de forma..;

completa desde el punto de vista funcional, contando esta especificacin con la apro- l
hacin de los usuarios.

que:

283

C-D1-3: Debe definirse la forma en que el nuevo sistema interactuar con los
distintos usuarios. sta es la parte ms importante para el usuario porque definir su
forma de trabajo con el sistema. Se debe comprobar que:

C-D1-1: Se debe realizar un modelo lgico del nuevo sistema, incluyendo Mo.
delo Lgico de Procesos (MLP) y Modelo Lgico de Datos (MLD). Ambos deben ser.,,:
eonsolidados para garantizar su coherencia. Se debe comprobar

CAPTUIO I2: AUDITORA DEL DESARROLLo

O RA.MA

.,

Se han descrito con suficiente detalle las pantallas a travs de las cuales el
usuario navegar por la aplicacin, incluyendo todos los campos significativos, teclas de funcin disponibles, mens, botones, etc. Si hay normas de diseo o estilo de pantallas en el rea, se verif,car que se respetan.

Se ha partido de los modelos realizados en el anlisis de requisitos del siste-

ma.

Existe el MLP, se ha realizado con la tcnica adecuada (normalmente diagra;.i

mas de flujos de datos) y es correcto tcnicarnente. Describir qu debe reali'
zar el sistema sin entrar en la forma en que lo har. Los procesos manuales
deben estar diferenciados. Los usuarios deben entender las convenciones de
smbolos usadas.

En el diagrama de contexto estn reflejados todos los agentes extemos. incluidos otros sistemas con los que el sistema intercambia informacin. Para
carla llujo de datos de entrada o de salida debe estar documentado el contenij
tkr, ln ltccuencia, suceso que lo origina, etc.

.
'
I

Lainte,rfaz de usuario se ha aprobado por ei grupo de usuarios y por el comit

de direccin.

C-Dl-4: La especificacin del nuevo sistema incluir los requisitos de seguridad,

iii.i.,,rendimrento, copias de seguridad y recuperacin, etc. Se debe comprobar que:

lixistc cl MLD, se ha realizado con la tcnica adecuada (normalmente

cntidird-relacin o diagramas de estructura de datos)

Se han descrito con suficiente detalle los informes que se obtendrn del siste-

ma y los formularios asociados, si stos existen. Si hay normas de diseo o

estilo de informes y formularios en el rea, se verificar que se respetan.

Esta informacin se ha solicitado a los usuarios en las entrevistas correspondientes a este mdulo y se ha documentado y contrastado.

es correcto tcnica-r

rncnt.c. Debe estar normalizado al menos hasta la tercera forma

normal.

riii
.|i

Se han aadido estos requisitos al catlogo de requisitos ya realizado en el

ARS.

En el MLD estn reflejadas todas las entidades con sus atributos y claves,
como las relaciones entre las mismas.

El MLP y el MLD son coherentes entre s. La consolidacin

C-Dl-5: Se deben especificar las pruebas que el nuevo sistema debe superar para
,ser accptado. Se debe comprobar que:

se debe

usando tcnicas adecuadas (Historia de la vida de las entidades, por ejemplo

Et MLP y el MLD han sido aprobados por los usuarios y por el comit de
reccin.

Sc ha clahorado el plan de pruebas de aceptacin dei sistema, que ste es

coltel'clttc con el catlogo de requisitos y con la especificacin funcional del
sistcrrur y rre cs aceptado por el grupo de usuarios y por el comit de direcc

rin.

C-D1-2: Debe existir el diccionario de datos o repositorio. Se debe

que:

I'll llllrr rlc r.ttr'hlrs tlcr aceptacin

Existe el diccionario de datos, es correcto y

ri

se gestiona de forma

da.

Se respetan en su gestin todos los procedimientos de control de

i"
cambios.

tiene en cuenta todos los recursos necesa-

tls.

C-Dl-6: l,ir rrulrtrlrrt rorr tlrl rlrrn cle proyecto seguir los criterios ya comentaidos, detallintltlsc r-'n cslc punl() ('lr nlry()r medida la entrega y transicin al nuevo siste*^

284 AUDITORA INFORMTICA:

I.JN

c.ptut-o

O RA-MA

O RA.MA

IINII{X](]E PRCTICO

12.5.3. Auditora de la fase de diseo

.f.

,..i

necesario.

1o:

Los componentes o proglamas del nuevo sistema se han definido con detalle a
partir del diseo modular, la definicin es correcta y sigue los estndares del
rea. La descripcin de los componentes es suficiente para permitir su programacin por parte de un programador sin conocimiento previo del sistema.

12.5.3.1.Diseo Tcnico del Sistema (DTS)

A partir de las especificaciones funcionales, y teniendo en cuenta el entorno te^c

nolgic, se disear la arquitectura de1 sistema y e1 esquema extemo de datos' Se

Se deben especificar los requisitos de operacin de los componentes'

i
,

considera un nico objetivo de control (serie E):

Se han detallado las interfaces de datos y control con otros mdulos y sistcmas, as como la interfaz de usuario ya especificada en el mdulo EFS.

CONTROL EL: Se debe definir una arquitectura fsica para el,rrir

sistema coherente con la especificacin funcional que se tenga y con el entorno tec:']

OBJETM DE

nolgico elegido.

C-EL-3:
.

C-Et-L: El entorno tecnolgico debe estar definido de forma clara y ser confor-,;,

que:

285

Los mdulos se disean para poder ser usados por otras aplicaciones si fuera

vosistemaqueservirndebasepara1aconstruccindelmismo.Hayunnicomdu-

me a los estndares del departamento de informtica. Se debe comprobar

DESARROLLo

El tamao de los mdulos es adecuado, el factor de acoplamiento entre ellos

es mnimo y la cohesin interna de cada mdulo es mxima.

l;;

En la fase de diseo se elaborar el conjunto de especificaciones fsicas del nue'

r2: AUDIToRA DEL

,,:,ii

Se debe disear la estructura fsica de datos adaptantlo las trstt't'ilicttt'trr

nes del sistema al entorno tecnolgico' Se debe comprobar quc:

''
,

El modelo fsico de datos est basado en el MLD oblcrtido crt cl rrt(rtlttlo liliS
e incluye todas las entidades, relaciones, claves, vistits, ctc'

'r'i'rir

Estn perfectamente definidos todos los elementos que configuran el entorno:"i

tecnolgico para el proyecto (servidores, ordenadores personales, perifricos,
sistemai opeiativos,-conexiones de red, protocoios de comunicacir, sistemas
gestores di bases de datos, compiladores, herramientas CASE, middleware en:

casodeprogramacinc1iente/servidor,libreras,etc.)'

del
Se dispone de los elementos seleccionados, estn dentro de los estdares
departamento de informtica y son capaces de responder a los requisitos esta'
.,
blecidos de volmenes, tiempos de respuesta, seguridad,

etc'

C-El-2:

Se deben

identificar todas las actividades f sicas arealizar por el sistema"*l

y descomponer las mismas de forma modular. Se debe comprobar que:

a
a

sistema' "''i
Se han documentado todas las activiclades sicas que debe realizar el
el''ril
El catlogo de actividades es ctlltcrclltL! con las tunciones identificadas en
MLP dei mduto EFS.
que ya
Se han identificado las actividrdc (lLlc s()ll colnunes, as como las
existan en las libreas generllcrs tk'l iircir'
ha'i:
Existe el documento con cl disctl tlc lit cstl'ttctura modular del sistema, se
por
realizado con una tcniclt atlccrlittlt 1l)iirgrlrrtras de estructura de cuadros
ejemplo) y es correcto

' :
'

Tiene en cuenta el entomo tecnolgico

y los recluisitos de rendirnicnto

para

los volmenes y frecuencias de acceso estimados.

Si incluye algn incumplimiento de las normas, est justificada.

.,

C-8L-4: Se debe disear un plan de pruebas que permita la verificacin de los

, distintos componentes del sistema por separado, as como el funcionamiento de Ios
rrdistintos subsistemas y del sistema en conjunto. Se debe comprobar que:
Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto.
Las personas que realizarn las pruebas de verificacin son distintas a las que
han desarrollado el sistema.
Es adecuado para validar cada uno de los componentes del sistema, incluyendo pruebas del tipo caja blanca para cada mdulo. Tendrin en cuenta todas las
posibles condiciones lgicas de ejecucin, adems de posibles fallos del
hardware o software de base.
Permite validar la integracin de los distintos componentes
conjunto.

y el sistema en

]86

AUDITORA WPONT'ITICA: UN ENFOQUE PRCTICO

CAPITULO l2: AUD{TORIA DEL DESARROLLO

o RA-lvlA

RA.M4

287

C-F1-2: Se debe programar, probar y documentar cada uno de ios componentes

C-E1-5: La actualizacin del plan de proyecto seguir los criterios ya comen-

identificados en el diseo del sistema. Se debe comprobar que:

Se han desarrollado todos los componentes o mdulos.
Se han seguido los estndares de programacin y documentacin del rea, el
cdigo es estructurado, est bien sangrado y contiene comentarios suficientes.

esta tase se programarn y probarn los distintos componentes y se pondrn

trabajar
cr ularcha todos los procedimientos necesarios para que los usuarios puedan
en
la fase
obtenidas
fsicas
coil cl nusvo sistema. Estar basado en las especificaciones

l}l

Se ha probado cada componente y se ha generado el informe de prueba. Si los

resultados de ias pruebas no son satisfactorios, se modifica el cdigo y se
vuelve arealzar la prueba. Si se detecta un fallo de especificacin o diseo, el
proyecto se actualizar segn el procedimiento establecido para ello.

tk: rlisctio. Hay dos mdulos.

.

12.5.4.1. Desarrollo de los Componentes del Sistema (DCS)

lln

',

este mdulo se realizarn los distintos componentes, se probarn tanto indivi-

tlualrucntc como de forma integrada, y se desarrollarn los procedimientos de oper&:l;

c:irin. Sc considera un nico objetivo de control (serie F):

OB.lliT'lvT DE CONTROL F1: Los componentes o mdulos deben desarrollarsr' rrs:rrrrkr lcir-:tticas dc programacin correctas.

C-F1-3: Deben realizarse las pruebas de integracin para asegurar que las inter-

faces entre los componentes o mdulos funcionan correctamente. Se debe comprobar

i qo.,
..

,
,r, .

rl,
-.

,ilri

Sc tlctrc preparar adecuadamente el entorno de desarrollo y de prueba'l

()rr()
los rrrrr.t,tlinrientos de operacin, antes de iniciar el desarrollo. Se debe comllij
ir,it r

(,-lrl-l:

diseo.

en

COnSeCUenCla.

.
'

que'

Se han evaluado las pruebas y se han tomado las acciones correctoras necesa-

rias para solventar las incidencias encontradas, actualizndose el proyecto

iii

rroIr;tt rttt':

Sc lurn crcatlo e inicializado las bases de datos o ficheros necesarios

currrplon las especificaciones realizadas en el mdulo de

Las pruebas de integracin se han llevado a cabo segn 1o especificado en el

plantde pruebas realizado en el mdulo de diseo.

No han participado los usuarios. En las pruebas de integracin slo debe participar el equipo de desarrollo.

',i
l

12.5.4.2. Desarrollo de los Procedimientos de I]suario (DPU)

En ningn momento se trabaja con informacin que se encuentra en explotacin.

Se han preparado los procedimientos de copia de seguridad'

Se han preparado los editores, compiladores, herramientas, etc. necesarios'

Estn disponibles los puestos de trabajo y el acceso a los equipos' redes, etc'

OBJliflvO DE CONTROL Gl: Al

trmino del proyecto, los futuros usuarios

deben cstar caucitados y disponer de todos los medios para hacer uso del sistema.

prueEstn disponibles todos los elementos lgicos y fsicos para realizar las
pruebas
de
bas unitarias de los componentes y las

integracin'

En este mdulo se definen los procedimientos y formacin necesarios para quc

Ios usuarios puedan utilizar el nuevo sistema adecuadamente. Fundamentalmente sc
trah de la instalacin, la conversin de datos y la operacin/explotacin. Se consideru
un nicrl objetivo de control (serie G):

C-(;l-l: Irl rk:srrrrollti de los componentes

:

de usuario debe estar planificado.

So

debe conrprrrllirl rrrc:

ri

Estn documentados todos 1os procedimientos de operacin para cuando

sistema est en

exPlotacin.

etr
.il

En el rlun tlcl l)roy('('l( ) csth incluido el plan para el desarrollo de los procc'tli
micntos rlc rsrrrrrrr t'irr, lrryr: totlas Ias actividades y recursos necesarios.

l{i\

cnpTuLo I2: AUDITORiA DELDESARROLLO

MA

289

UN tiNIJ( X)I]I., PRCTICO

AUDITORA INFORMTICA:

Se han determinado los recursos necesarios para cada usuario (consumibles,

perifricos especiales, espacio, etc.).

.Losprocedirnientossellevanacaborlespusdetenerlaespecificacinfun-,
implantacin del mismo'
cional del sistemal antes de la

Se han comparado con los recursos existentes y se ha planificado el alquiler,

leasing, adquisicin, etc. de los recursos no disponibles dentro de plazo.

C.Gl.Z:sedebenespecificarlosperfilesdeusuariorequeridosparaelfluevo
tema. Se debe comProbar que:

la implantaperfiles de usuario requeridos para

Estn definidos los distintos
cin y explotacin del nuevo sistema'

12.5.5. Auditora de la fase de implantacin

En esta fase se realizar la aceptacin del sistema por parte de los usuarios, adems de las actividades necesarias para la puesta en marcha. Hay un nico mdulo:

.Paracadaperfilsehadefinidoeirangodefechasyladedicacinnecesaria.,
C.G1-3:Sedebendesarrollartodoslosprocedimientosdeusuarioconarregloa
,*

"urndr",

del area' Se debe comprobar

que:

12.5.5.1. Pruebas, Implantacin y Aceptacin del Sistema (PIA)

,,

el sistema cumple con los rcquisiltls crilrlrlt'ct

dos en la fase de anlisis. fJnayez probado y aceptado se pondt'r crt c:xrkrlitci(rtt. St'

fgrman'
procedimientos de usuario, recopilados
Estn desarrollados todos los

Se verificar en este mdulo que

doelmanualdeusuario,ySoncoherentesconlasactividadesdescritasen

EFS.

ionsideran dos objetivos de control (serie H):

,.

Cadaprocedimientodescribeclaramentequrealiza,elperfildeusuarioaso-.
(equipos, consumibles, perif ''''
que son necesanos
ciado, as como los recursos
etc')'
ricos esPeciales, esPacio,

seo del mismo. Se debe comprobar que:

Se prepara el entorno

1as

pruebas.

Las pruebas se realizan y permiten verificar si el sistema cumple las especificaciones funcionales y si interacta correctamente con el entorno, incluyendo
interfaces con otros programas, recuperacin ante fallos, copias de seguridad,

Lacomparacindeperfilesdeusuariosyrecursosrequeridosconlosactuals'.i:
; estn aproba':'ri;
es realista y ros procedii"i::'..1r1:.f:::i:"^1lr-,".'';;;;

afectadas'

1l

'rlii

Se han evaluado los resultados de las pruebas y se han tomado las acciones
correctoras necesarias para solventar las incidencias encontradas, acfializndose el proyecto en consecuencia.

.l

cstn inclivirtualizados y
Los procedimientos de formacin
pfan de formacin que
a cadr o*un'io
persona, y se le ha comunicado
"i

sei.

lti;

r'

gu114.

los

Se han definido y preparado

cin (aulas, medios'auiovisualcs,

impartir la formaetcJt
los asistentes, tutoriales'

rcettLsr.rs rtcccsarios para

lurtr:rill pitra

r.,..

para el trabajo de Io|

recurstls lttittr.:ritlr.:s tlccesarios
los
definir
deben
Se
C-G1'.5:
ti
Se clehe cotttltt'oltltt tttc:
usuariOs cOn el nuevo Sistema.

ll
ti

tiempos de respuesta, etc.

se adaptan a cadan'

y los recursos necesarios para realizar

lro'1;

."rortu""rlrlrir"

il;;;i;t:tespnsables

C-H1-1: Se deben rcalizar las pruebas del sistema que se especificaron en el di-

oLosmanualesdeusuarioyelrestodeprocedimientoscumplenlosestndafesl
Yelrrv,vo'
de versiones'
control (rc
asociado su contror
',.:r
;;i;""
de1 rea y llevan asoclado

de 1as unidades

rot

los usuarios antes de ser puesto en explotacin.

"l

actuales d" 1":-:t:a"^t;.:""::t"?ff:tli:1os

C-G1-4: A partir de los perfiles
que:
,"*""i0, " personal necesarios. se debe comprobar

OyIATIVO DE CONTROL Hl: El sistema debe ser accptrckr lot'ttt:tltttctttr'

C-H1-2: El plan de implantacin y aceptacin se debe revisar para adaptarlo

situacin final del proyecto. Se debe comprobar que:
Se revisa el plan de implantacin

original y

a la

iI

se documenta adecuadamente.

Est incluida Ia instaiacin de todos los componentes desarrollados, as como

Ios elementos adicionales (libreras, utilidades, etc.).

1I

O RA-iUA

debe comprobar que:

Especificalosrecursosnecesariosparacadaactividad,ascomoqueelorden

.ar.uo para las actividades

es compatible'

.Schatenidoencuerrtalainformacinhistricasobreestimaciones.

Si el sistema antiguo se va

plotilcitin. Sc clebe comprobar que:

de anlisis' que"'i
aceptacin aprobado en la fase

explotacin'

informacin

se debe dejar

Los datos se convierten de acuerdo al procedimiento desarrollado y se verifica

la consistencia de 1a informacin entre el sistema nuevo y el antiguo.

I ii:
"i
,:i

por los usuanos'

Las pruebas de aceptacin sonrealizadas
1as pruebas
Se evalan ios resultados de

*f'"'t*

a mantenel para obtener

en explotacin en modo de slo consulta.

Se sigue el plan de pruebas de

y la
clebe incluir lu .oou"rr-" auto.

torts necesarias para

Hay un perodo de funcionamiento en paralelo de los dos sistemas, hasta que

el nuevo sistema est funcionando con todas las garantas. Esta situacin no
debe prolongarse ms tiempo del necesario.

(].tI1.3:Elsistemadebeseraceptadoporlosusuariosantesdeponefseenex-

l2: AUDtroRA DEL DESARRoLL] 291

C-H2-2: Si existe un sistema antiguo, el sistema nuevo se pondr en explotacin

de forma coordinada con la retirada del antiguo, migrando los datos si es necesario. Se

y la conversin si es necesana'
Incluye la inicializacin de datos

ceprulo

o RA'lt{A

2eo AUDIToRIiNronqlirtc:uNexl,oQu

se han tomado

las incidenciu'

C-}j2-3 Debe rmarse el final de la implantacin por parte de los usuarios.

las acciones coffecactualizndose

"n"onoudas'

'i

Se

debe comprobar que:

ffi

Existe el documento y que ha sido firmado por el comit de direccin y por el

grupo de usuarios.

,rt:r:iii

pr()yecto en consecuencia'
con las
y el comit de direccin firman su conformidad
Itri

lil

p,rrrpo dc usuarios

rr

rrt'lrlts tlc lccPtacin'

pondr en explotacin fomail

(rtl,tt':'t'tVO l)li CONTROL H2: El sistema se
aceptado y est prepa{
. ..:stir"",I*"."1*t"rto slo cuando haya sido
y

,r(..r(.

,rrsrrri
que se ejecutar'
rrrLr (otlo t:l cttttlrno cn el

C-l{2'l:

Se

cornprobar que:

C-H2-4: Se debe supervisar el trabajo de los usuarios con el nuevo sistema en las
primeras semanas para evitar situaciones de abandono de uso del sistema. Se debe
'ri

' .
"

Se ha comprobado, al menos informalmente, la impresin de los usuarios res-

pecto al nuevo sistema.

"it''

C-[{2-5: Para terminar el proyecto

Estn documentados de forma correcta'

se pondr en marcha

el mecanismo de mante-

nirlicnto. Se debe comprobar que:

necesaria y tienen en
11oder '*"',11,i
Los usuarios han recibido la formacin
manuales de
I'il
fundamentalmente
necesaria,
documentacin

usuano'

con
antiguos que sean incomPatibles
Se han eliminado procedimientos

nuevo sistema.

El ndice de utilizacin del sistema es adecuado a los volmenes que se esperaban para cada una de las ireas afectadas por el nuevo sistema.

rSehaninstaladoademsdelsistemaprincipaltodoslosprocedimientosaqti
tunto manuales como auto-'iii
,i, i
xiliares, po, .1"*piJ;;;''"top"'u"i'

tema.

1:

cOmprobar que:

de explotacin'
Se deben instalar todos los procedimientos

mticos.

Contiene de forma explcita Ia aceptacin de ia implarltacin colrecta del sis-

Hl ntscanismo existe y est aprobado por el director del proyecto, por el colrril tlc direccin y por el rea de mantenimiento, si sta existiese.

'l'icnr: cll cucntil los tiempos de respuesta mximos que

rrntc siturcirrncs do no fluncionamiento.

Se pueden

permitir

CAPTULO I2: AUDITORfADELDESARROLLO

293

O RA.MA

O RA.MA

\UDITORATNTO@

Controlinterno,auditorayseguricladinformdtica'Coopers&Lybrand'1996'

problema o para el mantenimiento

la persona
a seguir ante cualquier
procedimiento
Incluir al menos
El
="1t;;;t'
9"'t
etc'
del sistema t*u t;;tir"'
ta informacin a aportar'
de contacto,

t"lf";' ;;q;ina

H'
Auclitora en centros de cmputo'David

Li' Ed' Trillas'

1990'

I2.8.CUESTIONES DE REPASO

.6. CONCLUSIONES

'tr|:
Apesarae,seryll1gilXl;t:',Xtr;T:;;ii\li{i"ffi "':};'ff
y ssu difcil validadel software v
,oi*u." no ha conseryi9" "1:':^':::;:*iliJ.it*u'e
.":;;;'ilii'ut"'uesnecial

I,

de desarrollo?
a la importancia de la auditora
Qu factores contribuyen

2.

del rea de desadeben comprobar respecto a las funciones

Qu aspectos se

rroilo?

,orables. Este hecho'

Comentelaimportancia,desdeelpuntodevistadelaauditora,delafclrrtrir-

n,conriertenutp'o""'oJedesarrolloyttttl'*Jutizacinenlasclavesparacam-

rr la siruacin

de desarrollo'
cin que deben poseer los profesionales

,-j^.-.

t'
u*-''iill
tTTTi"*
pu"du pensar que Ia
r;H:Jl"'Tii:
:onli,Y:."::::Tff":
i"r"""t*". .*

que contlguran'
r odas las actividades
Todas

4.

Quprocedimientoutilizaraparavalorarlamotivacindelporstlttirltlctlc
sarrollo?

#:*,sl;f

programaclon' se
'n";;.i^,;",ut'o'uo"l.,1',,^T::"T*::::,J.hademostradoque"'"1"5'::.,11
'*r*lnn';"':i1x1l";i"Hllffi
que se p*d** *,i!*
,l}"ni:-,:X",'""i.:';"Tii
que los
i^j'ilu.-t*r:nunt", "t la proyectos son mas,;;;;,
ooLuvo
' ;,;
il,ruffit-i;i""'es de los

QurepercusionestienelaexistenciadeherramientasCASEcnclttthittl

5.

Je los mismos'
nal de

del desarrollo?

xlmu*:i

Porotraparte,nonargce.le1c:::::T3::,T'.:'"I::,1H,"ffi
p:ol:"t" u(JrrvrLrv' -" I rcin consolidada'
a 1o largo de :n
#:JT"':Ti:i::H[f
-ilJ::H
#,',#i,:Tt:1",J[':T.
," vors^^--ortwattr DU
eI seno (r., urro v!'F^--etr,
a cabo en fr
"rtunu.en
lleven
J". por
se
n"' ;'
"r,#.
t to"l
x en cuenta
u,,o
u:t-.T"]l:n
",
a
Ji tent
e
crtico
o :Ii
ro y e c ro s *

"#::IJffi
)

'oieIIo.

;'*,*:
::*: ;". "i.n

:i":::
en otro
convierre w'
la organizacin se convrErLe

rroyectos

iffh*:""ft

,ririi

ruditor.

d'l

de cuarta

ia ineenreria
.i";:L*;d;';""bj;;"'' lenguajes
illliTlll;ffi;i^'
auditora' "iri
en cierta medida :1 o:::-"^Tr::1tl.,o.ru,
u'r proceso
en un
enunproceso
rr
alterar *
Y--- de auditora'
al
;i";i"'*
'il
esenciales a estuurar
'n11^::#l:"::-'J:ff:t"",:Jl'i;,*.
elementos
ser
a
pasan
software'

-:-^!,nA
uuJv!r'""
olsullL,b
han expuesto
licarlos objetivos;r1
En este captulo se
Enestecapturosehan*n-1*'::l:Ht'.:-:H.t'Ji:,,i1,::XX'1*:1i':":
tuncin del provec'lo*
maneradebeninterp,J;#:#;;i:t:1ffi X,:%3"::::Hi'#XH;"1;,.+1,

XXH:i.:'l;:Jffiit"y
i:1il|#*;;':;;;o'
;ffiiu"* * cncla organizacin'

""

I t'J,ffi
12.7

.LECTUBAS RECOMENDADAS

Computer

Audit' Cttnlrol

tttttl '\ttttritv'

& Sons' 1989'

Mtrcllcr' R' John Wiley

.fnirlr]-clttuuditttt,tlli,t|(ll.ll'lll(.rl'Ytt.ttll)ct.rietr.Ed.Marcombo,l994.

6.DescribadiversosprocedimientosdeAnlisis,Evaluacinyseleccindeheo conozca'
rramientas de desarrollo quehayautilizado

7.

la subcontratacin del desarrollo?

Qu riesgos entraa

8.

en un proyecto a la
modelo de ciclo de vida que se adopte
Cmo afecta el
uditora atealizar sobre el mismo?

g.Creequela..trazabilidad,'delosrequisitosresultaimportanteenundesarrollo informtico?
l0.Expongacmodeberaserlaparticipacindelusuarioaiolargodelasdis.
tinias fses de la metodologa Mtrica'