4 – Evaluación de los Sistemas

Presentación del tema: "4 – Evaluación de los Sistemas"— Transcripción de la presentación:

1 4 – Evaluación de los Sistemas
Auditoría de Sistemas Ing. Diego J. Arcusin

2 Tipos de Software Elaborado por el usuario Su ventaja es que normalmente es desarrollado para cubrir todas las necesidades del usuario y puede ser modificado de acuerdo a las necesidades de la organización, contiene sistemas de seguridad propios. Sus desventajas son: es más costos, su tiempo de implementación es mas largo y su mantenimiento y actualización, normalmente no se hacen sobra una base periódica. Software Comercial Software shareware o freeware Se tratan de software que pueden ser conseguidos vía Internet. El riesgo de este tipo de software es que puede no cumplir con todas nuestras necesidades y pueden contener problemas de seguridad.

3 Características del Software
Transportabilidad (Portability) Se considera que un software es transportable cuando: Tiene diferentes versiones para diferentes sistemas operativos. Puede cambiarse entre dos o más sistemas operativos, o Puede ser fácilmente convertido de un sistema operativo a otro. Monousuario o Multiusuario Satelitales, Integrados o Compatibles. Al determinar desarrollar un determinado sistema se debe cuidar si habrá necesidad de adquirir sistemas o lenguajes propiedad de una compañía, que para su utilización se requiera de una licencia específica, lo cual puede ser muy costoso, o bien “casarnos” con un determinado proveedor, lo cual podría ser conveniente pero requiere una evaluación muy detallada.

4 Evaluación de los Sistemas
La elaboración o adquisición de sistemas debe evaluarse con mucho detalle, para lo cual se debe revisar desde la planeación y elaboración de los sistemas hasta su desarrollo e implementación. Se deberá evaluar si: Existen sistemas integrados como un todos, o bien si existen programas aislados. Existe un plan estratégico para la elaboración de los sistemas o bien si se están elaborando sin el adecuado señalamiento de prioridades y de objetivos. Los recursos son los adecuados y si se están utilizando en forma eficaz y eficiente.

5 Evaluación de acuerdo al ciclo de vida
Los sistemas deben ser evaluado de acuerdo con el ciclo de vida que normalmente siguen. Para ello, se recomiendan los siguientes pasos: Definición del problema y requerimientos del usuario. Examinar y evaluar los problemas y características del sistema actual, así como los requerimientos por parte del usuario. Estudio de Factibilidad: Desarrollo de los objetivos y del modelo lógico del sistema propuesto. Análisis preliminar de alternativas, incluyendo el estudio de factibilidad técnico y económico de cada alternativo. Desarrollo de recomendaciones para el proyecto de sistema, incluyendo los tiempos y costos del proyecto. C) Diseño general y análisis del sistema: Estudio detallado del sistema actual, incluyendo los procedimientos, diagramas de flujo, métodos de trabajo, organización y control. Desarrollo del modelo lógico del sistema actual.

6 Evaluación de acuerdo al ciclo de vida
Diseño del Sistema: Desarrollo de los objetivos del sistema propuesto. Desarrollo del modelo lógico del sistema propuesto, incluyendo la definición lógica de los procesos, diccionario lógico de datos y diseño lógico de las bases de datos. Evaluación de las diferentes opciones de diseño. Desarrollo del análisis costo-beneficio para evaluar las implicaciones económicas de cada alternativa. Diseño detallado Desarrollo de las especificaciones para el sistema físico, incluyendo el diseño de reportes, archivos, entradas, pantallas y formularios. Diseño de las especificaciones del programa. Diseño de la implementación y el tiempo y forma de llevar a cabo las pruebas. Implementación y Desarrollo físico Codificación y documentación del programa. Evaluación y selección del equipo de cómputo. Desarrollo de sistemas de auditoría, control y seguridad, y desarrollo de los procedimientos de prueba. Desarrollo de los programas de entrenamiento.

7 Evaluación de acuerdo al ciclo de vida
Pruebas del Sistemas, evaluación y aceptación por parte del usuario y de control interno Modificaciones y adecuaciones. Instalación. Carga de Datos. Soporte Cotidiano, cambios y mejoras al sistema. Después de esto se vuelve nuevamente al ciclo inicial, el cual a su vez debe comenzar con el estudio de factibilidad. También se debe evaluar que un error o corrección en el momento del diseño lógico es de fácil y bajo costo, pero que los errores o modificaciones entre más adelantado esté el desarrollo del sistema son más costosos y de difícil implementación.

8 Evaluación de los sistemas
La primera etapa a evaluar en el sistema es el estudio de factibilidad, el cuál debe analizar si el sistema es susceptible de realizarse y cuál es su relación costo-beneficio. Se deberá solicitar el estudio de factibilidad de los diferentes sistemas que se encuentren en operación, así como de los que estén en la fase de análisis para evaluar: La disponibilidad y características del equipo. Los sistemas operativos y los lenguajes disponibles. Las necesidades de los usuarios Las formas de utilización de los sistemas. El costo y los beneficios que reportará el sistema. El efecto que producirá en quienes lo usarán. El efectos que éstos tendrán sobre el sistema La congruencia entre los sistemas y la organización. Si están definidos los procesos administrativos, la normas y las políticas para la utilización de los sistemas. Su seguridad y confidencialidad. Código Abierto. Se distribuye con el código fuente. Hecho en C (Antes se desarrollaban en Assembler) Lenguaje en C -> Portabilidad entre distintos Hardware. Fácil de modificar y mejorar. Tiempo Compartido: Contra los recursos de una computadora y los asigna entre los usuarios.

9 Evaluación de los Sistemas
En el caso de los sistemas que estén en funcionamientos, se deberá comprobar si existe el estudio de factibilidad con los puntos señalados, y comparar con la realidad lo especificado en el estudio de factibilidad. Por ejemplo, en un sistema que el estudio de factibilidad señaló determinado costo y una serie de beneficios debemos comparar cuál fue el costo real y evaluar si se satisficieron las necesidades con el sistema. Para evaluar el costo de un sistema se debe considerar, con una exactitud razonable, el costo de los programas, el uso de los equipos (compilaciones, programas, pruebas, paralelos), el tiempo, el personal y la operación. Los beneficios que justifican el desarrollo de un sistema pueden ser el ahorro en los costos de operación, la reducción del tiempo de proceso de un sistema, una mayor exactitud, un mejor servicio, una mejoría en los procedimientos de control, una mayor confiabilidad y seguridad, una mejor y más comunicación: Código Abierto. Se distribuye con el código fuente. Hecho en C (Antes se desarrollaban en Assembler) Lenguaje en C -> Portabilidad entre distintos Hardware. Fácil de modificar y mejorar. Tiempo Compartido: Contra los recursos de una computadora y los asigna entre los usuarios.

10 Problemas más comunes en los Sistemas
Falta de estándares en el desarrollo, en el análisis y en la programación. Falta de participación y de revisión por parte de la alta gerencia. Falta de participación de los usuarios. Inadecuada especificación del sistema al momento de hacer el diseño detallado. Deficiente análisis costo-beneficio Nueva tecnología no usada o usada incorrectamente. Inexperiencia por parte del personal de análisis y del de programación. Diseño deficiente. Proyección pobre de la forma en que se realizará el sistema. Control débil o falta de control sobre las fases de elaboración del sistema y sobre el sistema en sí. Problemas de auditoría (poca participación de auditoría interna en el momento del diseño del sistema) Inadecuados procedimientos de seguridad, de recuperación y de resguardo. Falta de integración entre los sistemas. Documentación inadecuada o inexistente. Dificultad de dar mantenimiento al sistema, principalmente por falta de documentación o por excesivos cambios y modificaciones hechos al sistemas. Problemas en la conversión e implementación Código Abierto. Se distribuye con el código fuente. Hecho en C (Antes se desarrollaban en Assembler) Lenguaje en C -> Portabilidad entre distintos Hardware. Fácil de modificar y mejorar. Tiempo Compartido: Contra los recursos de una computadora y los asigna entre los usuarios.

11 Evaluación del Análisis
En esta etapa se evaluarán las políticas, normas y procedimientos y normas que se tienen para llevar a cabo el análisis. La situación de una aplicación puede ser alguna de las siguientes: Planeada para ser desarrollada en el futuro. En desarrollo. En producción, pero con modificaciones en desarrollo. En producción con problemas detectados. En producción sin problemas. Código Abierto. Se distribuye con el código fuente. Hecho en C (Antes se desarrollaban en Assembler) Lenguaje en C -> Portabilidad entre distintos Hardware. Fácil de modificar y mejorar. Tiempo Compartido: Contra los recursos de una computadora y los asigna entre los usuarios.

12 Evaluación del Análisis
La auditoría en informática debe evaluar los documentos y registros usados en la elaboración del sistemas, así como todas las salidas y reportes, la descripción de las actividades de flujo de la información y de procedimientos, los archivos almacenados, las bases de datos, su uso y su relación con otros archivos y sistemas, su frecuencia de acceso, su conservación, su seguridad y control, la documentación propuesta, las entradas y salidas del sistema y los documentos fuentes a usarse. Dentro del estudio de los sistemas en uso se debe solicitar: Manual del usuario. Descripción de flujo de información. Descripción y distribución de información. Manual de formularios. Manual de reportes. Lista de archivos y especifiación. Estructura de Base de Datos. Definición de redes. Código Abierto. Se distribuye con el código fuente. Hecho en C (Antes se desarrollaban en Assembler) Lenguaje en C -> Portabilidad entre distintos Hardware. Fácil de modificar y mejorar. Tiempo Compartido: Contra los recursos de una computadora y los asigna entre los usuarios.

13 Evaluación del Análisis
Con la información obtenida podremos dar respuesta a las siguientes preguntas: ¿Se está ejecutando en forma correcta y eficiente el proceso de información? ¿Puede ser simplificado para mejorar su aprovechamiento? ¿Se debe tener una mayor interacción con otros sistemas? ¿Se tiene propuesto un adecuado control y seguridad sobre el sistema? ¿Está en el análisis la documentación adecuada? ¿Se debe usar otro tipo de técnicas o de dispositivos (redes, bases de datos)? ¿Los informes de salida son confiables y adecuados? ¿Las pantallas y el sistema son amigables? Código Abierto. Se distribuye con el código fuente. Hecho en C (Antes se desarrollaban en Assembler) Lenguaje en C -> Portabilidad entre distintos Hardware. Fácil de modificar y mejorar. Tiempo Compartido: Contra los recursos de una computadora y los asigna entre los usuarios.

14 Análisis y Diseño Estructurado Análisis Orientado a Objetos
Tipos de Enfoques Análisis y Diseño Estructurado Análisis Orientado a Objetos Código Abierto. Se distribuye con el código fuente. Hecho en C (Antes se desarrollaban en Assembler) Lenguaje en C -> Portabilidad entre distintos Hardware. Fácil de modificar y mejorar. Tiempo Compartido: Contra los recursos de una computadora y los asigna entre los usuarios.

15 Herramientas de Análisis y Diseño
Diagramas de Flujo de Datos Diagramas Entidad Relación Cursogramas Diagramas de Transición de Estados Arboles y Tablas de Decisión Mapas de Objetos Etc. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

16 Evaluación del Diseño Lógico del Sistema
En esta etapa se deberán analizar las especificaciones del sistemas: ¿Qué deberá hacer? ¿Cómo lo deberá hacer? ¿Cuál es la justificación para que se haga de la manera señalada? ¿Cuál es la secuencia y ocurrencia de los datos? La definición del proceso Los archivos y bases de datos utilizados. Las salidas y reportes. Una vez analizadas se deberá estudiar la participación del usuario, auditoría interna. Posteriormente, deberemos comparar con lo que realmente se está obteniendo del sistema. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

17 Evaluación del Diseño Lógico del Sistema
Los puntos a evaluar en el diseño lógico del sistema son: Entradas Salidas Procesos. Especificaciones de datos. Especificaciones de proceso. Métodos de acceso. Operaciones Manipulaciones de datos. Proceso lógico. Identificación de archivos, tamaño de los campos y registros. Proceso en línea o lote y su justificación. Frecuencia y volúmenes de operación. Sistemas de seguridad. Sistemas de control. Responsables (tipos de usuarios y propietarios de la información) Número de usuarios Software necesario. Bases de datos requeridas. En caso de redes determinar tipo y características. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

18 Programas de Desarrollo
Los programas de desarrollo incluyen software que sólo puede ser usado por personal que ha tenido entrenamiento y experiencia; este software incluye: Lenguajes de máquina Lenguajes de Tercera Generación (Por ejemplo: C, Pascal, Basic) Lenguajes de Cuarta Generación (Por ejemplo: Oracle, Informix) 4GLS SQL Generadores de Reportes Lenguajes Naturales Generadores de Aplicaciones CASE (Computer aided software engineering). Lenguajes Orientados a Objetos (Por ejemplo: C++, Java, Smalltalk) Lenguajes Web (Por ejemplo: PHP, ASP, HTML, XML, Javascript) Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

19 Programas de Desarrollo
Al utilizar un determinado software se debe evaluar lo siguiente: Interfases gráficas de usuario que permitan el diseño de pantallas y reportes amigables y visualmente agradables. Posibilidad de enlazar o embeber objetos en los sistemas de información. Capacidad de trabajar en plataformas múltiples. Capacidad de trabajar en red. Licencias (Verfificar los tipos de licencia disponibles: individual, múltiple, corporativa) Transportabilidad Compatibilidad con otros software. Compatibilidad con hardware. Usabilidad (Facilidad de uso) Requerimientos de Hardware. Seguridad y Confidencialida Costo Etc. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

20 En las bases de datos se debe evaluar:
Es la organización sistemática de archivos de datos para facilitar su acceso, recuperación y actualización, los cuales están relacionados unos con otros y son tratados como una entidad. Pueden contener gran cantidad de información, del orden de millos de datos. EL DBMS (data base management system = sistema de administración de bases de datos) es un conjunto de programas que permite la actualización y recuperación de información de la base de datos. En las bases de datos se debe evaluar: La independencia de los datos. (No guardan relación con los programas que acceden a los mismos y pueden accederse en forma independiente) Redundancia de datos. (Debe evitarse para esto existe el concepto de Normalización). Consistencia de los datos. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

21 Los modelos de bases de datos pueden ser:
El desarrollo de las bases de datos ha creado la necesidad dentro de las organizaciones de contar con un organismo encargado de administrar las bases de datos cuyas funciones son las de: planear, diseñar, organizar, operar, entrenar, dar soportes a los usuarios, seguridad y mantenimiento. Los modelos de bases de datos pueden ser: Jerárquicos En Red Relacionales Orientados a Objetos Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

22 Problemas de las Bases de Datos
Cuando varios usuarios utilizan una base de datos, pueden existir problemas si no fue diseñada para usuarios múltiples. Uno de estos problemas surge cuando no existe un control sobre la actualización inmediata. Pueden existir problemas en el uso de recursos excesivos de cómputo, lo cuál se agrava si no se tiene un mantenimiento constante sobre las bases de datos. Problemas de seguridad. Las bases de datos deben tener suficiente control para que se asegure que sólo personal autorizado pueda acceder datos, y se debe definir el tipo de usuario que pueda adicionar, dar de baja, actualizar o acceder datos dependiendo de su perfil, así como un usuario propietario de la base de datos. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

23 Los componentes más comunes dentro de un sistema de comunicaciones:
Se debe evaluar el modo de comunicación y el código empleado. Los diferentes modos de comunicación varían dependiendo del tipo de información que transmitimos y el costo del medio empleado. El medio de comunicación es también un factor importante a evaluar, y éste dependerá de la velocidad y capacidad de transmisión, lo cuál está directamente relacionado con el costo (par de cobre, coaxil, fibra óptica, microondas, infrarrojo, etc.) Los componentes más comunes dentro de un sistema de comunicaciones: Servidores Terminales o Estaciones de Trabajo Router / Gateways Módems Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

24 Comunicaciones Las redes podrán justificarse por alguna o varias de las siguientes razones: Compartir periféricos. Compartir archivos. Compartir aplicaciones. Reducir costos de adquisición, instalación y mantenimiento de software. Conexión con otras redes. Captura de datos en lugares remotos. Aumento de productividad. Reducir tiempos de comunicación. Aumento de control. Seguridad Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

25 Los puntos a revisar en las redes son:
Comunicaciones Los puntos a revisar en las redes son: Confiabilidad de las redes. Tiempos de respuesta. Costo de la Red. Compatibilidad con otras redes. Seguridad en las redes. Los Compartir aplicaciones. Reducir costos de adquisición, instalación y mantenimiento de software. Conexión con otras redes. Captura de datos en lugares remotos. Aumento de productividad. Reducir tiempos de comunicación. Aumento de control. Seguridad Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

26 Lo que debemos determinar en el sistemas es:
Informes Al analizar un sistema es muy común pensar exclusivamente en la parte relacionada con la informática, olvidándonos de que un sistema comprende desde el momento en que se genera un dato, así como su procesamiento, retroalimentación y salida. Es muy común que se deje fuera la evaluación de aquello que es el inicio del sistema, el seguimiento administrativo y la obtención de reportes y salidas de información. Lo que debemos determinar en el sistemas es: En el procedimiento: ¿Quién hace la función, cuándo y cómo? ¿Qué formularios se utilizan en el sistema? ¿Son necesarios, se usan, están duplicados?¿El número de copias es adecuado? ¿Existen puntos de control o faltan? Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

27 Entre los elementos a revisar en el diseño de formularios están:
Numeración Título Espacio Tabulación Zonas Rayado Instrucciones Firmas Nombres Encabezados Rótulos Tipo de Papel Tamaños Color Etc. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

28 Evaluación del desarrollo del sistema
En esta etapa del sistema se deberán auditar los programas, su diseño, el lenguaje utilizado, la interconexión entre los programas y las características del hardware empleado apra el desarrollo del sistema. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

29 Control de Proyectos Debido a las características propias del análisis y de las programación es muy frecuente que la implantación de los sistemas se retrase. Para poder controlar el avance de los sistemas se recomienda que se utilice la técnica de administración por proyectos para su adecuado control. Para poder tener una buena administración por proyectos se requiere que el analista o el programador y su jefe inmedito elaboren un plan de trabajo en el cual se especifiquen actividades, metas, personal participante y tiempos. Este plan debe ser revisado periódicamente para evaluar el avance respecto a lo programado. Se deberán revisar tanto los proyectos terminados como los que se encuentran en proceso, para verificar si se ha cumplido con el plan de trabajo o si cumple con su función de medio de control. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

30 Instructivos de Operación
Debemos evaluar los instructivos de operación. El contenido mínimo de los instructivo de operación deberá comprender: Diagrama de flujo de cada programas. Diagrama particular de entrada-salida. Mensajes y su explicación. Parámetros y su explicación. Diseño de impresión de resultados. Cifras de control. Fórmulas de verifiación. Observaciones. Instrucciones en caso de error. Calendario de procesos y resultados. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

31 Formas de implantación
La finalidad es la de evaluar los trabajos que se realizan para iniciar la operación de un sistema; esto comprende: prueba integral del sistemas, adecuación, aceptación por parte del usuario, entrenamiento de los responsables del sistema. Para ello deben considerarse los siguientes aspectos: Indicar cuáles puntos se toman en cuenta para la prueba de un sistema: Prueba particular de cada programa. Prueba por fase, validación, actualización. Prueba integral. Prueba en paralelo. Pruebas de seguridad y confidencialidad. Otros. En la implantación se debe de analizar la forma en que se van a cargar inicialmente los datos del sistema y la manera en que se copian los programas al entorno de producción. También se debe de hacer un plan de trabaja para la implantación. Se puede decir que las variantes de Bell (1era a 6ta= era una versión comercial continuada por AT&T, y la versión de Berkley era una versión academica. Linux toma partes de cada una de estas ramas.

32 Preguntas ?