DOMINIO 3

ADQUISICIÓN, DESARROLLO E IMPLEMENTACIÓN DE SISTEMAS DE INFORMACIÓN

DOMINIO 3

Este capítulo sobre la adquisición, el desarrollo y la

implementación de sistemas de información
proporciona una visión general de los procesos y las
metodologías clave que utilizan las organizaciones
cuando crean y cambian sistemas de aplicación y
componentes de infraestructura.
ACERCA DEL EXAMEN CISA

Dominio 1: Proceso de
Dominio 5: auditoría a los sistemas
Protección de los de información, 21%
activos de
información, 27%

Dominio 2:
Gobierno y gestión
de TI, 17%
Dominio 4:
Operaciones de los
sistemas de
información y
resiliencia del
negocio, 23% Dominio 3: Adquisición,
desarrollo e
implementación de
sistemas de
información, 12%
OBJETIVOS DEL DOMINIO 3

Una vez finalizado este dominio, el auditor SI debería poder

hacer lo siguiente:
• Evaluar si el caso de negocio para los cambios propuestos a los sistemas
de información cumple con los objetivos de negocio.
• Evaluar las políticas y prácticas de gestión de proyectos de la organización.
• Evaluar los controles en todas las etapas del ciclo de vida del desarrollo de
sistemas de información.
• Evaluar la preparación de los sistemas de información para su
implementación y migración a producción.
• Realizar revisiones posteriores a la implementación de los sistemas para
determinar si se cumplen con los entregables, los controles y los
requerimientos del proyecto.
• Evaluar las políticas y prácticas de gestión de cambios, configuración,
versiones y parches.
TEMAS DEL DOMINIO 3

Adquisición, desarrollo e Implementación de sistemas de

implementación de sistemas de información
información • Metodologías de prueba
• Gobierno y gestión de proyectos • Gestión de configuración y versiones
• Caso de negocio y análisis de factibilidad • Migración de sistemas, implementación
• Metodologías de desarrollo de sistemas de infraestructura y conversión de datos
• Identificación y diseño del control • Revisión posterior a la implementación

5
 Para que un auditor de SI tenga certeza de que los
objetivos de una organización serán cumplidos
mediante las prácticas de gestión de sus sistemas de
información, es importante que el auditor SI
comprenda cómo una organización evalúa, desarrolla,
implementa, mantiene y desecha sus sistemas de
información y componentes relacionados.

ADQUISICIÓN, DESARROLLO E
IMPLEMENTACIÓN DE
SISTEMAS DE INFORMACIÓN

6
GOBIERNO Y GESTIÓN DE PROYECTOS

7
ROLES Y RESPONSABILIDADES DEL PROYECTO

8
TÉRMINOS CLAVE

Término clave Definición

Proyecto Conjunto estructurado de actividades relacionadas para proporcionar
una capacidad definida (que es necesaria pero no suficiente, para
conseguir un resultado requerido por el negocio) a la empresa con
base en un presupuesto y cronograma acordado.
Cartera de proyectos Conjunto de proyectos de propiedad de una empresa. Normalmente
incluye las principales pautas relativas a cada proyecto, lo que incluye
objetivos, costos, cronogramas y demás información específica del
proyecto.
Técnica de revisión y Técnica de gestión de proyectos utilizada en la planificación y el
evaluación de programas control de proyectos de sistemas.
(PERT).
PROYECTOS VS. PROGRAMAS

Proyecto Programas
• Tiene objetivos específicos, • Grupo de proyectos y
entregables, y fechas de inicio y tareas en función del tiempo muy
finalización. vinculadas a través de un objetivo
• Siempre con límites de tiempo común
• Por lo general, dividido en fases • Más complejo
explícitas • Suele tener una duración más
larga, un presupuesto más alto y
un riesgo más alto
• Tiene mayor importancia
estratégica
GESTIÓN DE PROYECTOS
El enfoque de gestión de proyectos depende del tamaño de
la organización y de la complejidad del negocio.
Los procesos de
EL AUDITOR SI DEBE: gestión de proyectos
incluyen:
Familiarizarse con el estándar o estructura utilizada por la organización. •Inicio
•Planificación
Familiarizarse con el contexto del proyecto:
•Ejecución
• La importancia del proyecto en la organización.
•Control
• La conexión entre la estrategia de la organización y el proyecto. •Cierre
• La relación entre el proyecto y otros proyectos.
• La conexión entre el proyecto y el caso de negocio subyacente.

Entender el entorno y el contexto de los proyectos ayuda a identificar:

• Objetivos comunes para la organización
• Riesgo
• Conexiones de recursos
ROLES Y RESPONSABILIDADES

La función de auditoría debe tener una participación activa en proyectos de desarrollo de

aplicaciones, a menudo como expertos en control.
El CISA debe estar familiarizado con los roles y responsabilidades generales en la
gestión de proyectos, incluidas:

Comité de dirección Patrocinador del

La alta gerencia Gestión de usuarios Gerente del proyecto
del proyecto proyecto

Director de seguridad
Gestión y equipo del
Equipo de usuarios del e ingeniero de Aseguramiento de la
proyecto de desarrollo
proyecto seguridad de sistemas calidad
de sistemas
de información
ESTRUCTURA Y GESTIÓN DE PROYECTOS

Comité Directivo
Gerente / Director

Sponsor

Gerente Usuario
Control Calidad
Líder de Proyecto

Equipo desarrollo Equipo usuarios Equipo técnico Responsable

de sistemas del del proyecto (soporte de de Seguridad
proyecto infraestructura)

Analistas Usuarios clave Soft Costes

Programadores Hard

Red PROYECTO

Objetivos: S.M.A.R.T
Productos Tiempo
(Specific, Measurable, Attainable, Realistic and Timely
14
COMUNICACIÓN DEL PROYECTO
Comunicar el inicio del proyecto a través de:
• Reuniones individuales.
• Reuniones de inicio del proyecto.
• Talleres de inicio del proyecto.
• Una combinación de lo anterior.
La comunicación debe ser abierta, presentada claramente y documentada.

CULTURA DEL PROYECTO

• Comprende normas, creencias, valores y suposiciones compartidas por el equipo del proyecto.
• Puede definirse a través de una declaración de misión, el nombre y logotipo del proyecto, la oficina
o lugar de reunión del proyecto, los protocolos de comunicación, la intranet del proyecto, etc.

OBJETIVOS DEL PROYECTO

• Son las declaraciones de acciones específicas que apoyan las metas del proyecto.
• Deben comenzar siempre con un verbo de acción.
• S.M.A.R.T. (Smart, Measurable, Attainable, Realistic, Timely.)
ESTRUCTURA DE ESTRUCTURA DE
DESGLOSE DE DESGLOSE DEL
OBJETOS (OBS) TRABAJO
Representa los Contiene todas las tareas necesarias agrupadas en unidades manejables y
componentes controlables.
individuales de la
solución y su relación Proyecto de implementación de
un nuevo sistema
jerárquica entre sí.
Entregables de
Entregables del
gestión de
sistema
proyectos

Configuración de
Diseño de la Desarrollo de
Plan de comunicación la infraestructura Requerimientos Casos de prueba Plan de cambio
solución aplicaciones
del sistema

WBS–Desarrollo Plan de
Requerimientos Documentos del Código de
de aplicaciones aseguramiento de
del subsistema diseño aplicaciones
calidad
de ventas

Especificaciones
Guiones de
OBS–Servicio al WP1–Desarrollo Plan de alcance de conversión de
Conversión
de páginas web datos
cliente en línea

WP2-Desarrollo Plan de riesgos

de código de
interfaz de ventas

Programación
ELEMENTOS DE GESTIÓN DE PROYECTOS

Las características generales de la planificación exitosa de proyectos consisten en un

proceso de gestión basado en el riesgo e iterativo por naturaleza.

Fuente: Personas & Técnicas Multimedia SL copyright 2009. Todos los derechos reservados. Usado con autorización.
 ROL DEL AUDITOR SI

Examinar la idoneidad de las siguientes actividades de gestión de proyectos:

• Niveles de supervisión por parte del comité del proyecto/consejo directivo.
• Métodos de gestión de riesgos.
• Gestión de problemas.
• Gestión de costos.
• Procesos de planificación y gestión de las dependencias.
• Proceso de reporte.
• Procedimientos de control de cambios.
• Participación de las partes interesadas.
• Proceso de aprobación.
CASO DE NEGOCIO Y FACTIBILIDAD

19
TÉRMINOS CLAVE
Término clave Definición
Caso empresarial Documentación de las razones para hacer
una inversión de negocio, que se utiliza tanto para apoyar una
decisión empresarial sobre si proceder o no con la inversión y como
una herramienta operacional para soportar la administración de la
inversión a través de su ciclo completo de vida económica
Retorno sobre la Una medida de rendimiento y eficiencia operativos, calculada en su
inversión (ROI) forma más sencilla dividiendo la utilidad neta entre la inversión total
en el período considerado

CASO DE NEGOCIO
Un caso de negocio entrega la información necesaria para que una organización decida si un proyecto
debe proceder.

Permite comparar los costos y los beneficios de negocio y justifica la creación o la continuación de un
proyecto.

A menudo es el primer paso en un proyecto y normalmente se deriva de un estudio de factibilidad.

ESTUDIO DE FACTIBILIDAD

Definir el alcance del proyecto.

Realizar un análisis actual.

Identificar los requisitos en función de las necesidades de las partes interesadas.

Proporcionar un enfoque recomendado.

Evaluar el costo-beneficio del enfoque

Realizar una revisión formal con las partes interesadas.

FASES DEL ESTUDIO DE FUNCIÓN DEL AUDITOR SI DURANTE
FACTIBILIDAD EL ESTUDIO DE FACTIBILIDAD

Definir el alcance del proyecto.

• Revisar la documentación de la fase para
asegurarse de que sea razonable.
• Determinar si toda la justificación de
Realizar un análisis actual. costos/beneficios es verificable y si muestra los
costos previstos y los beneficios esperados.
• Identificar y determinar la importancia crítica de
Identificar los requisitos en función de las necesidades de
las partes interesadas. la necesidad que se desea satisfacer.
• Determinar si se puede alcanzar una solución
con los sistemas ya existentes. En caso
Proporcionar un enfoque recomendado.
contrario, revisar la evaluación de las soluciones
alternativas para verificar si éstas son
razonables.
Evaluar el costo-beneficio del enfoque
• Determinar la idoneidad de la solución elegida.

Realizar una revisión formal con las partes interesadas.

METODOLOGÍAS DE DESARROLLO DE SISTEMAS

23
DESARROLLO DE APLICACIONES DE NEGOCIO
Centrada en la organización
• El objetivo de las aplicaciones orientadas a la organización es recolectar, integrar, almacenar, archivar y
compartir información con los usuarios del negocio y diversas funciones aplicables de soporte con
base en la necesidad de saber.
Centrada en el usuario
• El objetivo de una aplicación centrada en el usuario final es proveer diferentes vistas de los datos
para la optimización de su desempeño. Este objetivo incluye técnicas basadas en Sistemas de
Soporte a la Decisión (DSS) y sistemas de información geográfica (GIS), etc.

TÉRMINOS CLAVE
Término clave Definición

Ingeniería de Uso de paquetes de software que ayudan en el desarrollo de todas las fases de un sistema de información.
software asistida Se proporciona el análisis del sistema, la programación del diseño y la documentación. Los cambios
por computadora introducidos en un gráfico de CASE actualizarán automáticamente todos los demás gráficos relacionados.
(CASE). CASE se puede instalar en una microcomputadora para su fácil acceso.
Ciclo de vida del Las fases implementadas en el desarrollo o adquisición de un software de sistema. SDLC es un enfoque
desarrollo de usado para planear, diseñar, desarrollar, probar e implementar un sistema de aplicación o una modificación
sistemas (SDLC) importante en un sistema de aplicación. Las fases típicas de SDLC incluyen el estudio de factibilidad,
estudio de requerimientos, definición de requerimientos, diseño detallado, programación, prueba,
instalación y revisión posterior a la implementación.
Desarrollo en
24
También conocido como desarrollo tradicional, un ciclo de desarrollo centrado en el procedimiento con
cascada aprobación formal al final de cada nivel.
MODELOS DE SDLC

Existe diversos modelos de desarrollo de

sistemas (SDLC), incluidos:
• Cascada tradicional
• En V (verificación y validación)
• Iterativo

25
MODELOS DE SDLC
El modelo de SDLC de cascada tradicional:
• El más antiguo y el más ampliamente utilizado para desarrollar aplicaciones de negocio.
• Funciona mejor cuando los requisitos son estables y están bien definidos.
• Asegura que los errores potenciales se corrijan lo antes posible y no solo durante la prueba final de aceptación.
• Facilita la determinación de la arquitectura de un sistema de manera relativamente anticipada durante la actividad de
desarrollo.
• Basado en un enfoque secuencial y sistemático de desarrollo de software o sistemas.
• La primera versión que funcione no estará disponible de manera inmediata, hacia el final del ciclo de vida del proyecto.
• Un ambiente cambiante en el negocio puede modificar los requerimientos del cliente/usuario antes de que sean entregados.

El modelo de verificación y validación, llamado a veces modelo V:

• Énfasis en la relación entre las etapas de desarrollo y los niveles de prueba.
• La prueba de la unidad se realiza acto seguido de escribir los programas para validar el diseño detallado.
• La prueba del sistema se relaciona con la especificación arquitectónica del sistema, mientras que la prueba de aceptación del
usuario final se refiere a los requerimientos.
• El auditor de SI puede proveer una evaluación de los métodos y técnicas aplicadas, en las etapas de desarrollo del ciclo de
vida de las aplicaciones del negocio

El enfoque iterativo:
• Es un proceso cíclico en el cual los requisitos del negocio se desarrollan y prueban en iteraciones hasta que toda la aplicación
sea diseñada, construida y probada. Durante cada iteración, el proceso de desarrollo pasa por cada una de las fases, desde
los requisitos hasta las pruebas, y cada ciclo subsecuente mejora el proceso en forma progresiva.
FASES DE SDLC: ÉXITO CRÍTICO DE SDLC
Algunos factores clave para el éxito incluyen:
Fase 1: Estudio de factibilidad

• Productividad
Fase 2: Definición de requisitos
• Calidad
• Valor económico
Fase 3A: Selección y adquisición de
• Servicio al cliente
Fase 3B: Diseño
software
• La principal ventaja de SDLC es que
proporciona plantillas en el que se pueden
colocar los métodos para los requerimientos.
Fase 4A: Configuración Fase 4B: Desarrollo

Fase 5: Implementación y prueba final

Fase 6:
Posterior a la implementación
AUDITOR SI: ROL EN EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS (SDLC)

Cuando se esté revisando el proceso de SDLC, un auditor SI debe obtener documentación de las
diversas fases y asistir a las reuniones del equipo del proyecto para ofrecer asesoramiento al equipo
del proyecto durante todo el proceso de desarrollo del sistema.

Un auditor SI debe también hacer una valoración de la capacidad del equipo del proyecto para
producir resultados claves en las fechas prometidas.

Adicionalmente, debe ser evidente la documentación adecuada y completa de todas las etapas del
proceso de SDLC. Los tipos característicos de documentación pueden incluir, pero no limitarse a lo siguiente:
• Objetivos que definan qué es lo que se va a realizar durante esa etapa.
• Los productos claves por etapa con el personal de proyectos al que se le asignaron responsabilidades
directas sobre estos resultados.
• Cronograma del proyecto con fechas destacadas para la conclusión de los resultados claves.
• Previsión económica por etapa definiendo los recursos y el costo de los recursos que se requieren para
concluir la etapa.
MÉTODOS DE DESARROLLO DE SOFTWARE

Desarrollo ágil

Reingeniería Desarrollo
de software prototipado

Desarrollo de Desarrollo
aplicaciones rápido de
basadas en la aplicaciones
web (RAD)

Desarrollo de
Desarrollo
sistemas
basado en los
Ingeniería orientado a
componentes
inversa objetos
LA FUNCIÓN DEL AUDITOR SI EN LA
REINGENIERÍA DEL CASO EMPRESARIAL
Cuando los auditores de SI revisen los esfuerzos del equipo
de reingeniería de procesos (BPR) de la organización, El auditor SI debe
deben determinar si: proveer también una
• Los esfuerzos de cambio de la organización son consistentes con declaración o
la cultura y el plan estratégico general de la organización. conclusión de
aseguramiento
• El equipo de reingeniería está intentado minimizar cualquier
respecto de los
impacto negativo que el cambio pudiera tener sobre el personal
objetivos de la
de la organización.
auditoría.
• El equipo de gerencia de cambios documentó las lecciones
aprendidas después de terminar el proyecto de BPR/cambio de
procesos.

30
HERRAMIENTAS DE DESARROLLO DE SISTEMAS

Ingeniería de software asistida por computadora (CASE).

• Uso de herramientas automatizadas para asistir en el proceso de desarrollo de software. El
auditor de SI debe ser capaz de reconocer los cambios en el proceso de desarrollo generados
por CASE y puede utilizar CASE como herramienta de auditoría.

Generadores de códigos
• Herramientas que generan un código de programa basado en los parámetros definidos por un
analista de sistemas o basados en los diagramas de flujo de datos/entidades desarrollados por el
módulo de diseño de un producto CASE. El auditor SI debe estar consciente del código fuente
generado por esas herramientas.

Lenguajes de cuarta generación (4GL)

• Lenguajes no procesales con entornos independientes, subconjuntos de lenguaje simples y un
enfoque de banco de trabajo.
FUNCIÓN DEL AUDITOR SI EN LA
ADQUISICIÓN DE HARDWARE
Al realizar una auditoría de esta área, el auditor SI
debe:
• Determinar si el proceso de adquisición comenzó con
una necesidad de negocio y si los requerimientos de
hardware para esta necesidad fueron considerados en
la especificación
• Determinar si se consideraron varios proveedores y si
la comparación entre ellos se realizó de acuerdo con los
criterios mencionados.

32
DESARROLLO DE
INFRAESTRUCTURA/PRÁCTICAS DE ADQUISICIÓN

33
ANÁLISIS DE ARQUITECTURA FÍSICA

Selección de proveedores:

Revisión de Definición
Borrador de
la Análisis y de los Prueba de Entrega de
requisitos
arquitectura diseño requisitos concepto prototipo
funcionales
existente finales
PLANIFICACIÓN DE LA IMPLEMENTACIÓN

• Establecer el proceso de comunicación y determinar las

1. Etapa de adquisición entregas, los contratos y SLA. Se produce la declaración
de requisitos.

• Elaborar un plan de entrega: prioridades, objetivos, hechos

2. Plazo de entrega clave, principios, estrategias de comunicación, indicadores
clave, avances en las tareas clave y responsabilidades.

3. Plan de instalación • Desarrollar y revisar el plan con las partes involucradas.

4. Plan de prueba de • Desarrollar un plan de pruebas que incluya casos de

prueba, especificaciones de requisitos básicos, definición
instalación de procesos y métricas.
TÉRMINOS CLAVE
Término clave Definición
Petición de Documento distribuido a los proveedores de software, solicitándoles que presenten
propuestas (RFP) una propuesta para desarrollar o proporcionar un producto de software.
Definición de Técnica usada en la que los grupos de usuarios afectados definen los requisitos del
requisitos sistema para atender las necesidades definidas. Algunos de estos son requerimientos
relacionados con el negocio, regulaciones y la seguridad, así como los relacionados
con el desarrollo.

FACTORES PARA LA ADQUISICIÓN DE SISTEMAS

• Fecha funcionamiento: cuando se requiere que el sistema esté operativo.
• El costo de desarrollar el sistema en comparación con el costo de comprarlo.
• Los recursos, el personal y el hardware necesarios.
• En un sistema de proveedores, las características de licencia (por ejemplo, renovación anual, perpetua) y
costos de mantenimiento
• Otros sistemas que deberán tener la capacidad de interactuar con el nuevo sistema.
• Compatibilidad con los planes estratégicos de negocio, el apetito de riesgo, los requisitos de
cumplimiento normativo y la infraestructura de TI de la organización.
• Probables requisitos futuros para cambios en la funcionalidad.
ESPECIFICACIONES DEL SISTEMA

Al adquirir un sistema, las especificaciones deben

incluir lo siguiente:
• Descripción de la organización
(centralizada/descentralizada, distribuida,
subcontratada, atendida o no)
• Evaluación de aseguramiento del nivel de robustez en la
seguridad del hardware y software
• Requisitos de procesamiento de la información
• Requisitos de hardware
• Aplicaciones de software del sistema
• Requisitos de respaldo
• Requisitos de adaptabilidad y conversión
• Restricciones del sistema
DEFINICIÓN DE REQUISITOS
La definición de requisitos incluye las descripciones de qué deberá hacer el sistema, cómo será
la interacción usuarios-sistema, las condiciones de operación del sistema y los criterios de
información que el sistema debe satisfacer.

Para completar con éxito una definición de requisitos, el equipo del proyecto completará tareas, como:
• Identificar a las partes interesadas.
• Registrar los requisitos en un formato estructurado y consultar con las partes interesadas.
• Verificar que los requisitos están completos, son consistentes, no ambiguos, verificables,
modificables, comprobables y rastreables.
• Detectar, corregir y resolver conflictos.
• Identificar las restricciones.
PETICIÓN DE PROPUESTAS (RFP)

Escalabilidad e Factibilidad/estabilidad
Producto vs. requisitos
interoperabilidad del Referencias del cliente financiera del
del sistema
producto proveedor

Disponibilidad de
Disponibilidad del Años de experiencia
documentación Soporte del proveedor
código fuente ofreciendo el producto
adecuada y confiable

Número de
Una lista de
instalaciones que usan
aplicaciones recientes Prueba de aceptación
el producto con una
y planificadas para el del producto
lista de usuarios
producto y las fechas
actuales
LA FUNCIÓN DEL AUDITOR SI EN LA FUNCIÓN DEL AUDITOR SI EN LA
ADQUISICIÓN DE SOFTWARE ADQUISICIÓN DE HARDWARE
• Analizar la documentación del estudio de factibilidad • Determinar si el proceso de adquisición
para determinar si la decisión de adquirir una solución comenzó con una necesidad de
fue apropiada (incluida la consideración de negocio y si los requerimientos de
evaluaciones de criterios comunes). hardware para esta necesidad fueron
• Revise la RFP para asegurarse de que cubre los considerados en la especificación
elementos enumerados en esta sección. • Determinar si se consideraron varios
• Determinar si el proveedor seleccionado está proveedores y si la comparación
respaldado por documentación de RFP. entre ellos se realizó de acuerdo con
los criterios mencionados.
• Asistir a presentaciones programadas con agenda y
pilotos de salas de conferencia para asegurar que el
sistema coincide con la respuesta del proveedor a
la RFP.
• Revisar el contrato del proveedor antes de su firma
para asegurarse que incluye los puntos enumerados.
• Asegurarse de que el contrato sea revisado por el
asesor legal antes de que sea firmado.
• Revisar la RFP para asegurarse de que el proveedor
haya incluido las respuestas de seguridad.
IDENTIFICACIÓN DE CONTROL

41
CONTROLES DE APLICACIÓN
Entrada
Aseguran:
• Que sólo datos completos, correctos y válidos son ingresados
y actualizados en un sistema aplicativo.
• Que el procesamiento realice la tarea correcta. Controles
de
• Que los resultados del procesamiento cumplan las expectativas. aplicación

• Que se mantengan los datos. Procesami

Salida ento

CONTROLES DE ENTRADA
Garantizan:

• Que solo se introduzca información válida y autorizada y

• Que estas transacciones solo se procesen una vez.

CLASES DE FIRMA DE AUTORIZACIÓN

La autorización
Firmas en de entrada
formularios Controles de
de lote o acceso en verifica que todas
documentos línea las transacciones
originales
hayan sido
autorizadas y
aprobadas por la
Identificación
del terminal o gerencia.
Contraseñas
de la estación
únicas
de trabajo del
cliente
CONTROLES DE PROCESAMIENTO POR LOTE Y DE BALANCE

Valor
monetario
total
Acuerdos Elementos
informáticos totales

Cuentas de Documentos
control totales

Totales de
Registradores
comprobación
de lotes
(hash totals)
INFORME Y MANEJO DE ERRORES PROCEDIMIENTOS Y CONTROLES DE
PROCESAMIENTO
verifica que solo se acepten datos correctos en Garantizar la confiabilidad del procesamiento
un sistema. Se puede procesar de la siguiente mediante programas de aplicaciones.
manera:

• Rechazar solo operaciones con errores

• Rechazar todo el lote de transacciones

• Mantener el lote suspendido

• Aceptar el lote y marcar las transacciones de

error
PROCEDIMIENTOS DE VALIDACIÓN
Y EDICIÓN DE DATOS
Garantizan que los datos que se ingresen al sistema sean
validados y editados tan cerca como sea posible de su
momento y punto de origen.

• Verificación de secuencias
• Verificación de límites
• Verificación del rango
• Verificación de validez
• Comprobación de razonabilidad
• Búsquedas en tabla
• Verificación de existencia
• Verificación de claves
• Dígito de control
• Verificación de integridad
• Verificación de duplicados
• Verificación de relaciones lógicas
CONTROLES DE PROCESAMIENTO PROCEDIMIENTOS DE CONTROL DE
ARCHIVOS DE DATOS
Garantizar la integridad y exactitud de los datos Garantizan que solo se realice un procesamiento
acumulados. autorizado de los datos almacenados.
• Nuevos cálculos manuales • Reporte de imágenes del antes y el después
• Edición • Informe y manejo de errores de mantenimiento
• Retención de documentación fuente
• Totales de proceso a proceso
• Etiquetado interno y externo
• Controles programados
• Uso de versión
• Verificación de la razonabilidad de los montos
• Seguridad del archivo de datos
calculados
• Verificación uno a uno
• Verificaciones de límites sobre montos
• Entradas pregrabadas
• Conciliación de los totales de los archivos
• Registro de transacciones
• Informes de excepciones • Autorización de la actualización y el mantenimiento
del archivo
• Verificación de paridad
CONTROLES DE SALIDA

• Registro y almacenamiento de formularios de negocio,

sensibles y críticos en un lugar seguro.
Los controles de salida • Generación computarizada de instrumentos de negocio,
proveen garantía de que formularios y firmas.
los datos entregados a • Exactitud, integridad y puntualidad de los informes.
los usuarios serán • Informes generados desde el sistema.
presentados, • Distribución de informes.
formateados y • Compensación y reconciliación.
entregados en una forma • Tratamiento de errores de salida.
consistente y segura. • Retención de informes de salida.
• Verificación de la recepción de los informes.
 ROL DEL AUDITOR SI

Las tareas del auditor SI incluyen las siguientes:

• Identificar los componentes de aplicación significativos y el flujo de transacciones.
• Identificación de las fortalezas del control de aplicaciones, y la evaluación del
impacto de las debilidades de control.
• Desarrollo de una estrategia de prueba.
• Probar los controles para asegurar su funcionalidad y su eficacia.
• Evaluar el ambiente de control para determinar que se hayan alcanzado los
objetivos del control por medio del análisis de los resultados de la prueba y de otras
evidencias de auditoría.
• Considerar los aspectos operativos de la aplicación para asegurar su eficiencia y
eficacia.
DOCUMENTACIÓN DE LOS CONTROLES DE APLICACIÓN

El auditor SI debe revisar la siguiente documentación para comprender el desarrollo

de la aplicación:

Documentos de
Especificaciones
metodología de Cambios de
funcionales del
desarrollo de programa
diseño
sistemas

Documentación
Manuales del
de referencia
usuario
técnica
PROCEDIMIENTOS DE USUARIOS

Segregación Distribución Informes de

de funciones Balanceo de informes actividad

Autorización Control y Revisión y Informes de

para el corrección prueba de la infracciones
ingreso de errores autorización
de acceso y
de las
capacidades

51
IMPLEMENTACIÓN DE
SISTEMAS DE
INFORMACIÓN

52
METODOLOGÍAS DE PRUEBA

53
CLASIFICACIONES DE PRUEBAS

Prueba unitarias
• Prueba la lógica del programa con un programa o módulo en particular.
• Garantizan que la operación interna del programa funciona de conformidad con la especificación.
• Usa un conjunto de casos de prueba que se concentran en la estructura de control del diseño procedimental.

Pruebas de interfaz o de integración

• Una prueba de hardware o de software que evalúa la conexión de dos o más componentes que trasladan
información de un área a otra.
Pruebas del sistema
• Una serie de pruebas diseñadas para asegurar que los programas modificados, objetos, esquema de base de
datos, etc., que colectivamente constituyen un sistema nuevo o modificado, funcionen de manera apropiada.
Pruebas de aceptación final
• Pruebas del sistema que se llevan a cabo durante la fase de implementación y que aplican la metodología de
QA de la organización.
PRUEBAS DE ACEPTACIÓN FINAL

Pruebas de aseguramiento de la Pruebas de aceptación del usuario

calidad (QAT) (UAT)
• Se enfoca en los aspectos • Se enfoca en el aspecto funcional
técnicos de la aplicación. de la aplicación
• Verifica que la aplicación funcione • Se asegura de que el sistema
como se documentó por medio de esté listo para la producción y
pruebas del diseño lógico y la que satisfaga todos los
tecnología misma. requerimientos documentados.
• Garantiza que la aplicación • Realizada en un ambiente seguro
cumpla con las especificaciones de pruebas o que imita al de
técnicas documentadas y producción lo más cerca posible.
entregables. • Las pruebas se escriben desde la
• Implica una participación mínima perspectiva del usuario.
del • Realizadas por el departamento
usuario final. de TI y el usuario final.
• Realizada por el departamento de
TI.
OTROS TIPOS DE PRUEBAS
Tipos de pruebas Descripción

Pruebas alfa y beta La primera etapa, llamada prueba alfa, a menudo se realiza en una versión temprana de la
aplicación del sistema solo por parte de los usuarios dentro de la organización que desarrolla el
software (es decir, prueba de sistemas). La segunda etapa, llamada prueba beta, una forma de
prueba de aceptación del usuario, generalmente involucra a un número limitado de usuarios
externos e implica una exposición al mundo real.
Pruebas piloto Una prueba preliminar que se enfoca en aspectos específicos y predeterminados de un sistema,
como la prueba de concepto.
Pruebas de caja blanca Enfoque de pruebas que utiliza el conocimiento de la implementación subyacente de un
programa/módulo y los intervalos del código para verificar su comportamiento esperado.
Pruebas de caja negra Enfoque de prueba que se centra en la funcionalidad de la aplicación o producto y no requiere el
conocimiento de los intervalos de código
Pruebas de Prueba la funcionalidad del sistema contra los requisitos detallados para garantizar que el software
función/validación que se ha construido está de acuerdo con los requisitos del cliente.
Pruebas de regresión Es el proceso de volver a ejecutar una porción de un escenario de pruebas o plan de pruebas para
asegurar que los cambios o las correcciones no hayan introducido nuevos errores.
Pruebas paralelas El proceso de introducir datos de prueba en dos sistemas, el sistema modificado y un sistema
alternativo (posiblemente el sistema original) y comparar los resultados.
Pruebas de sociabilidad Pruebas para confirmar que el nuevo sistema o el modificado puede operar en su ambiente sin
impactar de manera adversa los sistemas existentes.
PRUEBAS DE SOFTWARE

Las pruebas determinan que se hayan validado los

requerimientos del usuario, que el sistema esté
funcionando como se anticipó y que los controles
internos trabajen como se pretendía.
Los dos enfoques principales de las pruebas
incluyen:
• Ascendente: Comienza con unidades individuales y
trabaja en dirección ascendente hasta que se haya
realizado una prueba completa del sistema.
• Descendente: Comienza a probar el sistema completo y
trabaje en dirección descendente hasta llegar a las
unidades individuales.
PRUEBAS DE APLICACIÓN DEL SISTEMA

Imagen instantánea Instalación de prueba integrada

Mapeo (mapping) Simulación paralela
Rastreo y etiquetado Programas de selección de
transacciones
Paquete/datos de prueba
Colección de datos de auditoría
Evaluación de sistemas utilizando un integrada
caso base
Registros extendidos
Operación paralela
PRUEBA DE INTEGRIDAD DE LOS DATOS

Pruebas de integridad relacional

• Rutinas de validación de datos realizadas a nivel de elementos de

datos y de registros.

Pruebas de integridad referencial

• Definir la existencia de relaciones entre entidades en diferentes

tablas de una base de datos que debe ser mantenida por el DBMS.
ROL DEL AUDITOR SI
Durante la prueba, el auditor SI debe realizar las siguientes actividades:
• Revisar el plan de prueba, los informes de errores, la documentación del usuario final y los
procedimientos utilizados para asegurarse de que estén completos y sean precisos.
• Efectuar una reconciliación de los totales de control y de los datos convertidos.
• Verificar el procesamiento cíclico y los informes críticos para mayor precisión.
• Entrevistar a los usuarios finales del sistema para verificar si entienden los nuevos métodos, los
nuevos procedimientos y las instrucciones de operación.
• Verificar que la seguridad del sistema funcione como se diseñó.
• Revisar los resultados de las pruebas paralelas y las pruebas de aceptación del usuario.
• Revisar los planes de las pruebas de unidad y del sistema para determinar si se planifican y
realizan pruebas de los controles internos.
• Revisar las pruebas de aceptación por parte de los usuarios y asegurarse de que el software
aceptado ha sido entregado al equipo de implementación. El proveedor no debería ser capaz de
reemplazar esta versión.
• Revisar los procedimientos utilizados para registrar y hacer seguimiento del reporte de errores.
GESTIÓN DE CONFIGURACIÓN Y VERSIONES

61
GESTIÓN DE CONFIGURACIÓN Y VERSIONES

Los cambios en los sistemas de TI deben evaluarse ,

planificarse, probarse, documentarse y comunicarse
cuidadosamente para minimizar las consecuencias no
deseadas en los procesos del negocio. El apoyo de la
gerencia en este
El auditor SI debe ser consciente de las herramientas proceso es
disponibles para gestionar la configuración, los cambios y fundamental para el
éxito.
la liberación de las versiones, así como los controles
implementados, a fin de garantizar la segregación de
funciones (SoD) entre el personal de desarrollo y el
entorno de producción.

62
APOYO DE LA GESTIÓN DE CAMBIOS

Las herramientas de gestión de configuración respaldarán la

gestión de cambios y la gestión de liberación a través de:
• Identificación de objetos afectados por un cambio propuesto para Para implementar el
ayudar en la evaluación del impacto (funcional, operativo y de proceso de gestión de
seguridad). configuración, se
desarrolla y sigue un
• Registro de elementos de configuración afectados por cambios plan de gestión de
autorizados. configuración y
• Implementación de cambios en conformidad con los registros de procedimientos
autorización. operativos.

• Registro de cambios de elementos de la configuración cuando se

implementan los cambios y nuevas versiones autorizados.
• Registrar niveles mínimos relacionados con nuevas versiones a
las cuales volver (con consecuencias conocidas), por ejemplo, si
fallara un cambio implementado.
• Preparación de una versión para evitar los errores humanos y
63

costos de los recursos.

MIGRACIÓN DE SISTEMAS, IMPLEMENTACIÓN DE
INFRAESTRUCTURA Y CONVERSIÓN DE DATOS

64
MIGRACIÓN DE DATOS
El proceso de conversión de datos debe proveer algunos medios, tales como pistas de auditoría y
registros (logs), que permitan verificar la exactitud e integridad de los datos convertidos.

Esta verificación de exactitud e integridad se pudiera realizar mediante una combinación de procesos
manuales, utilidades del sistema, herramientas de proveedores y aplicaciones especiales de un solo
uso.

PLANIFICACIÓN DE LA MIGRACIÓN
El proyecto de migración de datos debe planificarse con cuidado y debe utilizar metodologías y
herramientas apropiadas para minimizar el riesgo de:
• Interrupción de las operaciones de rutina.
• Violación de la seguridad y la confidencialidad de los datos
• Conflictos y disputas entre las operaciones heredadas y las migradas
• Inconsistencias y la pérdida de integridad de los datos durante el proceso de migración

65
PLANIFICACIÓN DE LA IMPLEMENTACIÓN Mediante:
• Después de una prueba exitosa, el sistema se implementa de
acuerdo con los procedimientos de control de cambios de la • Establecer roles.
organización.
• Adquirir y desarrollar las
• Se debe preparar un plan de implementación con la antelación habilidades necesarias.
necesaria a la fecha de implementación.
• Distribuir la carga de trabajo
• Cada paso de la configuración del entorno de producción debe en función de los roles y
documentarse, incluyendo quién será responsable, cómo se responsabilidades.
verificará el paso y el procedimiento de retrocesión.
• Crear un plan de transición
• Implementación de un escenario de retrocesión (al estado previo). por etapas.

TÉCNICAS DE CAMBIO (PASO A PRODUCCIÓN O TRANSICIÓN)

• Cambio en paralelo: ejecutar el viejo sistema, luego el viejo y el nuevo en paralelo y, finalmente, solo el
nuevo después de haber ganado la confianza para trabajar con el nuevo sistema.
• Cambio en etapas: primer módulo del sistema antiguo se elimina gradualmente utilizando el primer
módulo del sistema más nuevo y así sucesivamente el resto de módulos.
• Cambio abrupto: El sistema viejo es reemplazado por el nuevo en una fecha y hora de corte y el viejo
sistema es descontinuado una vez que el cambio al sistema nuevo tiene lugar.
IMPLEMENTACIÓN DEL SISTEMA

El auditor SI debe verificar que se hayan obtenido las firmas de aprobación

apropiadas antes de la implementación y realizar lo siguiente:
• Revisar los procedimientos programados para agendar y poner en funcionamiento
elnuevo sistema junto con los parámetros del sistema usados para la ejecución del
cronograma de producción.
• Revisar toda la documentación del sistema para asegurar su integridad y para
asegurarse de que la totalidad de las actualizaciones recientes, a partir de la fase de
pruebas, hayan sido incorporadas.
• Verificar todas las conversiones de datos para asegurarse de que estén correctas y
completas antes de implementar el sistema en producción.

67
PROCEDIMIENTOS DE CAMBIOS AL SISTEMA Y
PROCESO DE MIGRACIÓN DE PROGRAMAS
Una vez finalizada la implementación, el auditor SI debe considerar lo Además, el auditor SI
siguiente: debe revisar todo el
• El uso y la existencia de una metodología para autorizar, priorizar y rastrear los proceso de gestión de
requerimientos de cambios al sistema solicitados por el usuario. cambios para posibles
• Si los procedimientos de cambio de emergencia son considerados en los manuales de mejoras en
operación.
reconocimiento,
• Si el control de cambios es un procedimiento formal tanto para el usuario como para los tiempo de respuesta,
grupos de desarrollo.
efectividad de
• Si el registro de control de cambios asegura que todos los cambios presentados fueron
atendidos.
respuesta, y
satisfacción del
• La satisfacción del usuario con la rotación —tiempo y costo— de las solicitudes de
cambio. usuario con el
• Qué tan adecuadas son las restricciones de seguridad de acceso sobre las fuentes y los
proceso.
módulos ejecutables en producción.
• Qué tan adecuados son los procedimientos de la organización para efectuar los cambios
de urgencia en programas.
• Qué tan adecuadas son las restricciones de seguridad de acceso sobre el uso de las
credenciales de inicio de sesión de emergencia.
68
POSTERIOR A LA IMPLEMENTACIÓN
Las revisiones posteriores a la implementación se llevan a cabo normalmente después de que el proyecto
ha estado en uso el tiempo suficiente para darse cuenta de sus costos, beneficios y para medir el éxito
general del proyecto y su impacto en las unidades de negocio.

Las métricas incluyen:

• Costo total de propiedad (TCO)
• Retorno sobre la inversión (ROI)

CIERRE DEL PROYECTO:

Los proyectos tienen una vida finita. Una vez cerrado el proyecto, se entrega a los usuarios finales.

Durante el cierre del proyecto:

• Asignar temas pendientes.
• Asignar la custodia de los contratos.
• Archivar o entregar documentación.
• Conversar sobre las lecciones aprendidas.
• Realizar una revisión posterior al proyecto.
CIERRE DEL PROYECTO

Asignar temas pendientes.

Asignar la custodia de los contratos.

Archivar o entregar documentación.

Conversar sobre las lecciones aprendidas.

Realizar una revisión posterior al proyecto.

CERTIFICACIÓN Y ACREDITACIÓN

La certificación es un proceso mediante el cual un evaluador realiza una evaluación

exhaustiva basado en los estándares de la gerencia y controles operativos y técnicos
para determinar el nivel de cumplimiento.
• El objetivo es determinar en qué medida los controles se aplican correctamente, funcionan según
lo previsto y producen el resultado deseado.

La acreditación autoriza la operación de un sistema de información aceptando así el

riesgo. Un alto funcionario acepta la responsabilidad y es totalmente responsable de
cualquier impacto adverso.
MANTENIMIENTO DEL SISTEMA

Después de la implementación, un sistema entra en

la etapa de desarrollo o mantenimiento en curso.
Las prácticas de mantenimiento de sistemas se
refieren principalmente al proceso de gestión del
cambio en los sistemas de aplicaciones, mientras
mantiene la integridad del código fuente y los
ejecutables de la aplicación.
Es necesario que exista un proceso estándar de
gestión del cambio para registrar y realizar los
cambios, que normalmente se establece durante la
fase de diseño del proyecto.
ROL DEL AUDITOR SI
Determinar si se alcanzaron los objetivos y requisitos del sistema.
Determinar si se está midiendo y analizando los beneficios de costos
identificados en el estudio de factibilidad y si se los informa a la gerencia con
exactitud.
Revisar las solicitudes de cambio a programas para valorar el tipo de cambios
que requiere el sistema.
Revisar los controles integrados en el sistema para asegurarse de que estén
operando en conformidad con el diseño.
Revisar los registros de error de operación para determinar si hay algún
problema de recursos o de operación inherente en el sistema.
Revisar los controles de balance de entrada y salida y demás informes para
verificar que el sistema esté procesando los datos correctamente.
PREGUNTAS DE PRÁCTICA

74
 PREGUNTA DE PRÁCTICA

La razón para el establecimiento de un alto o un

punto de congelamiento en el diseño de un
nuevo sistema es:
A. evitar más cambios a un proyecto en proceso.
B. indicar el punto en el que el diseño debe
completarse.
C. requerir que los cambios después de ese punto
sean evaluados en su rentabilidad.
D. proporcionar al equipo de gestión de proyectos
un mayor control sobre el diseño del proyecto.

75
 PREGUNTA DE PRÁCTICA

Durante la auditoría de un paquete de

software adquirido, un auditor SI descubre
que la compra del software se basó en
información obtenida a través de Internet, en
lugar de basarse en respuestas a una petición de
propuestas. El auditor SI PRIMERO debería:
A. probar el software para su compatibilidad con el
hardware existente.
B. realizar un análisis de brechas.
C. revisar la política de concesión de licencias.
D. asegurarse que el procedimiento haya sido
aprobado.

76
 PREGUNTA DE PRÁCTICA

Las fases y resultados de un proyecto de ciclo de

vida del desarrollo de sistemas deben
determinarse:
A. durante las etapas iniciales de planificación del
proyecto.
B. después que la planificación temprana se haya
completado, pero antes de que el trabajo haya
comenzado.
C. durante las etapas de trabajo, basándose en los
riesgos y exposiciones.
D. solo después de que se hayan identificado todos
los riesgos y exposiciones y el auditor SI haya
recomendado los controles adecuados.

77
 PREGUNTA DE PRÁCTICA

Idealmente, las pruebas de estrés deben llevarse

a cabo en un:
A. entorno de prueba usando los datos de prueba.
B. entorno de producción usando cargas de trabajo
en vivo.
C. entorno de pruebas usando cargas de trabajo en
vivo.
D. entorno de producción utilizando los datos de
prueba.

78
 PREGUNTA DE PRÁCTICA

El control de cambios para los sistemas de

aplicación de negocio que se están desarrollando
utilizando prototipos podría complicarse debido
a:
A. el carácter iterativo del uso de prototipos.
B. el rápido ritmo de los cambios en los
requerimientos y el diseño.
C. el énfasis en los informes y pantallas.
D. la falta de herramientas integradas.

79
 PREGUNTA DE PRÁCTICA

El MEJOR momento para que un auditor SI

evalúe las especificaciones de control de un
nuevo paquete de software de aplicación que
está siendo considerado para su adquisición es
durante:
A. la fase de pruebas internas de laboratorio.
B. las pruebas y antes de la aceptación del usuario.
C. el proceso de recopilación de requerimientos.
D. la etapa de implementación.

80
REPASO DEL DOMINIO 3

Como auditor SI, ahora debería poder:

• Evaluar si el caso de negocio de los cambios propuestos a los sistemas de
información cumple con los objetivos de negocio.
• Evaluar las políticas y prácticas de gestión de proyectos de la organización.
• Evaluar los controles en todas las etapas del ciclo de vida del desarrollo de
sistemas de información.
• Evaluar la preparación de los sistemas de información para su
implementación y migración a producción.
• Realizar revisiones posteriores a la implementación de los sistemas para
determinar si se cumplen con los entregables, los controles y los
requerimientos del proyecto.
• Evaluar las políticas y prácticas de gestión de cambios, configuración,
versiones y parches.