UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES

“UNIANDES”

SEMESTRE MAYO 2020 – SEPTIEMBRE 2020

IDENTIFICACION

Facultad: Sistemas Mercantiles

Carrera: Ingeniería en Sistemas
Materia: Auditoria Informatica
Semestre: Octavo
Docente: Ing. Rodrigo Aguilar
Integrante: Javier Najamtai.

Fecha: 03 de Julio de 2020

AUDITORIA AL DESARROLLO, ADQUISICIÓN YMANTENIMIENTO DE
SISTEMAS DE INFORMACIÓN
DESCRIPCION Las empresas a menudo realizan una gran inversión monetaria
y asignan numerosos recursos humanos para el desarrollo, adquisición y mantenimiento
delos sistemas. Por lo tanto, los mismos se convierten en bienes que deben
ser protegidos y controlados.
ABORDAJE METODOLOGICO Seguimiento en todas las fases de SDLC (Software
Development Life Cicle).Incorporación de la función de Control de Calidad en las
distintas fases. Verificación de separación real de ambientes de procesamiento
(Producción y Prueba).
RESULTADOS QUE SE OBTIENEN Integridad en los sistemas aplicativos.
Aseguramiento de la calidad de los sistemas. Mejora de los procedimientos de puesta en
producción de aplicaciones informáticas. Transparencia en las decisiones de compra de
soluciones de sistemas de información
PAPEL DEL AUDITOR EN LA ADMINISTRACIÓN DEL PROYECTO
ORGANIZACIÓN Y ADMINISTRACION
Deberá garantizarse la mejor infraestructura del área de sistemas con el fin de que sus
servicios se presten con calidad y efectividad, teniendo presente la ubicación y estructura
organizacional que le permita brindar el apoyo necesario a todas las unidades de la
entidad, el aseguramiento de localidad, la conformación de comités de apoyo,
definición de políticas, funciones y responsabilidades; así como la asignación de
personal competente y su debida capacitación.
Para lograr lo anterior, se requiere de planeamiento de la oficina de servicios de
información; políticas, estándares y procedimientos; responsabilidades organizacionales
y administración de personal; aseguramiento de calidad de los servicios de información;
la función de auditoría interna requerimientos externos.
A fin de asegurar su contribución en la consecución de los objetivos organizacionales, la
oficina de servicios de información debe tener planes a largo y corto plazo.
Estos planes deben ser consistentes con los objetivos organizacionales. Las políticas,
estándares y procedimientos sirven de base para el planeamiento de la administración,
control y evaluación de sus actividades.
La calidad de los servicios brindados por la oficina de servicios de información debe
asegurarse estableciendo una función separada dentro de la misma, dedicada a mantener
los estándares establecidos de calidad. Como complemento a otros elementos de control,
la función de auditoría interna se debe establecer con la suficiente competencia técnica,
independencia y autoridad para conducir revisiones objetivas a los controles en sistemas
de información, así como para preparar y emitir reportes de sus hallazgos y
recomendaciones para elevar los servicios de los sistemas de información (Fairley, s.f.).
AUDITANDO LA ORGANIZACIÓN Y LA ADMINISTRACIÓN:
1. Verificar las funciones del área
a) Documentos que contengan la especificación de las funciones
b) Que esos documentos estén aprobados y que se lleven a cabo
2. Verificar que exista el organigrama del área, la descripción de puestos y el personal
que ahí labora.
a) Manual de la organización*Relaciones entre los puestos, el organigrama y el
personal
b) Procedimientos de promoción
3. ¿Existe un plan estratégico del área?
a) Debe ser claro, preciso, real y práctico
b) Debe ser revisado y actualizado regularmente
c) Debe ser difundido
4. Plan de sistemas
a) Propuestas y aprobación de proyectos
b) b)Desarrollo de sistemas
c) Calendarización
d) Asignación de presupuestos y tiempos
e) Documentación
5. Presupuestos-> asignados-> se cumple
6. Procedimientos de contratación, formación, abandono de puestos, rotación,
ideas/sugerencias
7. Biblioteca8. Utilización de herramientas según el plan de sistemas
9. Creación y utilización de estándares para actividades principales y diseño de sistemas
a) Análisis
b) Diseño
c) Programación ( triggers...)
d) Manuales) Modificaciones
10. Existencia de un método para estimar los tiempos de las fases del proyecto
(correcto, practicable y ajustable)
11. Registro de problemas que se producen en los proyectos
12. Existencia de protocolos de contratación de outsourcing
13. Verificar las relaciones externas del área (proveedores, ajustadores, técnicos,
corporativos, departamentos, etc.)
FASES DE SDLC/ADQUISICIÓN/MANTENIMIENTO DESCRIPCION
Las empresas a menudo realizan una gran inversión monetaria y asignan
numerosos recursos humanos para el desarrollo, adquisición y mantenimiento delos
sistemas. Por lo tanto, los mismos se convierten en bienes que deben ser
protegidos y controlados (JP, 2018).
ABORDAJE METODOLOGICO
Seguimiento en todas las fases de SDLC (Software Development Life
Cicle).Incorporación de la función de Control de Calidad en las distintas fases.
Verificación de separación real de ambientes de procesamiento (Producción y Prueba).
RESULTADOS QUE SE OBTIENEN
Integridad en los sistemas aplicativos. Aseguramiento de la calidad de los sistemas.
Mejora de los procedimientos de puesta en producción de aplicaciones informáticas.
Transparencia en las decisiones de compra de soluciones de sistemas de información
PRÁCTICAS DE ADQUISICIÓN Y DESARROLLO DE SI
Se dividen en tres etapas:
APROBACIÓN.
1. Documentación de aprobación (objetivos, alcance y áreas)
2. Estudio de factibilidad
3. Responsable o Director del Proyecto
4. El proyecto debe ser catalogado
5. Determinación del ciclo de vida
6. Elección del equipo técnico
PLANIFICACION
1. Elaborar el plan del proyecto
2. Elaborar mecanismos de resolución de problemas
3. Mecanismos de control de cambios y reajustes
4. Mecanismos de seguimientos de los tiempos por tarea, fase o proyecto
5. Seguimiento de las etapas del ciclo de vida
6. Mecanismos de finalización para liberar documentación y recursos y hacer la
evaluación del proyecto
DEFINICIÓN DE REQUERIMIENTOS
Para el desarrollo efectivo de los sistemas de información automatizada
deberán cumplirse procedimientos establecidos con relación a la metodología del ciclo
de vida del desarrollo de sistemas; las etapas a considerar deben ser: iniciación de
proyectos, estudio de factibilidad, análisis, diseño, desarrollo e implementación,
operación, mantenimiento, y plan de revisión posterior a la implantación por parte
del nivel gerencial competente. Para el desarrollo de sistemas se debe contar con el
involucramiento del departamento usuario en la identificación de la naturaleza general y
el enfoque del proyecto de desarrollo de sistemas. Los requerimientos de información a
ser satisfechos por los sistemas nuevos o modificados, deben ser definidos
cuidadosamente en forma escrita y el desarrollo de la solución propuesta debe ser
aprobado antes de que el proceso inicie.
Análisis de requerimientos del sistema:
a. Verificar la participación de todas las áreas y personas relacionadas con el
sistema
b. Verificar que se tomó en cuenta a las personas indicadas y se les aplicaron las
pruebas correctas
c. Debe de existir una documentación del sistema actual y los problemas asociados
con el mismo
d. Definir las diferentes alternativas de construcción

ESTUDIO DE FACTIBILIDAD
Es importante elaborar un estudio tecnológico de viabilidad en el cual se contemplen
distintas alternativas para alcanzar los objetivos del proyecto acompañados de un análisis
costo-beneficio para cada una de las opciones. Se debe considerar entre estas alternativas
la posibilidad de no llevar a cabo el proyecto (no siempre está justificada la implantación
de un sistema de bases de datos) así como la disyuntiva entre desarrollar y comprar (en la
práctica, a veces nos encontramos con que se ha desarrollado una aplicación que ya existía
en el mercado cuya compra hubiese supuesto un riesgo menor, asegurándonos incluso
una mayor calidad a un precio inferior)
Los objetivos de control exigen que para todo sistema que se diseñe, debe
realizarse un estudio de factibilidad, previa definición de requerimientos, y paracada una
de las opciones revisadas, sugeridas y evaluadas, que comprenda almenos tres
factibilidades:
Factibilidad Tecnológica
Que la tecnología seleccionada funcionará de manera correcta y adecuada, y sin
menoscabo del sistema, una vez puesto en operación y por la vida del
mismo. Que la aplicación soportará cambios sustanciales en la tecnología sin
tener que realizar modificaciones importantes en él.
Factibilidad Operacional
Que el sistema una vez puesto en operación funcionará de acuerdo con los criterios
bajo los cuales se diseñó y que no ofrecerá problemas de carácter técnico ni
administrativo.
Factibilidad Económico / Financiera
Que los beneficios (tangibles e intangibles) y ahorros superen a los costos; que los índices
financieros que se calculen sean aceptables, dé acuerdo con políticas y estándares
generales y específicos; que el proyecto tenga contenido económico y esté contemplado
en el presupuesto respectivo.
Como mínimo deben calcularse las siguientes razones:
1. Tasa Interna de Retorno
2. Valor Neto Presente
3. Período de Recuperación
4. Y, el total de los beneficios netos.
Dependiendo de los resultados de este estudio se determinará si se continúa o no con el
proyecto.
ADQUISICIÓN DE SOFTWARE
ANALISIS DE CONTRATOS INFORMATICOS
DESCRIPCION
Antes de adquirir algún tipo de software o servicio informático es necesario entender no
sólo la parte legal del contrato sino también los aspectos técnicos del mismo.
ABORDAJE METODOLOGICO
Evaluación específica de los productos (Software, Hardware, Servicios) a entregar por el
proveedor. Definición de fechas y pautas de cumplimiento de los servicios contratados.
RESULTADOS QUE SE OBTIENEN
Mejora en las negociaciones. Optimización de las contraprestaciones de servicios
informáticos. Participación en la redacción de cláusulas
El proceso de adquisición y mantenimiento de infraestructura tecnológica provee las
plataformas adecuadas para soportar las aplicaciones del negocio. Permite definir
consideraciones específicas de requerimientos funcionales y operativos y una
implantación por fases con hitos claros.
Se deben considerar: la disponibilidad de la tecnología, la dirección de su evolución, las
políticas de seguridad, el ajuste de los procedimientos a la instalación y la flexibilidad.
Es importante la integridad, peor han de prevalecer eficacia y eficiencia.
INGENIERIA DE SOFTWARER
ichard E. FairleyMc.
Graw Hill
La estimación de costos de un producto de programación es una de las más difíciles y
erráticas tareas, es complicado hacer estimaciones exactas durante la fase de planeación
de un desarrollo debido a la gran cantidad de factores desconocidos en ese momento. Sin
embargo, la práctica normal en los contratos implica un firme compromiso
monetario como parte del estudio de factibilidad. Lo anterior, aunado a la naturaleza
competitiva de este negocio, es un factor que contribuye a los retrasos de entrega y
sobregiro en presupuesto tan comunes en los proyectos de programación.
Reconociendo este problema, algunas organizaciones utilizan una serie de estimadores de
costos; se prepara un estudio preliminar durante la fase de planeación y se presenta en la
revisión de la factibilidad del proyecto. La estimación mejorada se muestra en las
revisiones de los requisitos de programación y la estimación final se presenta durante la
revisión preliminar del diseño. Cada estimación es un refinamiento obtenido como
resultado de las actividades de trabajo desarrolladas adicionalmente; algunas veces,
varias opciones del producto, con sus respectivos costos, se exhiben en las
revisiones; lo anterior permite que el cliente escoja una solución adecuada dentro de las
posibles soluciones.
En ocasiones los clientes financian las fases de análisis y de diseño preliminar en
contratos separados para poder alcanzar estimaciones exactas en cuanto a costo y tiempo
de entrega. Los contratos para análisis y diseño preliminar a veces se otorgan
a diversas empresas de programación por parte del cliente, quien escoge después la
organización que más se ajuste con base a un concurso del análisis y diseño preliminar
para que se desarrolló el producto.
Factores principales que influyen en el costo de software:
1. Capacidad del programador
2. Complejidad del producto
3. Tamaño del programa
4. Tiempo disponible5. Confiabilidad requerida
5. Nivel Tecnológico
Para la adquisición del software se debe
1. Comprobar que todos los lenguajes, herramientas, compiladores, etc., estén
homologados.
2. Comprobar que existan mecanismos de control en la adquisición de software
a) Adquisiciones
*Productividad
* Portabilidad
* Transición de los productos actuales
* Solvencia del proveedor
* Compatibilidad con el entorno actual
* Protocolos de comunicación
* Riesgos al cambio
3. Informar al personal de los nuevos productos
4. Contar con catálogos y manuales de los productos
5. Registro de fallas e información importante de los productos
6. Registro de pruebas a nivel tecnológico
7. Reutilización de software
a) librerías
b) clases
c) programas tipo
d) componentes
DISEÑO DETALLADO
INGENIERIA DE SOFTWARE
Richard E. FairleyMc.
Graw Hill
En esta fase se llevarán a cabo los diseños lógico y físico de la base de datos, por lo que
el auditor tendrá que examinar si estos diseños se han realizado correctamente;
determinando si la definiciónde los datos contempla además de su estructura, las
asociaciones y las restricciones oportunas, así como las especificaciones de
almacenamiento de datos y las cuestiones relativas a la seguridad. El auditor
tendrá que tomar una muestra de ciertos elementos (tablas, vistas, índices) y comprobar
que su definición es completa, que ha sido aprobada por el usuario y que
el administrador de la base de datos participó en su establecimiento
Es importante que la dirección del departamento de informática, los usuarios e incluso,
en algunas ocasiones, la alta dirección, aprueben el diseño de los datos, al igual que el de
las aplicaciones
Una vez diseñada la BD, se procederá a su carga, ya sea migrando datos de un soporte
magnético introduciéndolos manualmente
Las migraciones o conversiones de sistemas, como el paso de un sistema de archivos a
uno de bases de datos, o de un tipo de SGBD (de jerárquico a relacional), entrañan un
riesgo muy importante por lo que deberán estar claramente planificadas para evitar
pérdida de información y la transmisión al nuevo sistema de datos erróneos. También se
deberán realizar pruebas en paralelo, verificando que la decisión real de dar por terminada
la prueba en paralelo se atenía a los criterios establecidos por la dirección y que se haya
aplicado un control estricto de la corrección de errores detectados en esta fase.
Por lo que respecta a la entrada manual de datos, hay que establecer un conjunto de
controles que aseguren la integridad de los mismos. A este respecto, cabe destacar
que las declaraciones escritas de procedimientos de la organización referentes a la
entrega de datos a ser procesados deben asegurar que los datos se autorizan, recopilan,
preparan, transmiten, y se comprueba su integridad de forma apropiada.
También es aconsejable que los procedimientos y el diseño de los documentos fuentes
minimícenlos errores y las omisiones, así como el establecimiento de unos
procedimientos de autorización de datos.
El Diseño
* El entorno tecnológico debe estar definido, ser claro y preciso
* Se debe empezar ka descomposición modular
* Diseñar la estructura física de los datos
* Diseñar el plan de prueba de los módulos por separado
PROGRAMACION
Se debe:
 Verificar que la construcción de los módulos se haga de acuerdo a los
requerimientos delos usuarios, a los estándares y al plan del proyecto
 Que se utilicen técnicas de programación adecuadas
 El entorno de desarrollo debe ser el adecuado y de acuerdo a lo especificado en el
análisis
 Se debe programar, probar y documentar cada uno de los componentes del sistema
 Deben hacerse pruebas de integración
 Se deben especificar los perfiles y capacitación de los usuarios
 Se deben especificar los recursos materiales necesarios para la integración del
sistema y el usuario
Los lenguajes de programación son los vehículos dotacionales que se usan para
instrumentar productos de la programación. Las características disponibles en el lenguaje
de instrumentación ejercen una fuerte influencia sobre la estructura arquitectónica y los
detalles algorítmicos escritos en ese lenguaje.
PRUEBAS
INGENIERIA DE SOFTWARE
Richard E. FairleyMc.
Graw Hill
Los planes de prueba son un importante, pero a menudo pasado por alto, producto del
diseño de la programación. Un plan de prueba prescribe varias clases de actividades que
se efectuarán para demostrar que el producto de programación cumple con sus requisitos.
El plan de prueba específica los objetivos de las pruebas, los criterios de realización de
pruebas, el plan de integración del sistema, métodos a utilizarse en módulos
particulares, y los casos particulares de prueba a utilizarse.
Hay cuatro tipos de pruebas que un producto de programación debe satisfacer:
funcionales, de desempeño, de tensión y estructurales. Las pruebas funcionales y de
desempeño se basan en las especificaciones de requisitos; se diseñan para demostrar que
el sistema satisface sus requisitos. Por lo tanto, el plan de prueba sólo puede ser tan bueno
como sean los requisitos, los que a su vez deben expresarse en términos cuantificables,
verificables.
IMPLANTACIÓN
INGENIERIA DE SOFTWARE
Richard E. FairleyMc.
Graw Hill
Comprendería todas las actividades para conseguir el funcionamiento adecuado del
elemento en cuestión:
 Planificación. Procedimiento general del suministrador adaptado a la instalación
concreta.
 Documentación. Inventario de componentes del elemento y normas de
actualización.
 Parametrización. Valores de parámetros del sistema en función del resto de
elementos planificados
 Pruebas. Verificaciones a realizar y sus resultados
Especificaciones de funcionamiento
Verificar que existan o se elaboren los modelos lógicos de procesos y de datos
 Que sean coherentes y entendible
 Que sigan los estándares del plan de sistemas
 Diccionario de datos* Interfaces con los usuarios
 Requisitos de seguridad
 Especificación de las pruebas y su duración
Implantación
 Se deben realizar las pruebas del sistema que se especificaron en el análisis
 El sistema debe ser aceptado completamente por los usuarios antes de ser
explotado
 Se deben instalar todos los procedimientos de explotación necesarios
 Se coordinará la explotación del sistema anterior y el nuevo
 Debe de existir el documento de implantación por parte de usuarios
 Debe registrarse el trabajo de los usuarios con el sistema
 Deberán elaborarse y ponerse en marcha los mecanismos de mantenimiento del
sistema
REVISIÓN DE LA POST-IMPLANTACIÓN
INGENIERIA DE SOFTWARE
Richard E. FairleyMc.
Graw Hill
Aunque en bastantes organizaciones no se lleva a cabo, por falta de tiempo y recursos, se
debería establecer el desarrollo de un plan para efectuar una revisión post-implantación
de todo sistema nuevo o modificado con el fin de evaluar si:
  Se han conseguido los resultados esperados
 Se satisfacen las necesidades de los usuarios
 Los costos y beneficios coinciden con los previstos
PRACTICAS DE MANTENIMIENTO DE SI
INGENIERIA DE SOFTWARE
Richard E. FairleyMc.
Graw Hill
Comprendería el conjunto de acciones necesarias para la puesta al día del elemento, así
como la asistencia de terceros para la consecución de dicha puesta al día y la asistencia a
prestar a otros colectivos (desarrolladores, por ejemplo) para facilitar información
necesaria sobre el mismo sistema y sus herramientas para su mejor utilización.
 Planificación. Control del periodo de garantía y comienzo del mantenimiento del
elemento
 Documentación. Procedimiento para contactar con el soporte
 Parametrización. Adaptación de los parámetros del sistema en función
de nuevos requerimientos o como resultado de nuevas versiones o resolución de
incidencias.
 Pruebas. Verificaciones de los cambios o adaptaciones realizadas.
DOCUMENTACIÓN DEL SISTEMA
INGENIERIA DE SOFTWARE
Richard E. FairleyMc.
Graw Hill
DOCUMENTACIÓN DE APOYO
Las especificaciones de requisitos, documentación de diseño, planes de prueba, manuales
de usuario, instrucciones de instalación y los reportes de mantenimiento son
ejemplos de documentación de apoyo. Estos documentos son los productos que
resultan del desarrollo y mantenimiento sistemático de la programación. Un enfoque
sistemático al desarrollo de la programación garantiza que los documentos de apoyos
desarrollen de una manera ordenada, y que esos documentos se encuentren
disponibles cuando se necesiten. En el enfoque adecuado para el desarrollo
de la programación, la preparación de documentos de apoyo normalmente se
difiere hasta que se termine la instrumentación del sistema.
NOTAS DE UNIDAD DE PROGRAMA
Una unidad de programa es una unidad de código fuente que es desarrollada y/o
mantenida por una persona; esa persona es la responsable de la unidad. En un sistema
bien diseñado, una unidad de programa es un subprograma o grupo de subprogramas que
cumplen una función bien definida o forman un subsistema bien definido. Una unidad de
programa también es lo suficientemente pequeña y modular que puede ser probada
totalmente en forma aislada por el programador que la desarrolla o modifica. Un cuaderno
de notas de cada unidad de programa (también conocido como “carpeta de desarrollo de
unidad”) consta de una portada y varias secciones. La portada es la tabla de contenidos y
la hoja de avisos determinación de los diversos logros asociados con la unidad del
programa. El mantenimiento del cuaderno de notas es responsabilidad del programador
asignado a la unidad de programa. Las secciones dentro de un cuaderno de notas de la
unidad corresponden a las diversas fases del ciclo de vida de la unidad

DOCUMENTACIÓN INTERNA
Consiste en un prólogo estándar para cada unidad de programa y unidad de compilación,
los aspectos autodocumentados del código fuente, y los comentarios internos
intercalados en la porción ejecutable del código.
Formato característico de los prólogos de subprogramas y unidades de compilación
 Nombre del autor
 Fecha de compilación
 Función (es) realizada (s)
 Algoritmos empleados
 Autor / Fecha / Propósito de las modificaciones
 Parámetros y modos
 Aseveración de entrada
 Aseveración de salida
 Variables globales
 Efectos colaterales
 Estructuras de datos principales
 Rutinas que invocan
 Rutinas invocadas
 Restricciones de tiempo
 Manejo de excepciones
 Suposiciones (Yenis Gomez, 2020)
 Referencias
Fairley, R. E. (s.f.). https://www.studocu.com. Obtenido de https://www.studocu.com:
https://www.studocu.com/bo/document/universidad-de-aquino-bolivia/auditoria-de-
sistemas/practica/desarrollo-adquisicion-implementacion-
mantenimiento/2890441/view

JP, M. (9 de Marzo de 2018). https://normaiso27001.es. Obtenido de https://normaiso27001.es:

https://normaiso27001.es/a14-adquisicion-desarrollo-y-mantenimiento-de-los-
sistemas-de-informacion/

Yenis Gomez. (04 de 06 de 2020). https://fliphtml5.com/ycuzc/rcbf/basic/. Obtenido de

https://fliphtml5.com/ycuzc/rcbf/basic/: https://fliphtml5.com/ycuzc/rcbf/basic/