UNIDAD V. EVALUACIÓN DE LOS SISTEMAS DE INFORMACION


5.1 Aplicación de los sistemas de informacion.

El benchmarking como herramienta de evaluación


En el año 1979, aparece, por primera vez, el término “Benchmarking competitivo”, cuando la empresa Xerox comienza a cuestionarse su modelo de gestión, debido a que vendía sus productos y servicios por debajo de sus costos de producción; este acontecimiento marcó la pauta para el desarrollo del benchmarking.



Desde sus inicios, diferentes autores han definido este concepto, por ejemplo:
- Según Spendolini , se considera como “…un proceso sistemático y continuo para evaluar los productos, servicios y procesos de trabajo de las organización que se reconocen como representantes de las mejores prácticas, con el propósito de realizar mejoras organizacionales…”. Esta definición está enfocada al ámbito empresarial.

- Según la Comisión Directiva del International Benchmarking Clearinghouse del American Productivity & Quality Center (APQC) es “...un proceso en que las firmas determinan puntos claves de mejora en determinadas áreas, identifican y estudian las mejores prácticas de otros en dichas áreas, e implementan nuevos sistemas y procesos para mejorar su propia calidad y productividad....” 

Puede afirmarse entonces, que es un proceso operativo de aprendizaje y adaptación permanente que se realiza con el propósito de perfeccionar sus resultados, donde se aprehende, adapta e implementan métodos que han producido resultados positivos en otras organizaciones.

- Según Rodríguez de Rivera, “ …es un método para ayudar en la planificación y desarrollo de productos, servicios o sistemas (“serductos”) que sistematiza la medición/evaluación de los niveles de las prestaciones técnicas o de calidad alcanzados en la firma propia en comparación con los resultados de los mejores competidores - en referencia a determinadas magnitudes que deben definirse como las más relevantes…”.

Por tanto, se trata de un proceso de evaluación de productos, servicios y procesos entre organizaciones, mediante el cual una de ellas analiza cómo otra realiza una función específica para igualarla o mejorarla. La aplicación de esta técnica permite a las organizaciones alcanzar mayor calidad en sus productos, servicios y procesos, a partir de la cooperación, colaboración y el intercambio de información. Su objetivo es corregir errores e identificar oportunidades, para aprender a solucionar problemas y tomar decisiones según los patrones de los líderes.

Esta clase de estudios se realiza en contacto directo con los competidores o no competidores y al finalizar, se comparten los resultados para que cada organización cree su propio sistema de mejoras.

TIPOS DE BENCHMARKING

El proceso de benchmarking se utiliza para mejorar la eficacia y eficiencia de las organizaciones, así como para actualizarse con respecto a las mejores prácticas.

Boxwell afirma que existen varios tipos de benchmarking y los define en función de su objeto:
  • “...Benchmarking competitivo: significa mediar sus funciones, procesos, actividades, productos y servicios en comparación con los de sus competidores y mejorar los propios de forma que sean, en el caso ideal los mejores en su clase, pero, por lo menos, superiores a los que de sus competidores
  • Benchmarking cooperativo: el saber fluye normalmente en una dirección, desde las empresas objetivo hasta el equipo benchmarking aun cuando el equipo de Benchmarking ofrece frecuentemente algún beneficio a cambio. No se define con claridad en qué consiste.
  • Benchmarking de colaboración: un grupo de empresas comparten conocimientos sobre una actividad particular, y todas esperan mejorar a partir de lo que van aprender. A veces, una organización independiente sirve como coordinadora, recolectora y distribuidora de datos aunque un creciente numero de empresas dirige sus propios estudios de colaboración.
  • Benchmarking interno: es una forma de benchmarking de colaboración que muchas empresas grandes utilizan para identificar las prácticas del mejor “en casa” y extender el conocimiento, sobre estas practicas a otros grupos en la organización;, se realiza con frecuencia en grandes compañías como primer paso de aquello que puede ser más tarde un estudio enfocado al exterior..”.

ETAPAS DEL PROCESO

Según León, “…El Benchmarking afrontó en sus orígenes un primer problema a causa de la cantidad de modelos existentes para realizar este tipo de proceso y la cuantía de pasos que definen la lógica de los modelos de sus principales precursores…”

“…Estos modelos, a pesar de estar divididos en diferentes fases o pasos, en esencia, obtienen con su aplicación, los mismos resultados, que no es más que la búsqueda de una mejora continua en las organizaciones…”.

Para comprender globalmente las etapas para la aplicación de este proceso, a continuación, se enuncian, la secuencia propuesta por Spendolini, una de las mayor aplicación y referencia:
  • Determinar a que se le va a hacer Benchmarking: Consiste en identificar a los consumidores de este proceso y fundamentalmente sus necesidades; definir los aspectos específicos para el Benchmarking; además, en esta etapa, se identifican y aseguran los recursos necesarios.
  • Formar un equipo de Benchmarking: Es el proceso donde se escoge, orienta y dirige un equipo. En este paso, se introducen las herramientas para el manejo de proyectos, se identifican las etapas y se aclaran las tareas para todos los participantes.
  • Identificar los socios del Benchmarking: busca identificar las fuentes de información que se utilizarán para recopilar la información de Benchmarking; además, comprende el proceso de identificación de las mejores prácticas industriales y organizacionales.
  • Recopilar y analizar la información de Benchmarking: se propone la selección de los métodos específicos de recopilación de información. El análisis de la información, se realiza según las necesidades del cliente original, con vistas a recomendar acciones para provocar un cambio, es importante que los responsables de esta actividad sean expertos.
  • Actuar: su objetivo es generar un informe con un conjunto de recomendaciones para la ejecución real del cambio. Es necesario que, al terminar este proceso, se analicen nuevamente las necesidades de sus clientes y revelen los planes de ejecución a seguir, es decir, dar una continuidad al proceso de Benchmarking.

EL BENCHAMARKING COMO HERRAMIENTA DE EVALUACIÓN EN LOS SISTEMAS DE INFORMACIÓN

Alonso Arévalo y Martín Cerro plantean que “… cada biblioteca y servicio de información deberá adoptar un modelo de Benchmaking apropiado a sus circunstancias y características particulares”, y que deberá “considerar el funcionamiento de sus sistemas de información y los intereses de sus usuarios”, además aclaran que “este modelo ha de ser lógico, sencillo y simple de aplicar ”.5
Y señalan aspectos susceptibles de analizarse mediante un estudio de benchmarking:
  • Impacto y valor añadido de la información: qué incidencia tuvo la información en los usuarios y en sus actividades.
  • Niveles de actividad: cuál es distribución del horario, préstamos en relación al total de usuarios.
  • Reparto del presupuesto (adquisiciones, tipos de materiales, personal, infraestructura,…).
  • Productividad/procesos técnicos: tiempo en que se realiza una actividad o producto por parte del personal cualificado., A pesar de ser una medición a la que es reticente el propio personal, con frecuencia revela importantes deficiencias con respecto a los métodos de organización del trabajo (tiempo de catalogación o indización de documentos).
  • Tipo de estructura de la unidad documental: determinar cuál estructura responde mejor a los objetivos de la unidad, esto es, una estructura centralizada o descentralizada.
Y además destacan que, una vez analizados estos aspectos y realizados algunos cambios en la organización, es necesario por un lado, descubrir su efecto entre los usuarios y comparar los datos sobre el funcionamiento de los servicios antes y después del cambio, y por otro, mantener un seguimiento continuo con vistas a conservar las pautas de calidad establecidas de acuerdo con la política del sistema. Además, recomiendan que un posible modelo para su implementación es el desarrollado por Kinnell y Garrod, que considera una serie de aspectos durante el desarrollo del proceso de benchmarking, a saber:6
  • Identificación de los factores clave de éxito.
  • Documentación/diagrama de procesos y subprocesos.
  • Identificación de los procesos claves.
  • Medición de los factores clave de éxito.
  • Análisis de resultado/identificación de las diferencias de rendimiento.
  • Selección de asociados.
  • Organización de visitas.
  • Identificar las mejores prácticas.
En forma general, estos aspectos posibilitan analizar con profundidad cada proceso; identificar los factores clave de éxito, sus elementos constituyentes y representarlos en un diagrama de flujo; elaborar una guía para un mejor desarrollo del proceso; así como medir con rigor y precisión los factores clave de éxito según los indicadores seleccionados. Todo esto permite realizar un análisis y detectar problemas en las diferentes áreas, así como identificar los socios posibles para realizar el benchmarking, establecer contactos los formales y realizar comparaciones que permitan detectar posibles soluciones y adaptarlas a la organización.

REFERENCIAS BIBLIOGRÁFICAS

  1. Spendolini MJ. Benchmarking. Bogotá: Norma S.A., 1994. p. 11.
  2. Rodríguez de Rivera J. Benchmarking. Instrumentos de la gestión de procesos de negocio. 2004. Disponible en: http://www2.uah.es/estudios_de_organizacion/temas_organizacion/org_praxis/organiz_creacion_valor/benchmarking.htm[Consultado: 5 de mayo del 2006].
  3. Boxwell RJ. Benchmarking para competir con ventaja. Madrid: McGraw Hill, 1994. p.26-29.
  4. León Santos M. Gestión de procesos. La Habana: Universidad de la Habana, 2006.
  5. Alonso Arévalo J, Martín Cerro S. Benchmarking: Una herramienta para gestionar la excelencia en las bibliotecas y los servicios de información. 2004. Disponible en: http://www.ubu.es/biblioteca/bucle/5.htm [Consultado: 3 de mayo del 2006].
  6. Kinnell M, Garrod P. Benchmarking and its relevance to the Library and information. British Library Research and Development Department Project. Northumberland: s.n; 1995.

5.2 CRITERIOS DE EVALUACION DE LOS SISTEMAS DE INFORMACION.




Introducción

Es el primer paso práctico del auditor en informática dentro de las empresas o instituciones al efectuar un proyecto de auditoría en informática. 

Se busca la opinión de la alta dirección para estimar el grado de satisfacción y confianza que tiene en los productos, servicios y recursos de informática del negocio; asimismo, es posible detectar las fortalezas, aciertos y apoyo que brinda dicha función desde la perspectiva de los directivos del negocio.

Un punto importante que debe quedar plasmado en esta fase son las áreas de oportunidad que tiene informática para hacer más competitivo y rentable el negocio, sea este soporte directo o indirecto, en alto o menor grado.

Es conveniente aclarar que no se debe tratar esta etapa como un conjunto de tareas que requieren muchos recursos involucrados ni un tiempo considerable; es simplemente un aspecto necesario y generalizado para entender los puntos débiles y fuertes de la función de informática desde un punto de vista de los usuarios clave y la alta dirección.

Todas las actividades del auditor en informática deben estar claramente definidas en todos los componentes formales que integran cualquier trabajo dentro de una organización.

Los aspectos por evaluar son al menos los tres mencionados a continuación. Ahora bien, si el auditor considera .que la complejidad del negocio, la fusión o compra de la empresa, la informalidad palpable en informática o alguna consideración específica para el líder de proyectos o a petición de la alta dirección requieren más puntos por considerar y un tiempo más  prolongado, conviene que los integre en esta fase, ya que aquí se detectan los primeros síntomas de informática que, a la postre, pueden ser los más relevantes.
Los temas evaluación de los sistemas, objetivos específicos de la evaluación de los sistemas, evaluación del sistema lógico, evaluación del desarrollo de sistemas y auditoría informática de comunicaciones y redes entre otros, corresponden a las obras elaboradas por Oscar Toro, Núñez de Balboa, Eduardo Horacio Quinn y Julián Gutiérrez Melo.

1 Evaluación de los sistemas Fuente:
 http://www.monografias.com/trabajos/maudisist/maudisist.shtml

La elaboración de sistemas debe ser evaluada con mucho detalle, para lo cual se debe revisar si existen realmente sistemas entrelazados como un todo o bien si existen programas aislados. Otro de los factores a evaluar es si existe un plan estratégico para la elaboración de los sistemas o si se están elaborados sin el adecuado señalamiento de prioridades y de objetivos.

El plan estratégico deberá establecer los servicios que se presentarán en un futuro contestando preguntas como las siguientes:

¿Cuáles servicios se implementarán?

¿Cuándo se pondrán a disposición de los usuarios?44

¿Qué características tendrán?

¿Cuántos recursos se requerirán?

La estrategia de desarrollo deberá establecer las nuevas aplicaciones, recursos y la arquitectura en que estarán fundamentados:

¿Qué aplicaciones serán desarrolladas y cuando?

¿Qué tipo de archivos se utilizarán y cuando?

¿Qué bases de datos serán utilizarán y cuando?

¿Qué lenguajes se utilizarán y en que software?

¿Qué tecnología será utilizada y cuando se implementará?

¿Cuantos recursos se requerirán aproximadamente?

¿Cuál es aproximadamente el monto de la inversión en hardware y software?

En lo referente a la consulta a los usuarios, el plan estratégico debe definir los requerimientos de información de la dependencia.

¿Qué estudios van a ser realizados al respecto?

¿Qué metodología se utilizará para dichos estudios?

¿Quién administrará y realizará dichos estudios?

En el área de auditoría interna debe evaluarse cuál ha sido la participación del auditor y los controles establecidos.

Por último, el plan estratégico determina la planeación de los recursos.

¿Contempla el plan estratégico las ventajas de la nueva tecnología?

¿Cuál es la inversión requerida en servicios, desarrollo y consulta a los usuarios?

El proceso de planeación de sistemas deberá asegurarse de que todos los recursos requeridos estén claramente identificados en el plan de desarrollo de aplicaciones y datos. Estos recursos (hardware, software y comunicaciones) deberán ser compatibles con la arquitectura y la tecnología, conque se cuenta actualmente.

Los sistemas deben evaluarse de acuerdo con el ciclo de vida que normalmente siguen:

requerimientos del usuario, estudio de factibilidad, diseño general, análisis, diseño lógico, desarrollo físico, pruebas, implementación, evaluación, modificaciones, instalación, mejoras. Y se vuelve nuevamente al ciclo inicial. el cual a su vez debe comenzar con el de factibilidad.

La primera etapa a evaluar del sistema es el estudio de factibilidad, el cual debe analizar si el sistema es factible de realizarse, cuál es su relación costo/beneficio y si es recomendable elaborarlo. Se deberá solicitar el estudio de factibilidad de los diferentes sistemas que se encuentren en operación, así como los que estén en la fase de análisis para evaluar si se considera la disponibilidad y características del equipo, los sistemas operativos y lenguajes disponibles, la necesidad 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 quiénes lo usarán y el efecto que éstos tendrán sobre el sistema y la congruencia de los diferentes sistemas.45 En el caso de sistemas que estén funcionando, se deberá comprobar si existe el estudio de factibilidad con los puntos señalados y compararse con la realidad con 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 de acuerdo con las necesidades del usuario, debemos comparar cual fue su costo real y evaluar si se satisficieron las necesidades indicadas como beneficios del sistema.

Para investigar 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), tiempo, personal y operación, cosa que en fa práctica son costos directos, indirectos y de operación.

Los beneficios que justifiquen 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. Mayor exactitud, mejor servicio, una mejoría en los procedimientos de control, mayor confiabilidad y seguridad.

Fuente:http://html.rincondelvago.com/auditoria-de-Ios-sistemas-de-informacion.html

Se encarga de llevar a cabo la evaluación de normas, técnicas y procedimientos que se tiene establecidos en una empresa para lograr confiabilidad, oportunidad, seguridad y confidencialidad de la información que se procesa a través de los sistemas de información. La auditoría de sistemas es una rama especializada de la auditoria que promueve y aplica conceptos
de auditoría en el área de sistemas de información.

El objetivo final que tiene el auditor de sistemas es dar recomendaciones a la alta gerencia para mejorar o lograr un adecuado control interno en ambientes de tecnología informática con el fin de lograr mayor eficiencia operacional y administrativa.

IV.2 Objetivos específicos de la auditoría de sistemas:

1. Participación en el desarrollo de nuevos sistemas:
a. Evaluación de controles

b. Cumplimiento de la metodología.

2. Evaluación de la seguridad en el área Informática.

3. Evaluación de suficiencia en los planes de contingencia.
a. Respaldos, prever qué va a pasar si se presentan fallas.

4. Opinión de la utilización de los recursos informáticos.
a. Resguardo y protección de activos. .

5. Control de modificación a las aplicaciones existentes.
a. Fraudes
b. Control a las modificaciones de los programas.

6. Participación en la negociación de contratos con los proveedores.

7. Revisión de la utilización del sistema operativo y los programas.
a. Utilitarios
b. Control sobre la utilización de los sistemas operativos
c. Programas utilitarios.

8. Auditoría de la base de datos.
a. Estructura sobre la cual se desarrollan las aplicaciones.

9. Auditoria de la red de teleprocesos

10. Desarrollo de software de auditoría.46

Es el objetivo final de una auditoria de sistemas bien implementada, desarrollar software capaz de estar ejerciendo un control continuo de las operaciones del área de procesamiento de datos.

Fines de la auditoría de sistemas:

1. Fundamentar la opinión del auditor interno (externo) sobre la confiabilidad de los sistemas de información.

2. Expresar la opinión sobre la eficiencia de las operaciones en el área de TI.
Fuente: (http://www.inforarea.es/servicio7.htm) Núñez de Balboa.
Desde un Web site, una biblioteca, un archivo a un Centro de documentación, cualquier sistema de información puede ser evaluado para comprobar en que medida cumple con los objetivos para los que fue creado y detectar áreas de mejora en las que centrar las intervenciones futuras.

En nuestras evaluaciones seguimos una metodología adaptada a cada situación concreta que fundamentalmente recoge las siguientes fases:
Identificación y elección de los indicadores que permiten la medición de los distintos aspectos a evaluar Recogida de datos mediante los medios mas adecuados a cada situación (encuestas, cuestionarios on-line, entrevistas, observación directa, test de usabilidad, trabajo en grupo, etc.) Análisis de los indicadores. Detección de áreas de mejora Propuestas de mejora En muchos casos utilizamos la evaluación comparativa, que permite situar el sistema
evaluado con respecto al mejor (benchmarking) o comparar el sistema con un grupo de sistemas similares para situarlo dentro de una escala.

3 Evaluación del Diseño Lógico del Sistema

Fuente: (http://www.itapizaco.edu.mx/paginas/maudisist.html) Toro Oscar.
En esta etapa se deberán analizar las especificaciones del sistema.

¿Qué deberá hacer?, ¿Cómo lo deberá hacer?, ¿Secuencia Y ocurrencia de los datos, el proceso y salida de reportes?

Una vez que hemos analizado estas partes, se deberá estudiar la participación que tuvo el usuario en la identificación del nuevo sistema, la participación de auditoría interna en el diseño de los controles y la determinación de los procedimientos de operación y decisión.

Al tener el análisis del diseño lógico del sistema debemos compararlo con lo que realmente se está obteniendo en la cual debemos evaluarlo planeado, cómo fue planeado y lo que realmente se está obteniendo.47

Los puntos a evaluar son:

· Entradas.

· Salidas.

· Procesos.

· Especificaciones de datos.

· Especificaciones de proceso.

· Métodos de acceso.

· Operaciones.


· Manipulación de datos (antes y después del proceso electrónico de datos).

· Proceso lógico necesario para producir informes.

· 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.

· Número de usuarios.


Dentro del estudio de los sistemas en uso se deberá solicitar:

· Manual del usuario.

· Descripción de flujo de información y/o procesos.

· Descripción y distribución de información.

· Manual de formas.

· Manual de reportes.

· Lista de archivos y especificaciones.

Lo que se debe determinar en el sistema:

En el procedimiento:

· ¿Quién hace, cuando y como?

· ¿Qué formas se utilizan en el sistema?

· ¿Son necesarias, se usan, están duplicadas?

· ¿El número de copias es el adecuado?

· ¿Existen puntos de controlo faltan?

En la gráfica de flujo de información:

· ¿Es fácil de usar?

· ¿Es lógica?

· ¿Se encontraron lagunas?

· ¿Hay faltas de control?

En el diseño:

· ¿Cómo se usará la herramienta de diseño si existe?

· ¿Qué también se ajusta la herramienta al procedimiento?48

IV.4 Evaluación del desarrollo del Sistema

Fuente: (http://www.ilustrados.com/publicaciones/EpyppFZZkpIJTHHuCg.php) 

Toro Oscar.

En esta etapa del sistema se deberán auditar los programas, su diseño, el leguaje utilizado, interconexión entre los programas y características del hardware empleado (total o parcial) para el desarrollo del sistema. Al evaluar un sistema de información se tendrá presente que todo sistema debe proporcionar información para planear, organizar y controlar de manera eficaz y oportuna, para reducir la duplicidad de datos y de reportes y obtener una mayor seguridad en la forma más económica posible. De ese modo contará con los mejores elementos para una adecuada toma de decisiones. Al tener un proceso distribuido, es preciso considerar la seguridad del movimiento de la información entre nodos. El proceso de planeación de sistemas debe definir
la red óptima de comunicaciones, los tipos de mensajes requeridos, el trafico esperado en las líneas de comunicación y otros factores que afectan el diseño. Es importante considerar las variables que afectan a un sistema: ubicación en los niveles de la organización, el tamaño y los recursos que utiliza. Las características que deben evaluarse en los sistemas son:

· Dinámicos (susceptibles de modificarse).

· Estructurados (las interacciones de sus componentes o subsistemas deben 
actuar como un todo)

· Integrados (un solo objetivo). En él habrá sistemas que puedan ser interrelacionados y no programas aislados.

· Accesibles (que estén disponibles).

· Necesarios (que se pruebe su utilización).

· Comprensibles (que contengan todos los atributos).

· Oportunos (que esté la información en el momento que se requiere).

· Funcionales (que proporcionen la información adecuada a cada nivel).

· Estándar (que la información tenga la misma interpretación en los distintos 
niveles).

· Modulares (facilidad para ser expandidos o reducidos).

· Jerárquicos (por niveles funcionales).

· Seguros (que sólo las personas autorizadas tengan acceso).

· Únicos (que no duplique información).


IV.5 Auditoría informática de comunicaciones y redes
Fuente: (http:/www.monografias.com/trabajos5/audi/audi.shtml#redeS) 

Horacio Quinn Eduardo.

Para el informático Y para el auditor informático, el entramado conceptual que
constituyen las Redes Nodales, Líneas, Concentradores, Multiplexores, Redes Locales, etc. no son sino el soporte físico-lógico del Tiempo Real. El auditor tropieza con la dificultad técnica del entorno, pues ha de analizar situaciones y hechos alejados entre si, y esté condicionado a la participación del monopolio telefónico que presta el soporte. Como en otros casos, la auditoría de este sector requiere un equipo de especialistas, expertos simultáneamente en Comunicaciones y en Redes Locales (no hay que olvidarse que en entornos geográficos reducidos, algunas empresas optan por el uso interno de Redes Locales, diseñadas y cableadas con recursos propios).

El auditor de Comunicaciones deberá inquirir sobre los índices de utilización de las líneas contratadas con información abundante sobre tiempos de desuso. Deberá proveerse de la topología de la Red de Comunicaciones, actualizada, ya que la desactualización de esta documentación significarla una grave debilidad. La inexistencia de datos sobre cuantas líneas existen, cómo son y donde están instaladas, supondría que se bordea la inoperatividad49 Informática. Sin embargo, las debilidades más frecuentes o importantes se encuentran en las disfunciones organizativas. La contratación e instalación de líneas va asociada a la instalación de los Puestos de Trabajo correspondientes (Pantallas, Servidores de Redes Locales, Computadoras con tarjetas de Comunicaciones, impresoras, etc.). Todas estas actividades deben estar muy
coordinadas y de ser posible, dependientes de una sola organización.


IV.6 Auditoría de comunicaciones
Fuente: (http://monografias.com/trabajos10/auap/auap.shtml#au) Gutiérrez Melo Julián.

Ha de verse:

· La gestión de red = los equipos y su conectividad.

· La monitorización de las comunicaciones.

· La revisión de costes y la asignación formal de proveedores.


· Creación y aplicabilidad de estándares.
Cumpliendo como objetivos de control:

· Tener una gerencia de comunicaciones con plena autoridad de voto y acción.

· Llevar un registro actualizado de módems, controladores, terminales, líneas y todo equipo relacionado con las comunicaciones.


· Mantener una vigilancia constante sobre cualquier acción en la red.

· Registrar un coste de comunicaciones y reparto a encargados.

· Mejorar el rendimiento y la resolución de problemas presentados en la red.

Para lo cual se debe comprobar:

· El nivel de acceso a diferentes funciones dentro de la red.

· Coordinación de la organización de comunicación de datos y voz.

· Han de existir normas de comunicación en:

o Tipos de equipamiento como adaptadores LAN.

o Autorización de nuevo equipamiento, tanto dentro, como fuera de las horas
laborales.

o Uso de conexión digital con el exterior como Internet.

o Instalación de equipos de escucha como Sniffers (exploradores físicos) o

Traceadores (exploradores lógicos).

La responsabilidad en los contratos de proveedores.

La creación de estrategias de comunicación a largo plazo.

Los planes de comunicación a alta velocidad como fibra óptica y ATM ( técnica 
de conmutación de paquetes usada en redes MAN e ISDN).

Planificación de cableado.

Planificación de la recuperación de las comunicaciones en caso de desastre.

Ha de tenerse documentación sobre el diagramado de la red.

Se deben hacer pruebas sobre los nuevos equipos.

Se han de establecer las tasas de rendimiento en tiempo de respuesta de las 
terminales y la tasa de errores.

Vigilancia sobre toda actividad on-line.

La facturación de los transportistas y vendedores ha de revisarse regularmente.50

IV.7 Auditoría de la red física

Se debe garantizar que exista:
· Áreas de equipo de comunicación con control de acceso.
· Protección y tendido adecuado de cables y líneas de comunicación para evitar accesos físicos.

· Control de utilización de equipos de prueba de comunicaciones para monitorizar la red y el tráfico en ella.

· Prioridad de recuperación del sistema.

· Control de las líneas telefónicas.

Comprobando que:

· El equipo de comunicaciones ha de estar en un lugar cerrado y con acceso 
limitado.

· la seguridad física del equipo de comunicaciones sea adecuada.

· Se tomen medidas para separar las actividades de los electricistas y de cableado de líneas telefónicas.

· las líneas de comunicaci6n estén fuera de la vista.

· Se dé un código a cada línea, en vez de una descripción física de la misma.

· Haya procedimientos de protecci6n de los cables y las bocas de conexión 
para evitar pinchazos a la red.

· Existan revisiones periódicas de la red buscando pinchazos a la misma.

· El equipo de prueba de comunicaciones ha de tener unos propósitos y funciones específicas.

· Existan alternativas de respaldo de las comunicaciones.

· Con respecto a las líneas telefónicas: No debe darse el número como público y tenerlas configuradas con retrollamada, código de conexión o interruptores.


IV.8 Auditoria de la red lógica

En ésta, debe evitarse un daño Interno, como por ejemplo, inhabilitar un equipo que empieza a enviar mensajes hasta que satura por completo la red. Para éste tipo de situaciones:

· Se deben dar contraseñas de acceso.

· Controlar los errores.

· Garantizar que en una transmisión, ésta solo sea recibida por el destinatario. Para esto, regularmente se cambia la ruta de acceso de la informaci6n a la red.

· Registrar las actividades de los usuarios en la red.

· Encriptar la información pertinente.

· Evitar la importación y exportación de datos.
Que se comprueban si: El sistema pidió el nombre de usuario y la contraseña para cada sesión: En cada sesión de usuario, se debe revisar que no acceda a ningún sistema sin autorización, ha de inhabilitarse al usuario que tras un número establecido de veces errar en dar correctamente su propia contraseña, se debe obligar a los usuarios a cambiar su contraseña regularmente, las contraseñas no deben ser mostradas en pantalla tras digitarlas,51 para cada usuario, se debe dar información sobre su última conexión a fin de evitar
suplantaciones.

· Inhabilitar el software o hardware con acceso libre.

· Generar estadísticas de las tasas de errores y transmisión.

· Crear protocolos con detección de errores.

· Los mensajes lógicos de transmisión han de llevar origen, fecha, hora y 
receptor.

· El software de comunicación, ha de tener procedimientos correctivos y de control ante mensajes duplicados, fuera de orden, perdidos o retrasados.

· Los datos sensibles, solo pueden ser impresos en una impresora especificada y ser vistos desde una terminal debidamente autorizada.

· Se debe hacer un análisis del riesgo de aplicaciones en los procesos.

· Se debe hacer un análisis de la conveniencia de cifrar los canales de transmisión entre diferentes organizaciones.

· Asegurar que los datos que viajan por Internet vayan cifrados.

· Si en la LAN hay equipos con modem entonces se debe revisar el control de
seguridad asociado para impedir el acceso de equipos foráneos a la red.

· Deben existir políticas que prohíban la instalación de programas o equipos
personales en la red.

· Los accesos a servidores remotos han de estar inhabilitados.

· La propia empresa generara propios ataques para probar solidez de la red y
encontrar posibles fallos en cada una de las siguientes facetas:

o Servidores = Desde dentro del servidor y de la red interna.

o Servidores web.

o Intranet = Desde dentro.

o Firewall = Desde dentro.

o Accesos del exterior y/o Internet.52




Bibliografía Capitulo IV

05/11/1999. “Auditoría Informática”.
http://www.monografias.com/trabajos/audotoinfo/auditoinfo.shtml
Toro Oscar. 26/12/1999. “Manual de auditoría de sistemas”.
http://www.monografias.com/trabajos/maudisist/maudisist.shtml
http://html.rincondelvago.com/auditoria-de-Ios-sistemas-de-informacion.html
Núñez de Balboa. “Evaluación de los sistemas de información”.
http://www.inforarea.es/servicio7.htm
Toro Oscar. 04/08/2003. “Manual de auditoría de sistemas”.
http://www.itapizaco.edu.mx/paginas/maudisist.html
Toro Oscar. 04/08/2003. “Manual de auditoría de sistemas”.
http://www.ilustrados.com/publicaciones/EpyppFZZkpIJTHHuCg.php
Horacio Quinn Eduardo. 08/11/2000. “La Auditoria informática dentro de las etapas de análisis
de sistemas administrativos”.
http://www.monografias.com/trabajos5/audi/audi.shtml#redeS
Gutiérrez Melo Julián. 27/12/2001. “Auditoria aplicada a la seguridad en redes de
computadores”.
http://www.monografias.com/trabajos10/auap/auap.shtml#a


5.3 Desarrollo de caso practico



Sistemas de Información: Trabajo Práctico Nº5

Análisis y Diseño de Sistemas de Información

El desarrollo de un Sistema de Información (SI) comprende varios componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno más de los componentes: Software, hardware, personas, base de datos, documentación y procedimientos.

En una organización o Empresa, el análisis y Diseño de Sistemas, es el proceso de estudiar su Situación con la finalidad de observar cómo trabaja y decidir si es necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el analista de sistemas.

Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de Sistemas para detectar todos los detalles de la situación actual de la empresa. La información reunida con este estudio sirve como base para crear varias estrategias de Diseño del sistema de información.

Bibliografía recomendada:
“Análisis y Diseño de Sistemas” – III Edición.
Kendall & Kendall.
Pearson Educación.
“Sistemas de Información Gerencial. Administración de la empresa digital” - X Edición.
K. Laudon – J. Laudon.
Pearson – Prentice Hill.

Consigna:

Contestar las siguientes preguntas previamente a trabajar sobre el caso práctico. Considere que cada una de las respuestas debe contener al menos 200 palabras.

1) Defina Sistemas de Información

2) ¿Cuál es la función del análisis de SI? ¿Cuáles son los objetivos de dicho análisis?
Mencione al menos 5 elementos a analizar en todo SI.

3) ¿Qué se entiende por análisis de requisitos o requerimientos?. ¿En qué partes se encuentra dividido el análisis de requisitos?

4) ¿Qué es un estudio de viabilidad del SI y para qué sirve? Mencione al menos 3 áreas principales de interés en las que se debe basar el estudio de viabilidad.

5) ¿En que se basa el análisis Económico y Técnico de SI y que permite determinar?

6) ¿Qué es el modelado de la arquitectura del Sistema?

7) ¿A qué se refiere con especificaciones del Sistema?

8) ¿Qué es el diseño de SI y cuáles son las etapas que encierra?

9) ¿Para qué sirve un diseño de la salida de los SI?

10) ¿Qué es el diseño de Archivos?

11) ¿Qué es el diseño de Interacciones con la Base de Datos?

12) Mencione al menos 4 herramientas para el Diseño de Sistemas



Análisis de requerimientos 

- Introducción

El grupo laboral de la Administración de Ciencias Médicas de la Universidad de Buenos Aires se compone de las siguientes tipos de nombramientos; nombramiento temporal, empleado regular, y contrato de servicios profesionales. Todos estos nombramientos componen un grupo laboral de alrededor de 1000 personas de las cuales aproximadamente 500 personas son empleados regulares. Los empleados regulares son los únicos miembros que tienen derecho a una cobertura médica cubierto por la Universidad.

En vista de esto, el Director del Departamento de Recursos Humanos ha solicitado el análisis del problema existente para realizar posteriormente el diseño e implantación de un sistema computarizado que ayude a manejar de una manera más eficiente todo el proceso de manejo de información de las coberturas médicas.

El Departamento de Recursos Humanos es el encargado de la administración de los documentos concernientes a los empleados que tienen derecho a este según su contrato de empleo. Actualmente esta información la recopilan mediante un formulario que se le suministra al empleado en la oficina del Departamento de Recursos Humanos y luego este formulario es almacenado en un área de archivos. Cuando surge por ejemplo una información que es requerida por la gerencia (Departamento de Contabilidad) la persona encargada de manejar los expedientes en los archivos físicos tiene que dirigirse hasta el área de Base de Datos.

IMPORTANCIA DEL PROYECTO

Dado que la Universidad de Buenos Aires es en sí un sistema, muchos de los proyectos que se realizan en las diferentes unidades del sistema universitario son evaluados para analizar la posibilidad de que los mismos no sólo puedan implantarse en dicha unidad, sino en todas las unidades. Esto significa que el esfuerzo logrado por Ciencias Médicas para el desarrollo de este proyecto podría ser de beneficio para toda la institución.

Hasta el día de hoy ninguna unidad del sistema universitario posee esta herramienta, por lo que el éxito del proyecto es significativo y vital. Entre las razones para solucionar este problema se encuentran:

• Manejo rápido de la información solicitada por las diferentes oficinas a la
Administración.

• Muchas personas califican el servicio provisto como promedio, ya que aunque las solicitudes son realizadas, a veces hay que esperar mucho tiempo para que se realicen.

• Una fuente de almacenaje de información más confiable, precisa, rápida y sobre todo económica ya que el uso de papeles se reduciría considerablemente.

• Actualmente no existe ningún medio computarizado que permita por ejemplo actualizar la información en una manera rápida y clara.

• Una fuente de almacenaje de información más confiable, precisa, rápida y sobre todo económica ya que el uso de papeles se reduciría considerablemente.

• Se reduce la pérdida de horas de trabajo.
La Administración de Ciencias Médicas cuenta con una de las infraestructuras en tecnologías de información más completas y seguras de todo el sistema universitario.

Además, la Administración cuenta con un presupuesto especial (aprobado por el rector) para el desarrollo de nuevas tecnologías de información, las cuales puedan servir en beneficio para la comunidad universitaria. Los fondos para el desarrollo del nuevo sistema pueden ser obtenidos de este presupuesto ya que serán utilizados para mejorar un servicio en el recinto. La inversión en equipo y programado es pequeña en relación con otras instituciones debido
a los acuerdos establecidos entre la Universidad y las compañías que proveen dichos equipos y programados. Esto no solo permite el desarrollo de este proyecto, sino el de muchos otros que se encuentran propuestos. Por último, se utilizarán recursos (personal) de la Universidad para el desarrollo de éste.
La solución fue propuesta es un sistema computarizado para agilizar los métodos y procedimientos relacionados con la administración de los procesos que envuelven el manejo de información de las coberturas médicas de los empleados que son sometidas al Departamento de Recursos Humanos.

Este sistema permitirá mejorar la calidad del servicio provisto por la oficina de Cobertura Médica, identificar aquellas áreas con mayor índice de problemas, y proveer al usuario de una herramienta para generar la actualizar la información de planes médicos de una manera rápida y eficaz.


TECNOLOGÍAS A UTILIZAR

Actualmente la universidad tiene un acuerdo con la compañía Microsoft Corp. que permite la adquisición de licencias de programas a bajo costo. Entre ellos se encuentra el programa “Office”, el cual es el “standard” impuesto por la Oficina de Gerencia y Presupuesto para todas las empresas de gobierno. Dentro del “Office” se encuentra la versión “Professional”, que incluye el programado “Access”. Dado que todas las computadoras del recinto tienen instalado el “Office Professional” podríamos aprovechar esto utilizando el programado “Access” como una opción a bajo costo para diseñar el “frontend”, que consta de las pantallas e informes completamente funcionales. Todo esto aplica solamente al personal administrativo del sistema, el cual consta de:

• El Rector

• La Administración

• El Vicedecano

• Dos administradores del sistema: el “project manager” y el técnico de mantenimiento En resumen, la parte lógica del sistema constará de:

1. La parte del usuario – compuesta por una forma instalada en un Web Server con acceso a los usuarios de la oficina de Cobertura Médica.

2. La parte administrativa – compuesta de pantallas e informes diseñados utilizando “Access”, las cuales estarán enlazadas a la base de datos.

3. Un sistema de DBMS para almacenar los datos, que será “SQL Server”. Además, se recomienda adquirir una licencia del programado “Office Developer” para el desarrollo del proyecto, ya que contiene componentes adicionales de programación para “Access” y una aplicación llamada “Packaging Wizard”, que se utilizará para la creación del CD que contendrá las herramientas para instalar el sistema en cada computadora del personal administrativo.

Teniendo en cuenta que la Administración se encuentra analizando la posibilidad de implantar varios sistemas para el Decanato, y dado el hecho de que el sistema recomendado almacenará y procesará una gran cantidad de datos, es vital el que se escoja un servidor que provea los recursos necesarios para realizar ambas tareas sin que se afecte el rendimiento. Hay que enfatizar que en el servidor se instalará más de una base de datos.pueden ser obtenidos de este presupuesto ya que serán utilizados para mejorar un servicio en el recinto.

La inversión en equipo y programado es pequeña en relación con otras instituciones debido a los acuerdos establecidos entre la Universidad y las compañías que proveen dichos equipos y programados. Esto no solo permite el desarrollo de este proyecto, sino el de muchos otros que se encuentran propuestos. Por último, se utilizarán recursos (personal) de la Universidad para el desarrollo de éste.

La solución fue propuesta es un sistema computarizado para agilizar los métodos y procedimientos relacionados con la administración de los procesos que envuelven el manejo de información de las coberturas médicas de los empleados que son sometidas al Departamento de Recursos Humanos.

Este sistema permitirá mejorar la calidad del servicio provisto por la oficina de Cobertura Médica, identificar aquellas áreas con mayor índice de problemas, y proveer al usuario de una herramienta para generar la actualizar la información de planes médicos de una
manera rápida y eficaz.

TECNOLOGÍAS A UTILIZAR
Actualmente la universidad tiene un acuerdo con la compañía Microsoft Corp. que permite
la adquisición de licencias de programas a bajo costo. Entre ellos se encuentra el programa
“Office”, el cual es el “standard” impuesto por la Oficina de Gerencia y Presupuesto para
todas las empresas de gobierno. Dentro del “Office” se encuentra la versión “Professional”,
que incluye el programado “Access”. Dado que todas las computadoras del recinto tienen
instalado el “Office Professional” podríamos aprovechar esto utilizando el programado
“Access” como una opción a bajo costo para diseñar el “frontend”, que consta de las
pantallas e informes completamente funcionales. Todo esto aplica solamente al personal
administrativo del sistema, el cual consta de:
• El Rector
• La Administración
• El Vicedecano
• Dos administradores del sistema: el “project manager” y el técnico de mantenimiento
En resumen, la parte lógica del sistema constará de:
1. La parte del usuario – compuesta por una forma instalada en un Web Server con acceso
a los usuarios de la oficina de Cobertura Médica.
2. La parte administrativa – compuesta de pantallas e informes diseñados utilizando
“Access”, las cuales estarán enlazadas a la base de datos.
3. Un sistema de DBMS para almacenar los datos, que será “SQL Server”.
Además, se recomienda adquirir una licencia del programado “Office Developer” para el
desarrollo del proyecto, ya que contiene componentes adicionales de programación para
“Access” y una aplicación llamada “Packaging Wizard”, que se utilizará para la creación del
CD que contendrá las herramientas para instalar el sistema en cada computadora del
personal administrativo.
Teniendo en cuenta que la Administración se encuentra analizando la posibilidad de
implantar varios sistemas para el Decanato, y dado el hecho de que el sistema
recomendado almacenará y procesará una gran cantidad de datos, es vital el que se escoja
un servidor que provea los recursos necesarios para realizar ambas tareas sin que se afecte
el rendimiento. Hay que enfatizar que en el servidor se instalará más de una base de datos.


Entre las especificaciones para este equipo se encuentran las siguientes:
• Doble procesador a 3.0 Ghz, preferiblemente Intel Xeon, ya que estos están diseñados
para el procesamiento de tareas de alto rendimiento, como lo son las bases de datos
• Una cantidad considerable de memoria (aproximadamente 8 GB)
• Que contengan dos arquitecturas de discos duros:
o 2 discos en RAID 1 para almacenar el sistema operativo y el SQL Server
o 4 discos en RAID 5 para almacenar los datos
El equipo no sólo contendrá estos sistemas, sino que servirá como controlador de dominio,
por lo que su utilidad será múltiple. Esto permitirá implantar una forma de seguridad más
robusta, ya que las cuentas de “SQL Server” autenticarán contra las cuentas de usuario del
servidor, lo que se conoce como “mixed mode authentication”.
El Recinto cuenta con una infraestructura de telecomunicaciones que es administrada por la
Oficina de Tecnologías de Información. La oficina implantó hace unos años un “Firewall” que
protege al recinto de accesos no autorizados y la distribución de las computadoras dentro
de la red fue realizada utilizando el concepto de redes privadas. Ya que el sistema de
manejo de órdenes de servicio se utilizará solamente a nivel interno, ésta es la estructura
más apropiada para la implantación del sistema sin arriesgar la seguridad.
ETAPAS Y TIEMPO DE DESARROLLO DEL PROYECTO
Actividad
Actividades que
le preceden
Tiempo
estimado
A. Análisis del problema Ninguna 2 días
B. Formulación de preguntas para la entrevista a la
administración (gerencia)
Ninguna 2 días
C. Realización de entrevista a la administración B 1 día
D. Análisis de la entrevista (análisis necesidades) A,C 1 día
E. Creación y revisión del “Data Flow Diagram” D 4 días
F. Diagrama de procedimiento E 2 días
G. Creación de Base de Datos E 2 días
H. Diseño básico de pantalla de usuarios, creación de
programación PHP y “stored procedures”, creación de
pantallas parte administrativa
G 5 días
I. Creación manual sistema F,H 5 días
J. Pruebas al sistema F,H 3 días
K. Presentación a la gerencia, aceptación de cambios J 1 día
L. Realización de cambios (de ser necesario) K 3 días
M. Presentación a los usuarios, aceptación cambios I,L 2 días
N. Informe de cambios solicitados por usuarios a la
gerencia
M 1 día
O. Realización de cambios (de ser necesario) N 3 días
P. Creación manual usuario O 5 días
Q. Adiestramiento a usuarios y gerencia P 1 día

ANALISIS DE COSTO / BENEFICIO


COSTOS ACTUALES COSTO
- SALARIOS
Estimado de salario basado en tiempo dedicado al proyecto
Project Manager (Sueldo: $30000 anual según sueldo U.P.R.)
Tiempo dedicado al proyecto: 4 horas diarias @ $16.60/hora por 6 meses
Técnico de sistemas a cargo del mantenimiento (Sueldo: $22000 anual según
UPR)
Tiempo dedicado a mantenimiento: 1 hora diarias @ $12.22/hora por 1 año
$8000.00
$2932.00
Total salarios $10932.00
- PROGRAMADO
Programa “Office XP Developer” $125.00
Easy Mail Objects 6.0 (componente especial de programación para envío de
correo electrónico a través de sistemas construidos en “Access”)
$499.00
Programa “SQL Server 2000” $375.00
Licencias de uso (CAL) de “SQL Server” (6 @ $65.00 c/u) $390.00
Total costos programados $1379.00
- EQUIPO
Servidor Dell PowerEdge 4600 $11226.00
- Total (salarios + programado + equipo) $23537.00
BENEFICIOS
Beneficios Tangibles (se mide por tiempo o dinero)
1. Reducir a un 0.01% el tiempo necesario para realizar un informe de último momento
a la alta gerencia (esto es en los informes ya existentes en el sistema. Aquellos que
son solicitados por primera vez su tiempo será reducido al 3%).
2. Reducir en un 80% el tiempo requerido para buscar la información relacionada.
3. Reducir en un 30% en costos por reparaciones, ya que el sistema ayudará a que el
tiempo de respuesta sea casi inmediata.
Beneficios Intangibles (no se mide por tiempo o dinero)
1. Aumentar en un 100% la precisión de los informes estadísticos.
2. Reducir a un 25% las situaciones causadas por el efecto de no haber realizado una
tarea a tiempo ya que de no ser reparada, podría causar daños a otras áreas o equipo.

1. Tareas a desarrollar
Elaborar una documentación que integre los siguientes contenidos:
a) Organigrama jerárquico.
Se pide elaborar un posible organigrama jerárquico para la Facultad.
b) Análisis de factibilidad (operacional, técnica, económica y financiera).
Se pide elaborar para cada factibilidad al menos 4 preguntas dirigidas a diferentes
personalidades o sectores de la Facultad enfocando distintos factores (operacionales,
técnicos, económicos y financieros) que permitan determinar la viabilidad de la
sistematización.
c) Delimitación del Proyecto
Para ello se pide lo siguiente:
1. Descripción de subsistemas: Describa brevemente los subsistemas:
2. Relaciones entre los actores principales.
d) Requerimientos
Se pide elaborar un plan de entrevistas que especifique:
• Usuarios a entrevistar.
• Secuencia en la que serán entrevistados.
• Un plan de entrevista para cada usuario.
e) Conclusiones

Elabore una conclusión grupal sobre el trabajo.


Apuntes para considerar
a) Organigrama jerárquico
Siempre es valioso disponer de las dependencias funcionales entre los distintos
componentes de una organización (departamentos, personas, etc.), lo cual ayudará a
averiguar cuales son los subsistemas funcionales que la componen y por tanto son
susceptibles de informatizar.
b) Análisis de factibilidad
Resulta sumamente importante reconocer las partes sobre las cuales centraremos el
estudio del Sistema de Información o dicho de otra forma, que subsistemas de información
se van a analizar. Es muy importante realizar un estudio de este tipo para asignar
prioridades sobre los subsistemas. En este sentido se estudiará la factibilidad operacional,
la factibilidad técnica y la factibilidad financiera y económica.
c) Delimitación del Proyecto
• En este apartado el alumno deberá tomar una decisión sobre cual o cuales subsistemas
se va a desarrollar (hay que tener en cuenta que todos los sistemas no son igualmente
complejos).
d) Requerimientos
A partir de este momento el alumno ya está en condiciones de realizar el análisis de
requerimientos o análisis de requisitos, de tal forma que debe de averiguar cuales son los
puntos clave sobre los cuales centrar el análisis de su sistema global.
• Entrevistas: Este es el método más corriente para recoger información del usuario. Es
un proceso continuo utilizado por el alumno para construir gradualmente un modelo del
sistema y para obtener conocimientos sobre los problemas del sistema.






No hay comentarios:

Publicar un comentario