4

408 AUDITORIA DE TECNOLOGIAS Y SISTBftAS DE INFQRMACION RA-MA

Segun esto, tan TS (Tecnico de Sistemas) era la persona especialista enHardware (Sistemas Fisicos) como el que se dedicaba al desarrollo de LenguajesFormales o Automatas (Informatica Fundamental) como el que trabajabaAplicaciones (Informatica de Gestion).

No obstante, la evotucion de la Informatica ha obligado a un grado deespecializacidn en que Comunicaciones, Sistemas Operatives, Seguridad y Basesde Datos ban necesitado expertos en areas muy concretas, dejando la figura de TSrelacionada exclusivamente con el Sistema Operativo, no sin habilitar,naturalmente, especialistas en Comunicaciones, Seguridad y Bases de Datos(administradores de esas actividades y/o entornos), Este grado de especializacionha sido necesario, sobre todo, en centros grandes en que las tareas se ban hechomas complejas y laboriosas, y en consecuencia, no desempehables por una unicapersona. En ocasiones la necesidad de administrar con rigor determinadasinstalaciones ha llegado incluso a crear departamentos con las personas quecolaboran en la realization del trabajo correspondiente a la funcion concreta.

La Microinformatica y las Redes ban generado unos nuevos entornos detrabajo, en algunos casos unices (emprcsas mas pequenas) y en otros mezcladoscon los convencionales, pero que requieren de una preparation y dedicationespecificas. En este sentido oimos bablar cada dia (incluso en anuncios de prensa)de TS de Microinformatica o TS de Redes.

Parece pues que no es facil detenninar el imbito de la tarea de TS, peronuestro compromiso con lo que queremos escribir nos obliga a acotar con claridadla materia en cuestion, para poder establecer despues las correspondientesactividades de control.

Tratando de utilizar el sentido comun y la praxis habitual determinariamoscomo ambito de la tarea de TS la infraestructura informatica, es decir, el conjuntode instalaciones, equipos de proceso y e! llamado software de base. Vamos apuntualizar lo que, segun mi criterio, debe incorporar cada uno de estos apartados.

Instalaciones Este apartado incluiria salas de proceso, con sus sistemas de seguridad y

control, asf como elementos de conexibn y cableado, es decir, los elementos basepara acondicionar los componentes del apartado siguiente.

RA-MA CAPiTULO 14. AUDITORIA DE TECNICA DE SISTEMAS 409

Equipos de proceso

Aqui estarian los ordenadores (main, mini y micro), asi como susperifericos (pantallas, impresoras, unidades de cinta...), los dispositivos deconmutacion y comunicaciones (routers, modems, switches...), los componentesespecializados en integration (como telefonia IP, tratamiento de llamadas...) y loselementos especificos de seguridad (Firewall, IDS, IPS...).

Software de Base

Se compone de los Sistemas Operatives, Compiladores, Traductores eInterpretes de comandos y programas, junto con los Gestores de Datos (o sistemasde administration de Bases de Datos) y toda una serie de herramientas ycomponentes auxiliares e intermedios (herramientas de desarrollo, facilidades deexplotacion como planificadores, paquetes de seguridad, middleware...).

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

No obstante, dado que existen cn esta publicacidn capitulos especificosdedicados a Auditoria Fisica, de la Explotacion, de Bases de Datos, de la Seguridady de las Redes, intentaremos centrarnos en el apartado del Sistema Operativo y lasComunicaciones, como aspectos no cubiertos en los apartados mencionados.

14.2 DEFINICION DE LA FUNCIONParece que antes de entrar en la Auditoria de Tecnica de Sistemas,

deberiamos definir primero la tarea a auditar como una actividad informatica querequiere un determinado desempeno profesional para cumplir unos objetivosprecisos.

Siguiendo este esquema y buscando un enunciado simple podemos decirque Tecnica de Sistemas consiste en la actividad a desempeftar para instalar ymantener en adecuado orden de utilizacion la infraestructura informatica.

Todo de acuerdo con lo ya comentado en el apartado anterior -en cuanto aambito- y buscando un compromiso formal para separar las Aplicaciones de todo lonecesario para que estas fimcionen correetamente.

Profundizando en esto diriamos que el funcionamiento correcto se

caracterizaria por:

4!0 AUDITORIA DE TECNOlOGiAS YSISTEMAS PH 1NFQRMACION RA-MA

* Disponer de fodos los elementos necesarios

For parte de los usuarios autorizados

* En el momento requerido

* Con el rendimiento adecuado

* 14.3 EL NIVEL BE SERVICIO!

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^ expresa en terminos de nive! de servjcio. Toda nuestra actividad deberia estar

fundam.entada en ei logro de ese objetivo y, tanto los procedimientos de actuacion,como los correspondientes controles, deberian tener como fin ultimo dicha meta.

' Entendemos por nivel de servjcio una serie de parametros cuya medicion) es capaz de determinar objetivamente ei mayor 6 manor grado de eficacia del

servicio prestado. No cabe duda de que la obtencion de dicho nivel se ve afectada* por cuantas incidencias, de cualquier tipo, impacten en el normal desenvolvimiento) de la actividad de! SI. Ast, paradas por instalacion de nuevos drspositivos, cambios

de versiones del sistema operativo, puesta en servicio de nuevas herramientas,averias de maquina, fallos de corriente o elementos de acondicionamiento,! arranque o modificacidn de enlaces de comunicaciones, inclusion de nuevos

( usuarios o cualquier tipo de problema con el hardware o el software puede' degradar el servicio, con el consiguienie perjuicio para ia organizaeidn, que no1 podra desarrollar sus funciones adecuadamcnte o en el tiempo preciso, con el

correspondiente impacto economico que esto supone y que, generalmente, resultara; dificil de calcular, pero, en cualquier caso, importante.

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\ de la configuracion. Bastaria decir que sin los clientes del SI no tiene sentido el SI.

Y lo que tales clientes necesitan es la garantia de que el SI cumple su funcidnadecuadamcnte, puesto que, cada vez mas, es el fundamento de toda la actividad de, la organizacion.

Digamos para terminar esta breve incursion en el concepto expuesto que lagarantia del funcionamiento global se obtiene primero consiguiendo la de cada unode sus elementos, lo que nos obliga a determinar los pantos criticos que afecten a laactividad del SI y a prever su fallo y planificar los controles y acciones

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

correspondientes para soslayarlo. Comprcnderemos que es tan importante detectarla anomah'a en un elemento de hardware como la capacidad de subsanarla entiempo utif, para lo que deberemos disponer del correspondiente contrato deasistencia con un proveedor que nos permita reducir, a lo previsto, el impacto portiempo de inactividad. Debe anadirse que, con esta filosofia, se negocian con losusuarios y proveedores que reciben el servicio o aportan actividades para suconsecucion acuerdos de nivel de servicio (SLA: Service Level Agreement) que,por un lado, aseguran a nuestros clientes el grado de eficacia negociado y exige anuestros proveedores la asistencia requerida para conseguir lo anterior. Hay queentender que, en estos terminos, se habla comunmente de disponibilidades porencima del 99,9% (segun sectores y grado de criticidad de los SI con relacion alimpacto en la organizacion) lo que nos llevaiia a no tener interrupciones durantemas de 2 horas en total en un ano para un servicio estimado en 2.000 horas anuales.Vease que un total de 10 horas de parada en un ano para ese mismo serviciosupondria una disponibilidad del 99,5%.

La disponibilidad, siendo fundamental, no es el unico parametro a medir,toda vez que no se trata de tener un sistema que responde durante un determinadonumero de horas ai ano, porque ademas, debe hacerlo bien. Este ultimo aspectosolo puede comprobarse mediante tiempos de respuesta que den una medida de lautilidad del servicio.

La satisfaction de los usuarios es fruto del resultado general del servicio ydepende tanto de la eficacia de las aplicaciones como de la eficiencia del sistema.Este ultimo aspecto esta bien representado por los parametros de disponibilidad ytiempo de respuesta, pero se completa con el anaJisis de las incidencias originadaspor la infraestructura y las opiniones de los usuarios sobre el servicio, en la partecorrespondiente a ese mismo componente.

14.4 LOS PROCEDIMIJENTOSToda tarea organizada debe estar descompuesta en una serie de actividades

o acciones a realizar con unos procedimientos especificos que garanticen su calidad(o correcto funcionamiento).

De la orientacidn que hemos dado hacia el servicio se deduce ia tares deadministration de los recursos del SI (infraestructura), que debe pptimizar losparametros antes mencionados, cuestidn que ha de convertirse en el objetivo denuestros procedimientos.

Podemos efectuar una clasificacion en:

412 AUDlTORiA DE TECNOLOGiAS Y S1STEMAS DE INFORMACION RA-MA

1. Instalaeion y puesta en servicio

2. Mantenimiento y soporte

X Requisites para otros componentes

4. Resolution de Incidencias

5. Seguridad y Control "

6. Information sobre la actividad

La clasrficacidn anterior sin'e para cualquier elemento de infraestructura,pero como ejemplo, podemos pensar en e! Sistema Operative de una maquina. .

INSTALACIQN Y PUESTA EN SERVICIO

Comprenderia tod as las actividades para conseguir el funcionamientoadecuado del elemento en cuestion:

Planificacibn. Procedimiento general de! suministrador adaptado a lainstalaeion concreta.

Documentation. Inventario de componentes del elemento y normas deactualization.

Parametrizacion. Valores de parametros del sistema en funcion delresto de elementos planificados (numero y tipos de usuarios,aplicaciones...).

Pruebas. Verificaciones a realizar y sus resultados.

Debe partirse de los documentos existentes en la organization sobrenormativa general: estructura organizativa (especialmente informatica), normativasde instalaeion (como per ejemplo direcciones IP a utilizar), metodologia general deproyectos y demas informaciones que puedan y deban condicionar la instalaeion(criterios de securizacion de aplicaciones criticas que requieren garantia deservicio: cluster, mecanismos y comprobacion de back-up...).

MANTENIMIENTO Y SOPORTE

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

RA-MA CAPITULO 14. AUDlTORiA DE TECNiCA DE S1STEMAS 4 i3

dia y la asistencia a prestar a otros colectivos (desarrolladores, por ejemplo) parafacilitar information necesaria sobre el sistema y sus herramientas para su raejorutilization.

Pianificacion. Control del periodo de garantia y comienzo delmantenimiento del elemento.

Documentacion. Procedimiento para contactar con el soporte.

Parametrizacidn. Adaptacion de los parametros del sistema. En funcionde nuevos rcquerimientos o como resultado de nuevas versiones oresoiucion de incidencias (incluiria aplicacion de parches yactualizacion de nuevas versiones de software).

Pruebas. Verificaciones de los cambios o adaptaciones realizadas.

REOUIS1TOS PARA OTROS COMPONENTES

Procedimiento de requerimientos o recomendaciones para el mejorcomportamiento de otros componentes del SI.

Pianificacion. Considerar los requisitos cruzados de unos elementospara con otros, por ejemplo: considerar el espacio en disco necesariapara una nueva instancia de una base de datos y, por ende, el impactoen el subsistema de discos y las consccuencias en los back-up en cuantoa espacio requerido y tiempo necesario (ventana de back-up que puedelimitar el tiempo de servicio a usuarios), teniendo en cuenta laslimitaciones que en cuaiquiera de estos aspectos pudieran existir.

Documentacion. Procedimiento que determina los efectos a consideraren otros componentes.

Parametrizacion, Adaptacion de los parametros del sistema en funcionde nuevos requerimientos o como resultado de nuevas versiones oresoiucion de incidencias.

Pruebas. Verificaciones de los cambios o adaptaciones realizadas.

414 AUDITORJA DE TECNOLOGIAS Y SISTEMAS DK INFGRMAClON RA-MA

RESOLUCION DP; INCIDENCIAS

Procedimiento para registrar, analizar, diagnosticar, calificar y seguir lasincidencias que se produzcan, en relacion con el elemento en cuestion con elobjetivo tie su resolucion.

Registrar. Supone abrir un formulario en el medio habiiitado (papel,electronicu...) que permita recoger los datos que identifican la, anomaHa: momenta en que se produjo, elementos y servicios/usuarios

aFectados, danos producidos y/o que pueden producirse, entomo del1 problems y una description de lo acaecido (las opiniones de los> observadores pueden resultar de interes en algunos casos).

Analizar. Supone buscar una relacion entre etecto y sus posibies causas,. para lo que se cuenta, ademas de con los cornentarios de los

observadores ya mencionados, con la experiencia de! tecnico que trata> ia incidencia y la tnformacion ya registrada sobre otras incidenciasj producidas que pudieran estar relacionadas o responder a la misma o

parecida causa que esta., i1 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, establecer una causa del fenomeno reportar al soporte disponibie para

! su diagnostico.: ) '

, Calificar. Es un dato importante en el enfoque de la resolucibn, pues no! tiene el mismo tratamiento una anomaHa bloqueante que afecta a iodoI J un sistema que un error que se produce de forma muy espoxadica y susi , efectos no son muy prpbtematicos.

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 de disponer de la solucidn, su aplicacion, / debera atenerse a los criterios de nivel de servicio, evaluando la

problematica creada por la faita de solucidn y la que pueda crear la' resolucion, para coordinar las acciones que menos perjudiquen eli servicio global en curso. Supdngase e! caso de un problema que sdio

puede solucionarse mediante un "parche" de software que solo puede: ' instalarse parando una maquina que controla un proceso critico1 ; (iroagmese cualquier ejemplo en: hospital, banco, produccion de! fabrica...). .

O RA-MA CAPiTULQ 14. AUDiTORiA DE TECNICA DE SISTEMAS 415

Seguimiento. Es la accion continua y normalizada para conseguir eldiagnostico de una incidencia y la persecucion de su resolucion.

SEGURIPAD Y CONTROL

Estos procedimientos adquieren una especial relevancia en e! proceso deevitacion de incidencias y, en caso de producirse, en su temprana deteccion.

La proteccidn debe considerar tanto la posibiiidad de hechos fortuitoscomo malintencionados. Los primeros se evitaran partiendo de una formacionadecuada y competencia profesional mas la organizacion que establezca unosprocedimicntos robustos que inciuyan elementos de control". Los hechosmalintencionados se prevendran mediante una politics de personal adecuada, unosprocedimientos que eviten concentracion de (areas y consideren la segregacidn defunciones y ios correspondientes controles.

Adquiere una relevancia especial el control de Transportes. Se entiende portransporte el proceso que toma un nuevo objeto, la modificacion o eliminacion deun objeto existente en un entorno para su puesta en produccion en otro. En esteproceso se consideran:

Objeto: piezas de cbdigo (programas), de datos (tablas de configuraciono datos basicos).

Entomo: espacio de trabajo, como pOT ejemplo:

o Desarrollo: programacion y pruebas de nuevas funciones oadaptaciones.

o Integracion: pruebas de consistencia de nuevas funciones conexistentes.

o Formacion: equipos para entrenamiento de usuarios.

o Produccion: sistema dedicado a transacciones de negocio.

Responsable de transportes: normalmente el Director o Responsabledel Proyecto y en cuaiquier caso una persona diferente del que realizael nuevo desarrollo o la modificacion.

4!6 AUDITOR!A PS TECNOLOGlAS Y SISTEMAS DE INFORMACION SRA-MA

Es necesario proteger los accesos a informacion y funciones con criterio demmimos reservando funciones y accesos especiales a niveles de responsabilidadsuperiores con los controles adecuados.

Por poner ejemplos, diremos que personal de desarrollo no debe teneracceso a modificar parametros del sistema operative y, de igual forma, los T3 nodeben poder modificar programas.

Uno de los controles tipicos en cuanto a los programas objeto o compiladosen explotacion es el que comprueba que dichos objetos se corresponden con lasversiones fuente en vigor. Un control de este tipo tambien detecta aquellos objetosque no disponen de su correspondiente programa fuente.

Los entornos de desarrollo y mantenimiento de programas deben dejarinformacion sobre las sentencias borradas, modificadas y anadidas, asi como losautores de las modificaciones. Estas pistas de auditoria permiten realizarinvestigaciones para determinar el origen de un determinado cambio.

Es importante que existan una serie de normativas para realizar lasfunciones informaticas, aunque es igual de importante que tales normas secumplan.

INFORMACION SOBRE LA ACTIVIDAD

Forma parte de ia esencia de cualquier actividad rendir cuentas alresponsable superior del trabajo realizado. Dispones- de una informacionestructurada, de acuerdo con los parametros de seguimiento mas acordes con losobjetivos de desempeflo, es cuestidn primordial para:

Conocer la evolution de la actividad

Comparar la realidad con objetivos y estandares

Mejorar la calidad de la tarea

Anticiparse a situaciones criticas analizando las tendenciasEs uno de los elementos basicos del nivel de servicio, sicmpre que se

objetiven parametros para su seguimiento, es decir, seamos capaces de medircomportamientos de! sistema que esten directamente ligados con la calidad delservicio.

RA-MA CAPiTULO 14. AUDITORIA DE TECN1CA DE SISTEMAS 417

La informacion debe servir para gestionar y, por tanto, debe ser resumida yrepresentativa de la realidad, permitiendo profundizar si se requiere un analisis masfmo de algun parametro, en aras de localizar la causa de un determinadocomportamiento o magnitud.

14.5 LOS CONTROLESDeberian determinar el comportamiento del sistema y prevenir situaciones

no deseadas desde cualquier punto de vista: .

Hardware.

o Existen los componentes adquiridos (inventario)

o Estan correctamente instalados

o Se mantienen adecuadamente

o Dan el rendimiento requerido

Software,

o

o

o

Se dispone de las correspondientes licencias

Esta correctamente instalado

Se mantiene adecuadamente (versiones oficialmentesoportadas)

a Dan el rendimiento adecuado

Comunicaciones.o Existen componentes

Conmutacion.

o Estan correctamente instalados

q Se mantienen adecuadamente

o Dan el rendimiento adecuado

AUPITORIA OE TECNOLOgiAS Y SfSTEMAS DE INFORMACION RA-MA

Comumcaciones.o Existen los contratos o servicios

Enlaces.

o Esran correctamente parametrizados

o Se mantienen adecuadamente

o Dan el ancho de banda y respuesta necesarios

Seguridad.

o Existen los procedimientos

o Se Uevan a cabo

o Se controlan las excepciones

o Se toman inedidas

Informacton.

o Se dispone de procedimientos de back-up

o Se realizan los back-up correspondientes

o Se guardan adecuadamente

o Se comprueban por muestreo

Plan de Contingencias.

o Estan contratados los servicios necesarios

o Esta debidamente actualizado

o Se realizan los ensaybs periodicos

RA-MACAPI'TULG 14. AUOITORiA DE TKCNlCA DE SiSTEMAS 4!9

La Asociacion para la Auditoria y e) Control de los Sistemas deInformacion (ISACA) otorga las certificaciones:

C1SA. Certified Information System Auditor

C1SM. Certified Information Security Manager

IT Governance CertificationEn 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 agestionar la evolucion del Modelo COBIT (Control Objectives & IT related). Alii serelacionan los procesos de ios Sistemas de Informacion, clasificados en dominios:Organization y PJanificacion, Compras e Implantation, Puesta en Servicio ySoporte y, por ultimo, Monitorizaeion. Estos procesos engloban todas lasactividades relacionadas con ios Sistemas de Informacion y, a su vez, con factorescomo: Personas, Aplicaciones, Tecnologia, Explotacion y Datos. Por otra partetienen una conexion mayor o menor con siete Criterios de Informacion:

1. Eficacia

2. Eficiencia

3. Confidencialidad

4. Integridad

6. Cumpiimiento riormativo (legalidad vigente y regulation interna)

7. Fiabilidad

La definition del factor Tecnologia puede identificarse con el ambito queestamos aplicando a Ticnica de Sistemas, puesto que comprende:

1. Hardware

2. Sistemas Operatives

3. Gestures de Bases de Datos

4. Redes,

420 AODITORlAPE'I'ECN'OLOGiAS Y SISTEMAS DEINFORMACION RA-MA

5. Multimedia,

Extrayendo los procesos relacionados con esta definicion de Tecnologiaobtendriamos, segun ISACA, los objetivos de control coTrespondientes al aTea quenos ocupa: Tecnica de Sistemas.

Existen cuatro grupos para los 34 procesos que ISACA identifica y que seagrupan en 4 apartados:

PO 10 procesos de Planificacidn y Organization AI 7 procesos relacionados con Adquisiciones e Instalacion de

recursos de SI

DS 13 procesos de Entrega y Soporte (Deliver & Support) de Servicios

ME4 procesos de monitorizacion y Evaluation de los SI

Veamos los objetivos de control en los que se invoiucra la Tecnica deSistemas, seg&n el concepto anterior y el criterio del autor (se incluye la refereneiay description del proceso en COBiT 4.1).

POl - Definicibn del plan estratgico de TI

Pretende la satisfaction de los requerimientos del negocio, buscando unbalance optima entre las oportunidades de la tecnologia de la information, dichosrequerimientos y su posterior cumplimiento. Permite un proceso de planificacionestrategica que, a intervalos regulares, va cumpliendo los planes a largo plazo.Estos planes a largo plazo deben traducirse periodicamente en planes operativoscon objetivos claros y concretes a corto plazo.

Toma en consideracidn objetivos de negocio y necesidades de tecnologiade la informacidn, inventario de solutiones tscnologicas e Infraestructura actual yestudios de factibilidad.

Primaivdo fundamerdalmente el criterio de eficacia, concede tambknimportancia a la eficiencia.

RA-MA CAPITULO 14. AUDlTORiA OK TECNICA DE SISTEMAS 421

P03 - Determination de la direcci6n tecnologka

Se trata de obtener ventajas de las tecnologias emergentes. Pretende crear ymantener un plan de infraestructura tecnoiogica, adecuando y haciendo evolucionarla capacidad de la infraestructura actual, siguiendo los desarrollos tecnologicos, lasrestricciones del negocio y los planes de adquisicion.

incluye el establecimiento de estandares y criterios de unificacion de

plataformas.

Se deben equilibrar eficacia y eficiencia (normalization y simplification).

P05 - Administrar las inversiones cn TI

Asegura la disposition y el control de desemboisos de recursos financieros,por medio de los correspondientes presupueslos operativos periodieos establecidosy convenientemente aprobados.

Tiene en cuenta altemativas de financiacion, control sobre lo gastado yjustification de costes.

En este proceso son igual de importantes eficacia y eficiencia,considerandose, ademas, la fjabilidad de lo adquirido.

P08 - Administrar la calidad

Considera el nivel de servicio a prestar en cada caso (sistema o aplicacion).

Lo estandares de servicio deben considerar la criticidad y el impacto en e!negocio de cada uno de ellos. Veamos una clasificacion con un ejemplo de cadaagrupaeion:

Front-office- Servicios orientados a mercado y clientes (maximaprioridad: e-business).

Back-office. Operaciones intemas (importantes pero con menor nivelde criticidad: nomina).

Servicios base: Infraestructuras (requerimiento de robustez yfiabilidad: comunicaciones).

Los niveles de servicio de los Seivicios de Base deberan permitir que elFront-office y el Back-office puedan cumplir sus propios estandares. En casos de

422 AUDiTORiA DE TECNOLOOlAS Y SiSlfcMAS DE INFORMACION RA-MA

external izacion (outsourcing de servicios de base, nonnalmente) la negotiation detales parametros (incluyendo las penalizaciones por incumpiimiento) son clave ene! funcionamiento de las sistemas.

La Administration de la Calidad busca fundamerrtalmente la eficacia.

P09 - Evalaar y administrar riesgos de TI

Pxetende el asegurami'ento de la obtencion de los objetivos de TI(tecnologia de la information), previniendo a las amenazas en la obtencion de losservicios de TI. Permits a la organization identificar los riesgos, analizar suimpacto y tomar las medidas de coste efectivo para mitigarlos.

Considers distintos tipo de riesgos (tecnologia, seguridad, continuidad...),los momentos de analisis (periodicos o durante la implantation de nuevossistemas), ambitos giobales o especificos, informes de incidencias y elmantenimiento de un modelo de riesgo.

Estan involucrados los siete criterios, pero especialmente:confidencialidad, integridad y disponibilidad.

Supone marcar prioridades para conseguir objetivos en tiempo, dentro delos presupuestos. Permite a la organization identificar y priorizar proyectos enImea con el plan operativo. Mis aun, la organization debe adoptar y aplicartecnicas seguras de gestion de proyectos para cada proyecto emprendido.

Es preciso tener en cuenta eJ promoter del proyecto, los usuariosinvolucrados, las incidencias y los hitos, la determination de tesponsahilidades, elcomite de seguimiento, los presupuestos de costes y mano de obra, la calidad delplan y la segur.dad del plan para con los sistemas sensibles.

Results fundamental la participation de las Areas de Infraestructuras ytad en la planificacion y puesta en marcha de nuevos proyectos, a efectosdel cumplimiento de politicas y estandares y el aseguramiento del minirno impactoen los SI.

En esle caso intervienen por igual los criterios de eficacia y eficiencia.

O RA-MA CAPiTUE.O 14. AUDiTORiA DE TfeCNtCA DE SISTEMAS 423

All - Identification de soluciones automatizadas

Se trata de asegurar la mejor aproximacidn para satisfacer losrequerimientos de los usuarios, facilitando un analisis claro de las oportunasalternativas ajustadas a los requisites.

Se ban de tomar en consideration las restricciones intemas y extemas(como sistemas heredados), ia direction de la tecnologia, los estudios defactibilidad (costes, beneficios, alternativas...), los requerimientos y la arquitecturade informacion.

Prevalece la eficacia, aunque la eficiencia debe considcrarse tambien.

AI3 - Adqtiisicion y mantenimiento de infraestructura tecnologica

Este proceso provee las plataformas adecuadas para soportar lasaplicaciones del negocio. Permite defmir consideraciones especificas derequerimientos funcionales y operativos y una implantation por fases con hitosclaros.

Se deben considerar: la disponibilidad de la tecnologia, la direction de suevolution, las politicas de seguridad, el ajuste de los procedimientos a lainstalacion y la flexibitidad.

Deben prevalecer los estandares (regulation o normativa interna)considerando eficacia y eficiencia.

A14 - Facilitar las operaciones y el uso de los SI

Pretende asegurar el uso adecuado de las aplicaciones y de las solucionestecnologicas instaladas. Supone una aproximacion estructurada al desarrollo delusuario y a los manuales de procedimientos operativos, asi como a requerimientosde servicio y material de entrenamiento.

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

Prevaleciendo eficacia y eficiencia, tambien -en segundo tdrmino-intervienen criterios de integridad, cumplimiento normativo y fiabilidad.

AI5 - Adquisicldn de recursos de IT

Asegurar la integration con la infraestructura existente.

424 AUDiTQRlA DE TF.CNOLOGIAS Y SISTEMAS DE [NFORMACION RA-MA

Considera el soporte y mamenimiento adecuado por parte delsuministrador para poder garantizar el mamenimiento de la operativa global del SI.

Busca la integridad y la disponibilidad, prevaleciendo la eficacia.

AI6 - Gestidn de cambios

Pretend mimmizar disfunciones, alteraciones no autorizadas y errores,habilitando la gestion de! sistema para el analisis, la implantacion y el seguimientode los cambios solicitados y realizados en la infraestructura de Tl existente.

Tiene en cuenta la identificacion de los cambios, la categorizacion,priorizacion y procedimientos de emergencia, e! impacto, la autorizacion de loscambios, gestion delegada y distribucion de software.

Asegura que todos los afectados conocen las nuevas ftmcionalidades,cambios en la operativa de los sistemas y su impacto.

Considera la comunicacion, formacion y entrenamiento adecuado de todoslos participantes (tecnicos para el soporte y usuarios para su adecuada utilizacion).

Busca la integridad y la disponibilidad, prevaleciendo la eficacia.

A17 - Instalacion y certificacion de sistemas

Verifica y confirma que la solucion encaja con el proposito perseguido, loque permite la realizacion de una correctamente formalizada instalacion,migracion, conversion y un plan de aceptacion.

Considera la aprobacion de la estructura, la documentation, pruebasespecificas, entrenamiento, conversion y/o carga de datos y revisiones post-implantation.

Busca la integridad y la disponibilidad, prevaleciendo ia eficacia.

DSl - Definicidn y gestidn de niveles de servicioPersigue un entendimiento general izado sobre el nivel de servicio

requerido, Permite el establecimiento de acuerdos de nivel de servicio queformalizan los enterics de rendimiento con los que deben medirse cantidad ycalidad del servicio.

RA-MA CAPiTULO 14. AUD1TOR1A DE TECNiCA DE SISTEMAS 42S

Involucra definition de responsabilidades, volumenes y tiempos derespuesta, dependencies, cargas, garantias de integridad, penalizaciones porincumplimientos y acuerdos de discrecion.

Intervienen ios siete criterios, siendo primarios; eficacia y eficiencia.

DS2 - Gestion de servicios de terceros

Aseguran que los roles y responsabilidades de terceras partes estandefinidos con claridad, son conformes con los requerimientos y continuansatisfaciendolos. Facilitan medidas de control para revisar y monitorizar loscontratos existentes y los procedimientos para su eficacia y cumplimiento de laspoHticas de la orgariizacion.

Tiene que ver con los acuerdos de nivel de servicio, con los acuerdos dediscrecion, las poHticas de la compafiia, las Seyes y regulaciones y los contratos deoutsourcing.

Igual que el proceso anterior, requiere de todos los criterios y, en especial,de eficacia y eficiencia.

DS3 - Gestion de rendimiento y capacidad

Asegura la existencia de la capacidad adecuada, su disponibilidad y usodptimos de acuerdo con los requerimientos establecidos. Permite controles paragestionar la capacidad y el rendimiento que recopilan datos e informan paragestionar la carga, el tamano de las aplicaciones y la gestion de recursos ypeticiones.

Tiene en cuenta volumenes, tiempos de respuesta y rendimientos.

Busca el factor de disponibilidad, prevaleciendo siernpre eficacia yeficiencia.

DS4 - Aseguramiento de la continuidad del servicio

Dispone el servicio tal y como se requiere y continua facilitandoio cuandose produce una incidencia. Permite el ejercicio regular de un plan de contingenciaestructurado (simulacros) facilrtando distintas fases e hitos claros, alineando las TIcon los aspectos del negocio.

Considera la clasificacion critica, e! plan documentado, los procedimientosalternativos y las pruebas y ensayos sistematicos y regulares.

426 AUDfTOfUA DE TECNOLOGIAS YSiSTKMAS DJ- INFORMACION SRA-MA

Se fundamenta en dtsponibilidad y eficacia y, de manera secundaria, eneficiencia.

DS5 - Aseguramiento de la seguridad de Jos sistemas

, Para salvaguardar la informacion contra usos no autorizados, Tevelacion deinformacion, modificacion, corrupcion o perdida, controla el acceso logico al '

CAPAARQUITECT6NICA

SEVERIDAD COSTE i 1 iTULO )8. AUDlTORtiA DF. ARUCACiOKES 565

corroborar los resultados. Como resultado se presentar un informe final en el quese expongan las conclusiones mas importantes a las que se ha llegado. (Vease en latabla 18.4).

18.6 RECOMENDACIONES Y BUENAS PRACTICASA modo de conclusion final, de buenas practicas o recomendaciones que en

nuestra experiencia son importantes a la hora de realizar la auditoria de unaaplicacion software:

Utilizar metricas y factores cuantitativos obtenidos de la aplicacion es degran ayuda, aportando ademas argumentos solidos para concienciar sobreel estado de la aplicacion.

La pcriodicidad con la que se pretenda realizar las auditorias de laaplicacion en muchas ocasioncs vendrd determinada por la complcjidad delrnetodo e infraestructura disponible para medir la calidad de la aplicacion.Si es muy costoso obtener datos sobre el estado de la aplicacion laperiodicidad disminuira, de ahi la irnportancia de automatizar al maximodicha recogida de datos para la auditoria.

Con una buena infraestructura para la automatization de la obtencion dedatos para las auditorias hay que tener presente que es facil caer en elproblema de recopilar un excesivo volumen de informacion y no saber quehacer con ella, por lo que es muy importante tener claro los objetivos yalcance que persiguen las auditorias.

En cada auditoria es importante definir que informacion mostrar, cuando ya quidn, segun el nivel de abstraccidn e informacion que se requiera encada situation. Esto implicard que la mayoria de las ocasioncs existanvarios informes finales resultantes de la auditoria.

Para ciertas organizaciones en muchas ocasiones, bien por la complejidadde las auditorias, por su periodicidad, etc., lo mas conveniente esexternalizar ia actividad de audi tar la aplicacion a empresas especiaiizadas.Tambien frecuentemente se recurre a esta option para buscar un actorextemo que otorgue mas objetividad a la auditoria.

Y por ultimo que nunca se debe perder de vista el objetivo final de !aauditoria, que sera, por ejemplo, alinear objetivos de negocio con planes de mejora,increraentar la productividad y rentabilidad del desarrollo, aumer.tar la calidad del

568 AUDITORJA DE TECNOLOGiAS Y SiSTEMAS DE iNFORMACION RA-MA

NIST. (2002). Planning Report 02-3. The Economic Impacts of InadequateInfrastructure for Software Testing-. National Institute of Standards & Technology.Program Office Strategic Planning and Economic Analysis Group.

Piattini, M., Garcia, F., Garzas, J., St Genera, M. (Eds.). (2008). Mediciony estimacion del software: tecnicas y metodos para mejorar la calidad yproductividad del software, Ra-Ma.

Simhan, R. T. E. (2006). IBM Tops list of global outsourcing Companies.The Hindu Business Linewww.thehindubusinessline.eom/2006/05/26/stories/2006052602760400.htm.

Standish. (2001). Extreme CHAOS D. Standish Group International. Enhttp://www.standishgroup.eom/sample__research/PDFpages/extreme_chao.s.pdf(ultimo acceso en abril de 2006).

18.10 CUESTIONES DE REPASO1. ^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 empresasque han exteraalizado el desarrollo de su software?

3. iQue tres tipos de aspectos se suelen distinguir en la calidad de unaaplicacion?

4. i,Que caracteristicas del modelo de McCall aplicaria a la hora deauditar el rendimiento de una aplicacion?

5. En el caso anterior, ^qu6 alcance, en base a la norma ISO 9126, daria ala auditoria y que metodo utilizaria?

6. COBIT 4.1 se estructura en cuatro dominios de actividad. ^Cual deellos 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)

RA-MA CAPITULO 18. AUD1TORUA DE APL1CACIQNES 569

- Monitorizar y evaluar (ME, Monitor and Evaluate )

7. ^Que beneficios da realizar las mediciones de manera periodica yfrecuente?

8. ^Por que es necesario definir diferentes niveles de abstraccion enmedicion?

9. (,Por que crees que benefic-ia disponer de un entorno automatizado paraapoyar las auditorias de aplicacidn?

10. i,Que objetivo final debe guiar una auditoria. de aplicacion?

Capitulo 19

DESARROLLOY MANTENLMIENTO DESISTEMASINFORMATICOS

Daniel Mellado

Mario Piattini

19.1 INTRODUCCIONLa necesidad de que una organization cuente con procedimiento de control

intemo es aceptada ampliamente como garantia de una gestidn eficaz orientada a laconsecution de objetivos marcados. La fiincion auditora es precisamente laencargada de comprobar la existencia de estos procedimientos de control y deveriflcar su correcta dcflnicidn y aplicacidn, determinando las deficiencias queexistan al respecto y ios riesgos asociados a estas carencias de control.

Una de las areas que tradicionalmente aparecc en el departamento deinformatica es la de desarrollo o desarrollo y mantenimiento. Esta fiincion abarcatodas las fases que se deben seguir desde que aparece la necesidad de disponer deun SI hasta que este es constmido, implantado y entra en mantenimiento. Paradelimitar el ambito de este tema sobre auditoria del desarrollo y mantenimiento, seentendera que estos incluyen todo el ciclo de vida del software excepto laexplotacion y la retirada de servicio de las aplicaciones.

El desatTolIo y mantenimiento de sistema.s es un proceso costoso que debeser controlado adecuadamente. Por este motivo, el auditor informatico deberia ser

572 AUBlTORiA DE TECNOLOGIAS V SISTEMAS DE INFORMACION RA-MA

tenido en cuenta en el diseno y construction de controles en los sistemas. Ademasel auditor asesorara a la Direction y a los integrantes del area de desarrolloinvolucrados en el nuevo SI, sobre la convenlencia de determinados controles y \apeor adecuacion de otros. De forma general, las tareas del auditor cuando realiceuna revision en esta area seran: comprender adecuadamente y evaluar lametodologi'a seguida en el desarrollo del SI, identificar las fases de dichametodologfa, evaluar la adecuacion entre el proceso de desarrollo de aplicaciones ylos objetivos de la organization, revisar el cumpiimiento de estandares y norm as decontrol intemo en el desarrollo de aplicaciones y determinar si se cumplen lasnormas 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 (sistemaoperative, software empotrado, software de comunicaciones, etc.), lascaracteristicas de la organization, la metodoiogsa que use de forma estandar, lapoHtica de adquisicion de software o desarrollo a medida, y otros muchos factores,dcsarrollados con ampiitud en ingenicri'a de los Sistemas de Information del-presente 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 elcontrol de cada proyecto variara fundamentalmente si se elige una solution adesarrollar o adquirida, si podemos apuntar una serie de objetivos de control que elauditor tendra en cuenta en las distintas etapas, que de forma general, pasa un SI.

19.2 PLANTEAMIENTO Y METODOLOGIABxisten 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 ahardware.

El software como producto es muy difTcil de vaiidar. Un mayor controlen el proceso de desarrollo y mantenimiento incrementa la calidad delmismo y disminuye los costes de mantenimiento.

Las aplicaciones informaticas que son el producto principal obtenido alfinal del desarrollo pasa a ser la herramienta de trabajo principal de lasareas informatizadas, convirtiendose en un factor esencial para lagestion 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 recursosempleados en un proyecto software, por tanto, esta etapa debe serespecialmente considerada cn la auditoria informatica y siendo lamantenibilidad el factor critico de estudio de la auditoria demantenimiento de! SI. Entendiendo por mantenibilidad al factor decalidad que engloba todas aquellas caracteristicas del softwaredestinadas a hacer que el SI sea mas facilmente mantenible y por tantose consiga una mayor productividad.

El indice de proyectos de desarrollo que no alcanzan los objetivosmarcados es demasiado alto, lo cual denota la inexistencia o malfuncionamiento de los controles en este proceso.

Para tratar la auditoria del area de desarrollo y mantenimiento es necesarioen primer lugar acotar las funciones o tareas que son responsabilidad del area.Teniendo en cuenta que puede haber variaciones de una organization a otra, lasfunciones 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 deinformatica.

Desarrollo de nuevos sistemas y mantenimiento de los existentes. Estaes la funcion principal y la que da sentido al irea. Incluira para cadauno 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 losmismos cuando se considere oportuno para mantener un nivel devigencia adecuado a la tecnologia del momenta.

Establecimiento de un plan de formacion para el personal adscrito alarea.

Establecimiento de normas y controles para todas las actividades quese reaiizan en el area y comprobacion de su observancia,

Una vez conocidas las tareas que se realtzan en el irea de desarrollo ymantenimiento, 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 yxnancenimiento.

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 {ControlObjectives for Information and Related Technologies), la cual proporciona unconjunto estructurado de buenas pr&cticas y metodologias para su aplicacion, cuyoobjetivo es facilitar el gobierno de las TIC (ITGI, 2007a y 2007b). COBlT estabasado en la evaluacion de riesgos, de matiera que partiendo de los riesgospotenciales a los que esta sometida la actividad, en este caso el desarrollo omantenimiento de SI, se determinan una scric dc objetivos de control de alto nivelque minimicen esos riesgos.

Para cada objetivo de control de alto nivel, agrupados por cada una de lasfases del ciclo de vida del software identificadas en Metrica versidn 3 (MAP,2007), se especifican uno o mas objetivos de control de detalle o tambitiidenominadas practicas de control, que contribuyen a lograr el cumpiimiento dedicho objetivo de control de alto nivel; para lo cual nos hemos basado tambien enla propuesta de Rodero (2001). Asi mismo, se aportan una serie pruebas decumpiimiento que permitan comprobar la existencia y correcta aplicacion de dichoscontroles. Sera la funcion del auditor determinar el grado de cumpiimiento ymadurez de cada uno de ellos.

El estudio global de todas las conclusiones, pruebas y evidencias obtenidassobre cada control permitiran al auditor obtener el nivel de satisfaction dc cadaobjetivo de control, asi como cuales son los puntos fuertes y debiles del mismo.Con esa information, y temendo en cuenta ias particularidades de la organizacionen 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. Estasconclusiones,

junto con las recomendaciones formuladas, seran las que se plasmen en el informede auditoria.

En defmitiva, los auditores como requerimiento general debenproporcionar una garantia y recomendaciones en relation a los controles en unaorganizacion:

proporcionar una garantia razonabie de que se alcanzan los objetivosde 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 correctivasque deberian ser tomadas.

19.3 AUDITORIA DE LA ORGANIZACION Y GESTIONDEL AREA DE DESARROLLO Y MANTENIMIENTOLos proyectos de desaiTollo, a pesar de que tengan entidad propia y se

gestionen con cicrta autonomia, necesitan apoyarse en ei personal del area y losprocedimientos establecidos. La irnportancia de estos aspectos ha motivado que seanecesario establecerse objetivos de control que faciliten la auditoria de laorganizacion y gestion del area.

Objetivo de Control OGl: procesos, organizacion y relaciones: el areade desarrollo debe tener definidos los procesos del area, su organizacion y lasrelaciones con el exterior.

OG1-C1: deben establecerse de forma ciara las funcioncs del area dedesarrollo dentro del departamento de informatica. La direccion del area deberaparticipar en el comite de direccion del departamento de informatica a la hora dedeterminar la prioridad de los programas de inversion en TIC alineados con laestrategia del negocio, seguimiento de los proyectos horizontales/transversales aldepartamento y resolution de conflictos de recursos. Se debe comprobar que:

576 AUDITORJA DE TEONGJ-OGIAS Y SiSTEMAS DE JNFORMACJ(3N OKA-MA

Existe ei documento que contiene las funciones que son competenciadel area de desavrollo, que esta aprobado por la Direction deinformatica y que se respeta.

OG1-C2: debe especificarse ei organigrama con ta relacion de puestos delarea, as{ como el personal adscrito y el puesto que ocupa cada persona. Asi mismodicha organizacion del area deben corresponderse con las necesidades y objetivosdel negocio en cada momento. Ademas, debe exislir un procedimiento para laactualizacion del organigrama y para la promocion de personal. Se debe comprobarque:

Existe un procedimiento de revision que se aplica periodicarnente paracomprobar que la organizacion del area se adapta a las necesidades yobjetivos del negocio en cada momento y al dinamismo de las TIC.

Existe un organigrama con la estructura de organizacion del drea. Paracada puesto deben describirse los roles y responsabilidades, es decir,las funciones a desempenar y los requisitos minimos de formacion yexperiencia, as! como la dependencia jerarquica del mismo.

Existe un manual de organizacion que regula las relaciones entrepuestos.

Existe la relacion de. personal adscrito al area, incluyendo el puestoocupado por cada persona. Se deben cumpiir los requisitos de lospuestos.

' Estan establecidos los procedimientos de promocion de personal apuestos superiores, teniendo siempre en cuenta la experiencia yformacion.

Existe un proceso de supervision para asegurar que los roles y susresponsabilidades o funciones se realizan correctamente, de maneraque permita valorar si el personal cuenta con la suflciente autoridad yrecursos para poder desarrollar sus funciones adecuadamente.

OG1-C3: debe definirse e identificarse al personal TIC clave yminimizarse la dependencia para la realization de funciones criticas para el area enpersonas individual es. Se debe comprobar que:

Existen procedimientos forrnales que recojan esas funciones criticas yel conocimiento mas critico esta suficientemente document-ado; asi

como existen otros miembros del personal entrenados para poderrealizar esas funciones en un momento dado.

OG1-C4: debe establecerse el marco de trabajo de los procesos del area dedesarrollo que permita la ejec-ucion y puesta en practica del plan estrategico (o plandirector) de las TIC. Este marco debera incluir la estructura de los procesos y susrelaciones, 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 losobjetivos de los procesos, sus medidas, centrales y madurez han sidodefinidos e impiementados, asi como formalmente documentados yaprobados.

QGl-CS: las relaciones con el exterior del departamenlo deben produeirsede acuerdo a un procedimiento. Deben mantenerse contaetos con proveedores pararecibir information suficicnte sobre productos que puedan ser de interes. Y debeexistir un protocolo para la contratacion de servicios externos (recursos humanos,hardware, software o servicios). Se debe comprobar que:

Existen los protocolos, estan aprobados y se hacen uso de ellos. Se esta en contacto con un nuinero suficiente dc proveedores para

recibir informacion objetiva y completa y el tiempo invertido noexcede lo razonable.

La selection del proveedor se hace de forma objetiva y evitasituaciones de monopolio por parte de un unico proveedor.

El protocolo inciuye un contrato-tipo que prevea los riesgos mdsfrecucntes cuando se contiatan servicios externos y en todo casoincorpora penalizaciones en caso de iucumplimiento de contrato porparte del proveedor.

Esta definido cudndo, como y que tipo de trabajos pueden serexternaiizados y cual es su forma de implementation, seguimiento yreception.

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, certiflcandoloantes 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 dichosrequisitos de seguridad se recogen por contrato.

OG1-G6: deben establecerse los roles y responsahilidades para la gestiondel aseguramiento de la calidad, gestion de riesgos, seguridad y conformidad, Sedebe comprobar que:

El grupo de aseguramiento de la calidad cuenta con los sistemas deaseguramiento de la calidad apropiados, as! como los controles yasesoramiento de expertos.

Las responsabilidades y roles asi como los procesos para la gestion deriesgos y seguridad han sido correctamente establecidas, formalizadasy documentadas y satisfacen los requisitos del area. Y son ejccutadospor persona! con la suficiente formacion y experiencia en la materia.

Objetivo de Control OG2: gestidn de Recursos Humanos TIC. El areade desarrollo debe contar con unos recursos humanos adecuados para gestionar eldesarrotlo y mantenimiento de SI. Esto se consigue mediante practicas definidas yacordadas para la contratacion, entrenarniento o formacion, evaiuacion delrendimiento, promocion y recepcidn/abandono de personas. Este proceso es criticodebido a que las personas son uno de los activos mas importantes para todaorganization, de manera que una buena gestion del area de desarrollo dependententre otros factores de la motivation, formacion y aptitud de su personal adscrito.

OG2-C1: deben existir procedimientos de contratacion objetivos. Se debecomprobar que:

Existe un plan de gestion de recursos humanos TIC que recoge losroles y perfiles necesarios en el area para cumplir sus objetivos y quees revisado al menos anualmente.

Las ofertas de puestos del area se difunden de forma suficiente fuera dela organizacion y las seiecciones se hacen de forma objetiva.

RA-MA CAPiTULO 19. DESARROLLO Y MANTENIMiENTO DESI 579

Las personas seleccionadas cumplen los requisitos del puesto al queacceden.

OG2-C2: debe existir un plan de formacion que este en consonancia conlos objetivos tecnologicos del area y alineados con los objetivos del negocio. Sedebe comprobar que:

Se tiene aprobado un plan de formacion a corto, medio y largo plazoque 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 estaevaiuacion se tiene en cuenta a la hora de redefmir el plan deformacion.

Contempla la formacion de todos los empieados y tiene en cuenta elpuesto 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 latransferencia de conocimiento que asegure la continuidad de lasfunciones.

OG2-C4: debe existir una biblioteca y una hemeroteca accesibles por elpersona! del area asi como acceso a internet. Se debe comprobar que*

Esian disponibles un numero suficiente de libros, publicacionesperiodicas, monogramas, etc. de reconocido prestigio, ya sea enformato electronico o papel, y el personal tiene acceso. a elios.

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 comprobarque:

Existe algun mecanismo que permita a los empleados hacersugerencias sobre mejoras en la organization de! area.

No existe una gran rotation de personal y hay un buen ambiente de

OG2-C6: debe existir un procedimiento de evaluation periodico de losrecursos humanos TIC propios y contratados del area. Se debe comprobar que:

El persona! cuenla con la cualificaciun descrita en ios rolesidentificados en el area, en base a su formation y experiencia.

Se minimiza la dependencia de personas individuales clave para ciertasfunciones mediante la captura del conocimiento (documentation),compartiendo dicho conocimiento entre la plantilia y conplanificaciones 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 essimilar a! del resto de la organization.

Existe una remuneration o reconocimicnto en base a la consecucidn delos objetivos de rendimiento logrados.

Objetivo de Control OG3: plan estratdgico de Tecnologias de laInformation del area: el area de desarrollo debe participar en la definition delplan estrategico o plan director de Tecnologias de la Informacion.

OG3-C1: el area debe tener y difundir su propio plan a corto, medio ylargo plazo, que sera coherente con el plan director de TIC del departamento deinformalica y con el plan de sistemas, si este existe. Se debe comprobar que:

El plan existe, esta actualizado, es claro y realista.

Los recursos actuaies, mas los que se estd planificando que seincorporen al area, son suficientes para su cumplimiento.

RA-MA CAPiTUI.O 19. DESARROLLO Y MANTFNIMIENTO DE SI 581

Se revisa y actualiza con periodieidad en fimcion de las nuevassituaciones-

Se difunde a todos los empleados para que se sientan participes delmismo, a! resto del departamento y los departamentos a los que lesatahe.

OG3-C2: la realizacion de nucvos proyectos debe basarse en el plandirector TIC y en el plan de sistemas en cuanto a objetivos, rnarco general yhorizonte 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 vezcomenzado 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 areade desarrollo debe participar en la direction de la politica tecnologica deldepartamento de informatica.

" OG4-C1: deben analizarse las nuevas regulaciones/regjamentaciones en'materia de TIC asf como las tecnologias existentes y emergentes y determinar quepolitica tecnologica es la apropiada para la consecucidn de los objetivos del area, ypara el desarrollo de nuevos sistemas o mantcnimicnto de los existentescompatibles con )a arquitectura de los sistemas actuaies o realizar un estudio de lasestrategias de migration en su caso. Se debe comprobar que:

Existe un proceso de analisis de las regulaciones y tecnologias y eltiempo invertido.no excede to razonable.

Los estandares tecnologicos corporativos encajan con las arquitecturasde los SI existentes en mantenimiento.

Periodicamente se comprueba e! nivel tecnologico, para ver si escoherente con ei plan director TIC y con el plan de sistemas y si esti enlinea con el de otras organizations similares.

Objetivo de Control OGS: gestidn de las lnversiones TIC: el area dedesarrollo debe llevar su propio control presupueslario en lo relative a la gestion delas inversiones en TIC. Se debera comprobar que;

582 AUDlTORiA DE TECNGLOGiAS Y StSTEMAS DEINFORMACION RA-MA

Se hace un presupuesto por ejercicio y se cumple y que esta enconsonancia con IDS objetivos a cumplir.

Exists un proceso de priorizacion en la ccnfeccion del presupuestopara la asignacion de inversiones y recursos TIC a adquisiciones,proyectos de desarrollo y mantcnimiento, que maximice el ROI dedlchas inversiones TIC.

Existe un proceso de gestion de costes comparando los costes actualesen desarrollo y mantcnimiento y adquisiciones con lo presupuestado.Dicho proceso debera reportar las desviaciones existentes de maneraque debera haber una estimation del impacto de estas sobre losprogramas a fin de facilitar las acciones correctivas a tomar.

Objetivo de Control OC6: gestion de la Caiidad: el area de desarrollodebe disponer de unos procesos de desarrollo regidos por los estandares yprincipios de ingenieria del software ampliamente aceptados.

OG6-C1: debe existir un registro de problemas que se producen en losproyectos del area, incluyendo los fracasos de proyectos completes. Sc debe

Existe un catalogo de problemas, incluyendo para cada uno de ellos lasolution o soluciones encontradas, proyecto en el que sucedio, personaque lo resolvio, etc.

El catalogo es accesible para todos los miembros del area, estaactualizado y tiene uno 0 varios indices que faciliten la busqueda.

Se registran y controlan todos los proyectos fracasados (aquellos quecomienzan y no llegan a su fin), asi como los recursos invertidos en losmismos.

OG6-C2: debe mantenerse y comunicarse periodicamente al area lasmodificaciones del plan global de caiidad a fin de promover la mejora continua. Sedebe 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 deldepartamento adoptadas por el area de desarrollo.

RA-MA CAPiTULO 19 DESARROLLO Y MANTENIMIENTO DE SI 583

OG6-C3: debe tenerse implantada una metodologla de desarrollo de STsoportada por herramientas CASE. Se debe comprobar que:

La mctodologia cubre todas las fases del desarrollo y mantenimiento yes adaptable a distintos tipos de proyecto.

La metodologia y las tecmcas asociadas a la misma estan adaptadas alentomo tecnologico y de organization del area de desarrollo.

Se ha adquirido, homologado e implantado segun las norm as del areauna herramlenta/s CASE que se adapta a la metodologla elegida y quecumple con los requisitos minimos exigibles a una herramienta de estetipo.

Se ha formado al personal sobre esta metodologla y su adaptation, asicomo sobre las tecnicas asociadas a la herramienta CASE.

Existe un procedimiento que permita determinar en que proyectos eluso de la herramienta CASE es ventajoso.

Esta claramente especificado de que forma el uso de la herramientaaltera las fases de desarrollo tradicionales.

La herramienta CASE es capaz de mantener el diccionario de datos ycumplir con la sintaxis e integridad de los datos.

La herramienta CASE cumple con los requisitos de confidencialidadnecesarios sobre la documentation asociada al proyecto.

OG6-C3: debe existir un mecanismo de creacion y actualizacion depracticas y estandares de caiidad asi como de practicas, estandares de desarrollo ymantenimiento. Se debe comprobar que:

El mecanismo para la creacion y actualizacion de practicas yestandares esta documentado y es conocido en el Srea.

Estan definidas las practicas de analisis y diseno, e incluye las tdcnicasy herramientas a usar, etc. Asi como tambien hay una guia o practicasde programaciOn para cada uno de los lenguajes homologados. Y parala realizacion de prucbas (validacidn dc los requisitos, planes depruebas, pruebas unitarias, de regresion y de integracion).

584 AUDI JOR1A DE TECN0L001AS Y SISTRMAS DE INFORMACtQN

586 AUDITORiA DE TECNOLOGIAS Y SISTEMAS DE fNFORMAClON RA-MA

disponibles para realizar la auditoria. Esto obliga a que sean la pericia yexperiencia del auditor las que determiner! las actividades del proyecto que secontrolaran con mayor intensidad en funcion de los pararnetros arsteriores.

En este apartado se definen objetivos y tecnicas de control generalesaplicables a cualquier proyecto. El auditor decidira los objetivos mas importantesen funcion de las caracteristicas del proyecto y de la fase a auditar.

Como se puede observar los controles de auditoria han sido agrupados porcada una de las fases del ciclo de vida del software identificadas como procesos enMetrica version 3, as! mismo se especifican uno o mas objetivos de control dedetalle o tambien denominadas practicas de control, que contribuyen a lograr elcumplimiento ce dicho objetivo de control de auditoria ce alto nivel.

Aunque los objetivos de control se han catalogado en funcion de la fase delproyecto a la que se aplican, en el caso de la auditoria de un proyecto de desarrollose puede hacer en dos momentos distintos. a medida que avanza el proyecto o unavez concluido el mismo. Las tdcnicas a utilizar y los elcmentos a inspeccionar,normalmente los productos y documentos generados en cada fase, seran losmismos en ambos casos. La unica diferencia es que en el primer caso lasconclusiones que vaya aportando el auditor pueden afectar al desarrollo delproyecto, aunque nunca participant en la toma de decisiones. Respecto a laauditoria de un proyecto de mantenimiento, se detalla mas adelante y secorresponde con e! apartado que describe la auditoria de dicha fase o proceso-

19.4.1 Auditoria de la gestion y planificacion del proyecto

Los objetivos de control que se consideran en este apartado son lossiguientes.

Objetivo de Control PI: el proyecto de desarrollo debe estar aprobado,definido y pianificado formalmente.

Pl-Cl: debe existir una orden de aprobacion del proyecto que definaciaramente los objetivos, restricciones y las unidades afectadas. Se debe comprobarque:

Existe una orden de aprobacion del proyecto reffendada por un organocompetente. El estudio de vvabilidad debe habcr seguido el cauceestablecido.

"$

P&ff'yBL

RA-MA CAPlTULO 19. DESARROLLO V MANTENIMIENTO DE S! 587

En el documento de aprobacion estan deftnidos de forma clara yprecisa los objetivos del mismo y las restricciones de todo tipo quedeben tenerse en cuenta (temporales, recursos tecnicos y humanos,presupuesto, etc.) y su alineacion con el plan de sistemas.

Se han identificado las unidades de la organizacion a las que afecta.P1-C2: debe designarse un responsable o director del proyecto. Se debe

comprobar que:

La designacion se ha llevado a cabo segun el procedimientoestablecido.

Se le ha comunicado al director su nombramiento junto con toda lainformacion 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 normasestablecidas.

Se han evaluado los riesgos asociados al proyecto, especialmentecuando se van a usar tecnologias no usadas hasta el momento.

Se ha elegido el ciclo de vida mas adccuado al tipo de proyecto de quese trata.

Se ha hecho uso de la informacidn historica que se dispone tanto paradimensionar el proyecto y sus riesgos como para seleccionar el ciclo devida.

P1-C4: una vez determinado el ciclo de vida a seguir, se debe elegir elequi'po tecnico que rcalizara e! proyecto y se determinara el plan del proyecto. Sedebe comprobar que:

La designacion del equipo de desarrollo se ha llevado a cabo segun elprocedimiento establecido.

Los participates que pertenezcan a otras areas (sistemas,comunicaciones, ofimatiea, etc.) se han solicitado. segun el protocoloexistente.

588 AUDITORIA PE TECN'OLOGiAS Y SISTEMAS DE INFQRMACiON RA-MA

Si participa persona! externo, los perfiles profesionales son adccuadosa las funciones que van a realizar. El contrato cumple el protocolo decontrataci6n.

Se ha comunicado a todos los miembros del equipo de desarrollo losobjetivos del proyecto, la responsabilidad que tendran en el mismo, lasfechas en las participar&n y la dedicacion (completa/parciai).

El plan de proyecto realizado es realists y utifiza la informacidnhistorica de la que se disponga para realizar estimaciones.

Objetivo de Control P2: el proyecto se debe gestionar de forma que scconsigan los mejores resultados posibles teniendo en cuenta las restricciones detiempo y recursos. Los criterios usados seran coherentes con los objetivos de lasunidades afectadas.

P2-C1: los responsabies de las unidades o areas afectadas por el proyectodeben participar en la gestidn de! proyecto. Se debe comprobar que:

Se ha constituido formalmente el eomite de direction del proyecto y enel estan incluidos los responsabies de todas las unidades afectadas y laoficina de proyectos.

El comite tiene una periodicidad de reunion minima, y en cualquiercaso siempre que lo exija e! desarrollo del proyecto, debe tenercompetencia para asignacion de recursos, la revision de la marcha delproyecto y para modificar e! plan del proyecto en funcion de lasrevisiones.

Las reuniones se hacen con un orden del dia previo y las decisionestomadas quedan documentadas en las actas de dicho eomite.

El numero de reuniones y la duration de las mismas no superan unlimite razonable comparado con la envergadura del proyecto.

P2-C2: se debe establecer un mecanismo para la resolution de losproblemas que puedan plantearse a lo largo de! proyecto. Se debe comprobar que:

Existen hojas de registro de problemas y que hay aiguna personadel

proyecto encargada de su reception, asi como un procedimientoconocido de tramitacion.

C RA-MA CAPITULO 19. DESARROLLO V MANTENlMtENTO P SI 589

Hay un nretodo para catalogar y dar prioridad a los problemas, asicomo para trasladarlos a la persona que dc los debe resolver,informando si es necesario al director del proyecto y al comite dedireccion.

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 pudieranproducirse, asi como para evaluar el impacto de los mismos.

La documentacion afectada se actualiza de forma adecuada y se llevaun control de versiones de cada producto, consignando la ultima fechade actualizacion.

Se remite la nueva version de los documentos actualizados a losparticipantes en el proyecto.

P2-C4: cuando sea necesario reajustar el plan del proyecto, normalmenteen un hito a! finalizar una fase, debe hacerse de forma adecuada. Se debecomprobar que: ' '

Se respetan los limites temporales y presupuestarios marcados al iniciodel 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 formaparticipen en el proyecto y se vean afectados.

Si existe un plan director TIC o plan de sistemas, se actualizara enconsecuencia.

P2-C5: debe hacerse un seguimiento de los tiempos empleados tanto portarea 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 cadaparticipate del proyecto dedica al mismo y qud tarea realiza en esetiempo.

Las productividades que se obtienen para distintos empleados en lasmismas tareas son similares y estan en consonancia con la informacionhistorica.

Existe un procedimiento para analizar las desviaciones y proponeracciones correctivas.

P2-C6: se debe controlar que se siguen las etapas del ciclo de vidaadoptado para el proyecto y que se generan todos los documentos asociados a lametodologia usada. Se debe comprobar que:

Antes de ccmicnzar una nueva etapa se ha documentado la etapa previay se ha revisado y aceptado, especialmente en las fases de an&iisis ydiscfio.

La documentacLon cumple los estandares y procedimientosestablecidos en el area.

Se respeta el plan establecido y en caso contrario se toman las medidasoportunas 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 y esta catalogadaperfectamente para accesos posteriores.

Los recursos, tanto personales como materiales, se ponen a disposiciondel area o departamento del que provienen.

El comite de direction y el director del proyecto hacen balance delproyecto, estudiando los posibles problemas y sus causas, los cambiosdel plan, etc. Toda esta informacidn se registra en los archivoshistoricos sobre estimaciones y problemas.

RA-MA CAPiTULO 19. DESARROt.LO Y MANTENIMIENTO PES) S9I

La nueva aplicacion se incorpora al catalogo de aplicaciones existentescon toda la informacion relevante dc la misma.

19.4.2 AUMTORIA DE LA FASE DE ESTUDIO DEVIABILIDAD

El objetivo del estudio de viabilidad del sistema es el anaiisis de unconjunto concreto de necesidades para proponer una solucion a corto plazo, quetenga en cuenta restricciones economicas, tecnicas, legales y operativas. Por lotanto, el auditor debera controlar que:

Objetivo de Control VI: antes de la definition del proyecto debenestudiarse los requisitos que se han de satisfacer y estudiarse, si precede, lasituation actual, identificando seguidamente las altemativas de solucion yseleccionando aquella que satisfaga mas eficaz y eficientemente los requisitosidentificados, lo cual puede derivar en la definicion de uno o varios proyectos queafecten 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 requcridaspara satisfacer las necesidades planteadas por el cliente o usuario. Se debecomprobar que:

Existe un dccumento que recoge la descripcion general de la necesidadplanteada por ei usuario y los objetivos generales (y en el caso deexistir plan de sistemas se tomara como referencia los requisitos yarquitectura de informacion del mismo) as! como las posiblesrestricciones tdcnicas, legales, operativas y economicas.

Se han determinado formalmente el grupo de usuarios que participaraen el proyecto, identificandose sus perfiles y dejando claras sus tareasy responsabilidades.

V1-C2; debe estudiarse la situacibn actual y determinarse los sistemasafectados Se debe comprobar que:

Se han realizado los modelos del sistema. 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 elnuevo sistema estableceran de forma clara los requisitos de! mismo. Se debecomprobar que:

Se ha realizado un plan detallado de entrevistas con el grupo deusuarios y con los responsables de las unidades afectadas que permitaconocer como valoran el sistema actual y lo que esperan del nuevosistema.

Se han identificado las directrices tecnicas y de gestion, a partir delplan de sistemas en el caso de que el proyecto pertenezca ai ambito deeste. Estas directrices seran: politicas tecnicas (de gestidn de proyectos,de desarrollo, de arquitectura), politica de seguridad, directrices deplanificaciori, gestion de la calidad y gestion de cambios.

Existe un catalogo de requisitos que estan justificados y cada requisitotiene una prioridad y esta clasificado en funcional y no funcional.

EI catalogo de requisitos ha sido revisado y aprobado por el grupo deusuario y los responsables as: como por el comite de direccion.

V1-C4: se deben estudiar y valorar las distintas altemativas de soluciOnque satisfacen los requisitos identificados anteriormente y analizar sus ventajas einconvenientes. Se debe comprobar que:

Existe un documento en el que se describen las distintas altemativas ycada alternativa esta descrita desde un punto de vista logico (al menosmodelo logico de procesos) y es coherente con los requisitosestablecidos.

Si existe en el mercado algun producto o productos que cumplan conunas minimas garantias los requisitos especificados, una de lasaltemativas debe ser su adquisicion.

Si no Io impiden las caracteristicas del proyecto una de las altemativasdebe ser el desarrollo del sistema por parte de una empresa externa.

Se ha evaluado las ventajas e inconvenientes de cada alternativa deforma objetiva (anIisis coste/beneficio por ejemplo), as! como losriesgos asociados. Teniendose en cuenta el impacto de cada alternativaen la organizacion, desde el punto de vista tecnico, organizativo y deoperation asi como los beneficios esperados y costes asociados.

RA-MA CAPITULO i9. DESARROLLO Y MANTENiMIENTO DE SI 593

Vl-CS: debe seieccionarse la solution que satisfaga mas eficaz yeficientemente los requisitos identificados. Sc debe comprobar que:

El comite de direccion ha seleceionado una alternativa como la masventajosa y es realmente la mejor para la organizacion y se ha recogidoformalmente su decision y argumentation asociada.

Se ha actualizado el plan del proyecto segun los criterios yacomentados.

19.4.3 Auditoria de la fase de analisisEl objetivo de esta fase es la obtencion de una especificacion detallada del

sistema de informacion que satisfaga las neeesidades de informacion de losusuarios y sirva de base para el posterior disefio del sistema y de una formaindependiente del entomo tecnico.

Para lo cual se consideran los siguientes objetivos de cmitrol:

Objetivo de Control Al.* se debe eiaborar una especificacion detalladaque permita describir con precision el sistema de informacidn.

Al-Cl: debe realizarse un plan detallado de sesiones de trabajo con elgrupo de usuarios del proyecto y los responsables de las unidades afectadas pararecopilar la informacion necesaria. Se debe comprobar que:

Las tecnicas que se utilizan para la recopilacion de esta informacion esia adecuada en funcion de las caracteristicas del proyecto y los tipos deusuario 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 queestos puedan preparar la entre vista y la documentaci6n que deseenaportar a la misma. Y el gui6n inciuye todas las cuestiones necesariaspara obtener la informacion sobre las funciones deseadas y probiemasque se quieren resolver.

A1-C2: a partir de la informacion obtenida de las entrevistas se deberealizar la descripcidn inicial del SI y obtener el catalogo de requisitos detalladodel mismo. Se debe comprobar que:

Existe un catalogo de requisitos, que estan justificados y detallados.

594 AUDITORiA DE TECNOLOGIAS Y SiSTEMAS PE INFORMACION RA-MA

Cada requisito tierte una prioridad y estan clasificados en funcionales yno funcionales.

La especificacidn del sistema incluye los requisitos no funcionales: deseguridad, rendimiento, disponibilidad, implantacibn, etc.

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. Sedebe comprobar que:

La descomposiciort de los subsistemas esta orientada a los procesos denegocio.

Se han asignado los requisitos a cada uno de los subsistemasidentificados, y consecuentemente actualizado el catalogo derequisitos.

A1-C4: se debe realize el modelo del sistema que sirva de base para eldiseno. En el caso de analisis estructurado, mediante la elaboracidn y descripciondetallada del modelo de datos y de procesos, y en el caso de un analisis orientado aobjetos, a traves del modelo de clases y el de interaction de objetos, mediante elandlisis de los cases de uso. Se debe comprobar que:

Los modelos son correctos tecnicamente y que se han realizado con latecnica 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 elusuario, tales como formatos de pantalias, di&logos, formatos de informes yformularios de entrada. Se debe comprobar que:

Se han descrito con suficiente detalle las interfaces: pantalias a travesde las cuales el usuario navegara por la aplicacion, incluyendo todoslos campos significativos, menus, botones, etc.; asi como informes yformularios asociados si existen. Si hay normas de diseflo o estilo depantalias, informes, formularios, etc.. en el area, se verificara que serespetan.

RA-MA CAPiTUI.O 19. DESARROLI-Q V MANTCNIMIENTO DE SI 595

La interfaz de usuario se ha aprobado por el grupo de usuarios y por elcomite de direccion.

AI-C6: debe especificarse el plan de pruebas que el nuevo sistema debesuperar para ser aceptado. Se debe comprobar que:

Se han definido los requisitos del entomo de pruebas y el alcance delas pruebas.

Se ha elaborado el plan de pruebas de aceptacion del sistema, que fatees coherente con el catalogo de requisitos y con la especificacionfoncional del sistema y que es aceptado por el grupo de usuarios y porel comite de direccion.

Gbjetivo de Control A2: se debe garantizar la calidad de los distintosmodelos generados en el proceso de analisis del SI, y asegurar que los usuarios ylos analistas tienen el mismo concepto del sistema.

A2-C1: se debe de verificar la calidad tecnica de cada modelo y asegurar lacoherencia entre los distintos modelos. Se debe comprobar;

La calidad formal de los distintos modelos, comprobando si sonconforme a la tecnica seguida para la elaboracion de cada producto y alas 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 travesde! catalogo de requisitos, mediante la traza de requisitos, como atraves de la validacion directa del usuario.

A2-C2: debe realizarse una validacion formal de la especificacion derequisitos y de los modelos del analisis del sistema. Se debe comprobar que:

Los usuarios confirman que los requisites especificados en el cat&logode requisito, asi como los casos de uso, son validos, consistentes ycompletes.

Una vez que el catalogo de requisitos ha sido especificadoformalmente 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.

Cualquier petition de cambio en los requisite que pueda surgirposteriormente debera ser evaluada y aprobada.

La actualization del plan de proyecto seguira los criterios yacomentados, deiall&ndose en este punto en mayor medida la entrega ytransition al nuevo sistema.

19.4.4 Auditona de la fase de disenoEl 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 laespecificacion detallada de los componentes del sistema de information.

Objetivo de Control Dl: se debe definir una arquitectura del sistema quesea coherenle con la especificacibn funcional que se tenga y con el entomotecnologico.

D1-C1: el particionamiento fisico del sistema de informacibn, asi como su.organization en subsistemas de diseno, la especificacion del entomo tecnologico, ysus requisitos de operation, administration, seguridad y control de acceso debenestar definidos de forma clara y ser conformes a los estandares y norm as deldepartamento de informatica. Se debe comprobar que:

Estan perfectamente diferenciados y definidos los subsistemasespeclficos del sistema de information (en adelante, subsistemasespecificos) y los subsistemas de soporte.

Estan definidos todos los elementos que configuran el entomotecnologico (servidcres, PC, perifericos, conexiones de red, sistemasgestores de bases de datos, middleware, herramientas CASE, etc.)junto con su planificacidn de capacidades (capacity planning) y susrequisitos de operation, administracion, seguridad y control de acceso.

Exists un cat&logo de excepciones, de requisites, normas y estandaresoriginados como consecuencia de la adoption de una determinadasolution de arquitectura o infraestructura.

Los elementos seleccionados estn dentro de los estandares deldepartamento de informatica y son capaees de responder a los

.RA-MA CAPJTULO 19. PESARROLLO-Y MANTENiMiRNTO PES! 597

requisites establecidos de volumenes, tiempos de respuesta, seguridad,etc.

D1-C2: se debe realizar un diseno detallado de los subsistemas de soportey del sistema de informacion especifico. Se debe comprobar que:

Se ban identificado los mecanismos genericos de diseno, asi comolas librerias y clases reutilizables.

El tamano de los modules o clases es adecuado y el factor deacoplamiento entre ellos es minimo y la cohesion interna esmaxima.

Los modulos o clases, se disenan para poder ser reutilizados cn elfuturo por otros SI.

BI-C3; se debe disenar la estructura de datos adaptando lasespecificaciones del sistema al entomo tecnologico. Se debe comprobar que:

El modelo de datos tiene en cuenta el entomo tecnologico y losrequisitos de rendimiento para los volumenes y frecuencias de accesoestimados, 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 aceptacidndel diseno por parte de los responsables de las areas de Explotacidn ySistemas.

Objetivo de Control 02: se deben generar todas las especificacionesnecesarias para la construction del sistema de informacion:

D2-CI: se deben generar unas especificaciones de construccion. Se debecomprobar que:

Se ban fijado formalmente las directrices para la construccion de loscomponentes 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 inicialde datos asi como los requisites de operacion. Se debe comprobar que:

Se definen los procedimientos de migracion y sus componentesasociados, con las especificaciones de construccion oportunas.

Se definen los requisitos relativos a la propia implantacion del sistemaen el entomo de operacibn y aquellos relacionados con ladocumentation que el usuario requiere para operar con el nuevosistema.

D2-C3: debe realizarse la especificacion tecnica del plan de pruebas. Sedebe comprobar que:

Existe el plan de pruebas y contempla todos los recursos necesariospara llevarlas a efecto.

Es adecuado para validar cada uno de los componentes del sistema,incluyendo pruebas de caja blanca. Tendran en cuenta las posiblescondiciones logicas de ejecucion, ademas de posibles fallos delhardware o software de base y ataques de seguridad.

Permite validar la integracidn de los distintos componentes y el sistemaenconjunto.

D2-C4: se debe realizar una aprobacion formal del disefio del sistema porel comite de direccion. Se debe comprobar que:

Se realiza la presentation del disefio al comite de direccion y seregistra la aprobacion del mismo.

Se actuaiiza el plan de proyecto scgun los criterios ya comentados.

19.4.5 Auditoria de la fase de construccionEn 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 usuariospuedan trabajar con el nuevo sistema.

Objetivo de Control CS-1: los componentes que se desarrolien debendesarrollarse usando tecnicas de programacidn correctas.

RA-MA CAPiTUI.O 19. DF.SARROILO Y MANTEN1MIENTODE SI 599

CS1-C1: se debe preparar adecuadamente el entomo de desarrollo y depruebas, asi como los procedimientos de operacion y seguridad. Se debecomprobar que:

Se han creado e inicializado las bases de datos o ficheros necesarios yque cumplen las especificaciones de construccion del sistemaobtenidas en la fase de diseno.

En ningun momento se trabaja con information que se encuentra enexplotacion.

Se han preparado los editores, compiladores, herramientas, etc.necesarios y estan disponibles los puestos de trabajo y acceso a losequipos, redes, etc.

Se han preparado los proce