Evaluacin de los sistemas

7.1 Evaluacin de sistemas

La elaboracin 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 estratgico para la elaboracin de los sistemas o si se estn elaborando sin el

adecuado sealamiento de prioridades y de objetivos.

El plan estratgico deber establecer los servicios que se prestarn en un

futuro contestando preguntas como las siguientes:

a) Cules servicios se implementarn?

b) Cundo se pondrn a disposicin de los usuarios?

c) Qu caractersticas tendrn?

d) Cuntos recursos se requerirn?

La estrategia de desarrollo deber establecer las nuevas aplicaciones y

recursos que proporcionar la direccin de informtica y la arquitectura en que

estarn fundamentados.

- Qu aplicaciones sern desarrolladas y cundo?

- Qu tipo de archivos se desarrollarn y cundo?

- Qu bases de datos sern desarrolladas y cundo?

- Qu lenguajes se utilizarn y en qu software?

- Qu tecnologa ser utilizada y cundo se implementar?

- Cuntos recursos se requerirn aproximadamente?

- Cul es aproximadamente el monto de la inversin en hardware y

software?

En lo referente a la consulta a los usuarios, el plan estratgico debe definir

los requerimientos de informacin de la organizacin.

- Qu estudios van a ser realizados al respecto?

- Qu metodologa se utilizar para dichos estudios?

- Quin administrar y realizar estos estudios?

En el rea de auditoria interna debe evaluarse cul ha sido la participacin

del auditor y los controles establecidos.

Por ltimo, el plan estratgico determina la planeacin de los recursos.

- Contempla el plan estratgico las ventajas de la nueva tecnologa?

- Cules sern los conocimientos requeridos por los recursos humanos

planeados?

- Se contemplan en la estructura organizacional los nuevos niveles

jerrquicos requeridos por el plan estratgico?

- Cul es la inversin requerida en servicios, desarrol o y consulta a los

usuarios?

El proceso de planeacin de sistemas deber asegurarse de que todos los

recursos requeridos estn claramente identificados en el plan de desarrollo de

aplicaciones y datos. Estos recursos (hardware, software y comunicaciones)

debern ser compatibles con la estrategia de la arquitectura de la tecnologa, con

que se cuenta actualmente.

Para identificar los problemas de los sistemas primero debemos detectar

los sntomas, los cuales son un reflejo del rea problemtica; y despus de

analizar los sntomas podremos definir y detectar las causas, parte medular de la

auditora.

Debemos aprender a reunir todos los sntomas y a distinguirlos antes de

sealar las causas, evitando tomar los sntomas como causas y dejando fuera

todo lo que es rumores sin fundamento.

Los sistemas debemos evaluarlos de acuerdo con el ciclo de vida que

normalmente siguen:

1) requerimientos del usuario,

2) estudio de factibilidad,

3) diseo general,

4) anlisis,

5) diseo lgico,

6) desarrollo fsico,

7) pruebas,

8) implementacin,

9) evaluacin,

10) modificaciones,

11) instalacin,

12) 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 susceptible de realizarse, cul es su relacin

costo/beneficio y si es conductualmente favorable.

Se deber solicitar el estudio de factibilidad de los diferentes sistemas que

se encuentren en operacin, as como los que estn en la fase de anlisis para

evaluar si se considera la disponibilidad y caractersticas del equipo, los sistemas

operativos y lenguajes disponibles, las necesidades de los usuarios, las formas de

utilizacin de los sistemas, el costo y los beneficios que reportar el sistema, el

efecto que producir en quienes lo usarn y el efecto que stos tendrn sobre el

sistema, y la congruencia de los diferentes sistemas.

En el caso de sistemas que estn funcionando, se deber comprobar si

existe el estudio de factibilidad con los puntos sealados, y comparar con la

realidad lo especificado en el estudio de factibilidad.

Por ejemplo, en un sistema que el estudio de factibilidad seal

determinado costo y una serie de beneficios de acuerdo con las necesidades del

usuario, debemos comparar cul 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 operacin,

cosa que en la prctica son costos directos, indirectos y de operacin.

Los beneficios que justifiquen el desarrollo de un sistema pueden ser el

ahorro en los costos de operacin, la reduccin del tiempo de proceso de un

sistema, mayor exactitud, mejor servicio, una mejora en los procedimientos de

control, mayor confiabilidad y seguridad.

Entre los problemas mas comunes en los sistemas estn los siguientes

1. Falta de estndares en el desarrollo, en el anlisis y la programacin.

2. Falta de participacin y de revisin por parte de la alta gerencia.

3. Falta de participacin de los usuarios.

4. Inadecuada especificacin del sistema al momento de hacer el diseo

detallado.

5. Deficiente anlisis costo/beneficio.

6. Nueva tecnologa no usada o usada incorrectamente.

7. Inexperiencia por parte del personal de anlisis y del de programacin.

8. Diseo deficiente.

9. Proyeccin pobre de la forma en que se realizar el sistema.

10. Control dbil o falta de control sobre las fases de elaboracin del

sistema y sobre el sistema en s.

11. Problemas de auditora.

12. Inadecuados procedimientos de seguridad, de recuperacin y de

archivos.

13. Falta de integracin de los sistemas (elaboracin de sistemas aislados

programas que no estn unidos como sistemas).

14. Documentacin inadecuada o inexistente.

15. Dificultad de dar mantenimiento al sistema, principalmente por falta de

documentacin o excesivos cambios y modificaciones hechos al sistema.

16. Problemas en la conversin e implementacin.

17. Procedimientos incorrectos o no autorizados.

7.2 Evaluacin del anlisis

En esta etapa se evaluarn las polticas, procedimientos y normas que se

tienen para llevar a cabo el anlisis

Se deber evaluar la planeacin de las aplicaciones que pueden provenir

de tres fuentes principales.

1. La planeacin estratgica: agrupadas las aplicaciones en conjuntos

relacionados entre si y no como programas aislados. Las aplicaciones

deben comprender todos los sistemas que puedan ser desarrollados en

la organizacin, independientemente de los recursos que impliquen su

desarrollo y justificacin en el momento de la planeacin.

2. Los requerimientos de los usuarios.

3. El inventario de sistemas en proceso al recopilar la informacin de los

cambios que han sido solicitados, sin importar si se efectuaron o se

registraron.

La situacin de una aplicacin en dicho inventario puede ser alguna de las

siguientes

a) Planeada para ser desarrollada en el futuro.

b) En desarrollo.

c) En proceso, pero con modificaciones en desarrollo.

d) En proceso con problemas detectados.

e) En proceso sin problemas.

f) En proceso espordicamente.

NOTA: Se deber documentar detalladamente la fuente que gener la

necesidad de la aplicacin. La primera parte ser evaluar la forma en que se

encuentran especificadas las polticas, los procedimientos y los estndares de

anlisis, si es que se cumplen y si son los adecuados para la organizacin.

Es importante revisar la situacin en que se encuentran los manuales de

anlisis y si estn acordes con las necesidades de la organizacin. En algunas

ocasiones se tiene una microcomputadora, con sistemas sumamente sencillos y

se solicita que se l eve a cabo una serie de anlisis que despus hay que plasmar

en documentos sealados en los estndares, lo cual hace que esta fase sea muy

compleja y costosa. Los sistemas y su documentacin deben estar acordes con

las caractersticas y necesidades de una organizacin especfica.

Se debe evaluar la obtencin de datos sobre la operacin, flujo, nivel,

jerarqua de la informacin que se tendr a travs del sistema, as como sus

lmites e interfases con otros sistemas. Se han de comparar los objetivos de los

sistemas desarrollados con las operaciones actuales, para ver si el estudio de la

ejecucin deseada corresponde al actual.

La auditora en informtica debe evaluar los documentos y registros usados

en la elaboracin del sistema, as como todas las salidas y reportes, la descripcin

de las actividades de flujo de la informacin y de procedimientos, los archivos

almacenados, su uso y su relacin con otros archivos y sistemas, su frecuencia de

acceso, su conservacin, su seguridad y control, la documentacin propuesta, las

entradas y salidas del sistema y los documentos fuentes a usarse.

Con la informacin obtenida podremos contestar a las siguientes preguntas:

1. Se est ejecutando en forma correcta y eficiente el proceso de informacin?

2. Puede ser simplificado para mejorar su aprovechamiento?

3. Se debe tener una mayor interaccin con otros sistemas?

4. Se tiene propuesto un adecuado control y seguridad sobre el sistema?

5. Est en el anlisis la documentacin adecuada?

7.3 Evaluacin del diseo lgico del sistema

En esta etapa se debern analizar las especificaciones del sistema.

Qu deber hacer?, Cmo lo deber hacer?, secuencia y ocurrencia de

los datos, el proceso y la salida de reportes

Una vez que hemos analizado estas partes, se deber estudiar la

participacin que tuvo el usuario en la identificacin del nuevo sistema, la

participacin de auditora interna en el diseo de los controles y la determinacin

de los procedimientos de operacin y decisin.

Al tener el anlisis del diseo lgico del sistema debemos compararlo con lo

que realmente se est obteniendo: como en el caso de la administracin en la cual

debemos evaluar lo planeado, cmo fue planeado y lo que realmente se est

obteniendo.

Los puntos a evaluar son:

a) Entradas

b) Salidas

c) Procesos

d) Especificaciones de datos

e) Especificaciones de proceso

f) Mtodos de acceso

g) Operaciones

h) Manipulacin de datos (antes y despus del proceso electrnico de

datos)

i) Proceso lgico necesario para producir informes identificacin de

archivos, tamao de los campos y registros Proceso en lnea o lote y su

justificacin

j) Frecuencia y volmenes de operacin

k) Sistemas de seguridad

I) Sistemas de control

m) Responsables

n) Nmero de usuarios

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

1) Manual del usuario

2) Descripcin de flujo de informacin

3) Descripcin y distribucin de informacin

4) Manual deformas

5) Manual de reportes

6) Lista de archivos y especificacin

Lo que debemos determinar en el sistema:

En el procedimiento:

Quin hace, cundo y cmo?

Qu formas se utilizan en el sistema?

Son necesarias, se usan, estn duplicadas?

El nmero de copias es el adecuado?

Existen puntos de control o faltan?

En la grfica de flujo de informacin:

Es fcil de usar?

Es lgica?

Se encontraron lagunas?

Hay faltas de control?

En las formas de diseo:

Cmo est usada la forma en el sistema?

Qu tan bien se ajusta la forma al procedimiento?

Cul es el propsito, por qu se usa?

Se usa y es necesaria?

El nmero de copias es el adecuado?

Quin lo usa?

Lo que debemos revisar en las formas de diseo:

Numeracin.

Est numerada la forma?

Es necesaria su numeracin?

Est situada en un solo lugar fcil de encontrar?

Cmo se controlan las hojas numeradas y su utilizacin?

Ttulo.

Da el ttulo de la forma una idea clara sobre su funcin bsica?

Espacio.

Si la forma est mecanografiada:

hay suficiente espacio para escribir con mquina rpidamente, con

exactitud y eficiencia?

Si la forma se llena a mano:

hay el espacio adecuado para que se escriba en forma legible?

Tabulacin.

Si la forma est mecanografiada:

permite su tabulacin llenarla uniformemente?

Es la tabulacin la mnima posible?

Una excesiva tabulacin disminuye la velocidad y eficiencia para l enarla.

Adems le da una apariencia desigual y confusa.

Zonas.

Estn juntos los datos relacionados entre s?

Si los datos similares estn agrupados por zonas, todas las personas que

usan la forma ahorran tiempo. La informacin similar reunida por zonas, hace ms

fcil su referencia, se mecanografa ms eficientemente y se revisa con ms

rapidez. Posteriormente se debe verificar que las zonas de las formas que sean

utilizadas para captura estn situadas de manera congruente con el diseo de las

pantallas de captura.

Rayado.

Da la forma una apariencia desordenada y difcil de entender por el uso

confuso y excesivo de lneas delgadas, gruesas o de doble raya?

Instrucciones.

Le dice la forma al usuario cmo debe llenarla?

Formas autoinstructivas o que suministran la informacin de cmo llenarlas

permiten que el personal nuevo y los otros trabajen con supervisin y errores

mnimos. De no ser as existe un manual de llenado de formas, se debe revisar si

las instrucciones son claras, si son congruentes con la forma y si son excesivas,

ya que un diseo excesivo de instrucciones pueda provocar confusin y hacer que

sea poco clara.

Firmas.

Existe suficiente espacio para una firma legible?

Est el espacio debidamente identificado respecto a la firma que necesita?

La firma se utiliza como un mero tramite o realmente controla la persona

que firma lo que se est firmando?

Nombres.

Usa la forma los nombres de los puestos, en lugar del nombre del

individuo?

No es conveniente imprimir nombres de personas debido a la rotacin de

personal.

Encabezados ambiguos.

Se indica con exactitud qu fechas, qu nmeros, o qu firmas se

requieren? Se deben evitar encabezados dudosos o ambiguos.

Rtulos.

Son demasiados l amativos?

Son demasiado discretos?

Existe un adecuado contraste entre los rtulos y los textos respecto a su

tamao, color y ubicacin para que los datos solicitados sean identificados

fcilmente?

Ubicacin de los rtulos.

Estn los rtulos o encabezados debajo de la lnea en donde se debe

mecanografiar?

Esto causa prdida de tiempo, porque la mecangrafa tiene que mover el

carro para ver el rtulo y acomodarlo nuevamente para escribir la informacin

deseada.

Casil eros.

Se usan pequeos espacios enmarcados ( ) para con una sola indicacin

reducir escritos largos o repetitivos?,

Los espacios son suficientes o excesivos?

Tipo de papel.

Son el peso y calidad del papel apropiado para esa forma?

Use papel ms pesado y de mejor calidad para aquellas formas que

requieren un manejo excesivo. Use papel de menor peso con formas que se usen

poco, para reducir costo y espacio en los archivos.

Tamaos estndar.

Tiene la forma un tamao estndar?

El tamao estndar se ajusta a sobres y archivos estndar. Adems reduce

existencias de papel, manejo y tiempo y costo de impresin. Se debe considerar

que el costo del papel que no es de tamao estndar es considerablemente mayor

que el de tamao estndar.

Color.

Permite el contraste del color del papel una lectura eficiente?

Las formas en colores como el anaranjado, el verde, el azul, el gris, etc., en

tonos obscuros, son difciles de leer porque no ofrecen suficiente contraste entre la

impresin (NEGRO) y el papel. Ciertos colores brillantes cansan la vista. Se debe

tener cuidado tanto en el color del papel como en el color de la tinta. Las copias

deben estar identificadas de acuerdo con el color.

Anlisis de informes

Una vez que se ha estudiado los formatos de entrada debemos analizar los

informes para posteriormente evaluarlos con la informacin proporcionada por la

encuesta a los usuarios. Despus de describir el contenido de los informes se

debe tener el anlisis de datos e informacin.

Ruido, redundancia, Entropa

En la auditora de sistemas hay que estudiar la redundancia, el ruido y la

entropa que tiene cada uno de los sistemas.

En primer lugar, debemos considerar como comunicacin "La transferencia

de informacin del emisor al receptor de manera que ste la comprenda",

Koontz/O'Donnell/ Weihrich; Administracin, Mc Graw Hill.

El ruido es todo aquello que interfiere en una adecuada comunicacin; no

solamente los sonidos sino todo aquello que impida la adecuada comunicacin, y

Koontz/O'Donnell/WeiHrich definen el ruido como "Cualquier cosa (sea en el

emisor, en la transmisin o en el receptor) que obstaculiza la comunicacin"; as,

por ejemplo; si una persona se encuentra jugando, sin hacer necesariamente

algn sonido, en el momento que otra est hablando, se considera como tipo de

ruido para el sistema.

En el caso de un sistema computarizado el error en la captura, una pantalla

de la terminal demasiado llena de informacin y poco entendible o un reporte

inadecuado se deben considerar como ruido en el sistema, ya que impide una

buena comunicacin de la informacin.

La redundancia es toda aquella duplicidad que tiene el sistema con la

finalidad de que, en caso de que exista ruido, esta redundancia permita que la

informacin llegue al receptor en forma adecuada.

Podemos enviar un mensaje de la forma siguiente: Lleg por avin el da

martes 31 de octubre de 1988 del presente ao, a las 16:00 hrs. de la tarde a la

ciudad de Cancn, Quintana Roo, Mxico.

En el mensaje anterior tenemos excesiva redundancia debido a que el 31

de octubre de 1988 es martes y si estamos en 1988 es del presente ao. Las

16:00 hrs. siempre es de la tarde y la ciudad de Cancn est slo en el estado de

Quintana Roo, Mxico. Y en cambio puede ser incompleta ya que no especifica la

lnea area ni el vuelo en que llegar.

La redundancia anterior puede ser conveniente en el caso de que se

necesiten cerciorarse de que la informacin se recibe correctamente y esto estar

en funcin de lo delicado que sea la informacin y del riesgo que se corre en caso

de una prdida total o parcial de la misma.

Un ejemplo de redundancia dentro de las mquinas es el bit de paridad, el

cual permite que en caso de prdida de un bit, se pueda recuperar la informacin

que contiene el byte.

La redundancia es una forma de control que permite que, si existe ruido, la

comunicacin pueda llevarse a cabo en forma eficiente, y deber haber mayor

redundancia entre ms arriesgada, costosa o peligrosa sea la prdida de

informacin; pero a su vez debemos estar conscientes que el exceso de

redundancia puede provocar ruido. Esto se da, por ejemplo, en el caso de que un

profesor desee ser tan claro que se dedique a dar demasiados ejemplos; puede

provocar ruido en el sentido que llegue a confundir o aburrir a sus alumnos y el

nmero excesivo de ejemplos impida una adecuada comunicacin.

En la auditora se debe considerar que todo sistema ha de ofrecer un

nmero adecuado de redundancia segn su nivel de importancia, de modo que

permita una buena comunicacin aun en el caso de que exista ruido, pero sin ser

la redundancia de tal magnitud que a su vez provoque ruido.

Tambin debemos considerar que con un mayor control y redundancia, se

incrementa tambin el costo de los sistemas. Hay que tener un adecuado nivel de

control y redundancia que no sea de tal magnitud que provoque ruido o bien que

no sea demasiado costoso en relacin con el nivel de seguridad que requiere el

sistema.

Entropa

El diccionario la define como: "Cantidad de energa que por su degradacin

no puede aprovecharse", Nuevo Diccionario Espaol Ilustrado SOPENA.

La entropa en un sistema, por ejemplo de un motor, es el calor que genera,

el cual es energa que por sus caractersticas no puede aprovecharse. En el caso

del sistema l amado motor se utiliza esta entropa; por ejemplo, en la calefaccin

del automvil o bien para calentar el aire y la gasolina que entra al motor (en el

caso de motores turbo).

En un sistema computarizado debemos procurar reducir al mximo esta

entropa, y una de las formas de reducirla es interconectar sistemas, en tal forma

que esa cantidad de energa no usada en un sistema pueda ser utilizada en otro

sistema. Por ejemplo, al capturar el catlogo de clientes para el sistema de

cobranzas, con un poco de informacin adicional lo podemos utilizar en

contabilidad.

Matriz de recepcin y distribucin de documentos

Una forma objetiva de evaluar la informacin que se encuentra en un

sistema es emplear la matriz de recepcin y distribucin de documentos, en la cual

se define de modo grfico la distribucin de documentos y los resultados

obtenidos en un proceso.

Matriz de entrada/salida

Otra forma de analizar la informacin es recurrir al impacto de los datos en

entrada/salida, la cual puede ser establecida por medio de la matriz de

entrada/salida en que se ve en forma objetiva cmo la informacin est dentro del

sistema y puede detectar la redundancia, analizar informacin faltante y optimizar

los reportes que se obtienen.

La matriz de entrada/salida puede, por ejemplo darnos la imagen de los

reportes que con pequeas diferencias son iguales (redundantes), de la

informacin que puede pedir el usuario pero que no es posible proporcionar

debido a que no se captur, de los datos que son capturados pero que no se

utilizan, as como los posibles reportes adicionales que se pueden obtener si el

usuario llegase a solicitarlos.

Esta matriz es muy importante en el caso de que tengamos un programa

generadores de reportes en el que los usuarios elaboran directamente sus

reportes, ya que se pueden hacer reportes en forma indiscriminada provocando

duplicidad y "reportitis" (tendencia a generar reportes sin tener una adecuada

justificacin) o bien informes que deben ser obtenidos por medio de pantallas para

no utilizar papel y para una forma ms adecuada de utilizacin.

7.4 Evaluacin del desarrollo del sistema

En esta etapa del sistema se debern auditar los programas, su diseo, el

lenguaje utilizado, interconexin entre los programas y caractersticas del

hardware empleado (total o parcial) para el desarrollo del sistema.

Como se analiz en la auditoria de los programas, es conveniente hacer la

evaluacin cuando el sistema ya se implement y se encuentra trabajando

correctamente.

Al evaluar un sistema de informacin se tendr presente que todo sistema

debe proporcionar informacin 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 ms econmica 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 informacin entre nodos. El proceso de planeacin de sistemas

debe definir la red ptima de comunicaciones, recordando que el plan de

aplicaciones proporciona informacin de la ubicacin planeada de las terminales,

los tipos de mensajes requeridos, el trfico esperado en las lneas de

comunicacin y otros factores que afectan el diseo.

Es importante considerar las variables que afectan a un sistema: ubicacin

en los niveles de la organizacin, el tamao y los recursos que utiliza. Las

caractersticas que deben evaluarse en los sistemas son:

Dinmicos (susceptibles de mortificarse).

Estructurados (las interacciones de sus componentes o subsistemas

deben actuar como un todo).

Integrados (un slo objetivo). En l habr sistemas que puedan ser

interrelacionados y no programas aislados.

Accesibles (que estn disponibles).

Necesarios (que se pruebe su utilizacin).

Comprensibles (que contengan todos los atributos).

Oportunos (que est la informacin en el momento que se requiere).

Funcionales (que proporcionen la informacin adecuada a cada nivel).

Estndar (que la informacin tenga la misma interpretacin en los distintos

niveles).

Modulares (facilidad para ser expandidos o reducidos).

Jerrquicos (por niveles funcionales).

Seguros (que slo las personas autorizadas tengan acceso).

nicos (que no duplique informacin).

7.5 Control de proyectos

Debido a las caractersticas propias del anlisis y la programacin, es muy

frecuente que la implantacin de los sistemas se retrase y se llegue a suceder que

una persona lleva trabajando varios aos dentro de un sistema o bien que se

presenten irregularidades en las que los programadores se ponen a realizar

actividades ajenas a la direccin de informtica. Para poder controlar el avance de

los sistemas, ya que sta es una actividad intelectual de difcil evaluacin, se

recomienda que se utilice la tcnica de administracin por proyectos para su

adecuado control.

Qu significa que un sistema sea liberado en el plazo establecido y dentro

del presupuesto? Pues sencillamente que el grado de control en el desarrollo del

mismo es el adecuado o tal vez el ptimo. Pero esto no se consigue gratuitamente

o porque la experiencia o calidad del personal de desarrollo sea alta, sino porque

existe un grado de control durante su desarrollo que le permite obtener esta

cualidad. Cabe preguntar aqu: quin es el elemento adecuado para proporcionar

este grado de control?

Para poder tener una buena administracin por proyectos se requiere que

el analista o el programador y su jefe inmediato elaboren un plan de trabajo en el

cual se especifiquen actividades, metas, personal participante y tiempos. Este plan

debe ser revisado peridicamente (semanal, mensual o bimestralmente) para

evaluar el avance respecto a lo programado.

La estructura estndar de la planeacin de proyectos deber incluir la

facilidad de asignar fechas predefinidas de terminacin de cada tarea. Dentro de

estas fechas debe estar el calendario de reuniones de revisin, las cuales tendrn

diferentes niveles de detalle. Son necesarias las reuniones a nivel tcnico que

requieran la participacin del personal especializado de la direccin de informtica

para definir la factibilidad de la solucin y los resultados planeados. Son muy

importantes las reuniones con los usuarios finales, para verificar la validez de los

resultados esperados y, finalmente, se deben planear.

La evaluacin de proyectos y su control puede realizarse de acuerdo con

diferentes autores y a manera de ejemplo presentamos el siguiente.

Cuestionario para la evaluacin de proyectos,

Existe una lista de proyectos de sistema de procesamiento de informacin

y fechas programadas de implantacin que puedan ser considerados como plan

maestro?

Est relacionado el plan maestro con un plan general de desarrollo de la

dependencia?

Ofrece el plan maestro la atencin de solicitud?

Asigna el plan maestro un porcentaje del tiempo total de produccin al

reproceso o fallas de equipo?

Poner la lista de proyectos a corto plazo y a largo plazo.

Poner una lista de sistemas en proceso periodicidad y usuarios. Quin

autoriza los proyectos?

Cmo se asignan los recursos?

Cmo se estiman los tiempos de duracin?

Quin interviene en la planeacin de los proyectos?

Cmo se calcula el presupuesto del proyecto?

Qu tcnicas se usan en el control de los proyectos?

Quin asigna las prioridades?

Cmo se asignan las prioridades?

Cmo se controla el avance del proyecto?

Con qu periodicidad se revisa el reporte de avance del proyecto?

Cmo se estima el rendimiento del personal?

Con que frecuencia se estiman los costos del proyecto para compararlo

con lo presupuestado?

Qu acciones correctivas se toman en caso de desviaciones?

Qu pasos y tcnicas siguen en la planeacin y control de los proyectos?

Enumrelos secuencialmente.

( ) Determinacin de los objetivos.

( ) Sealamiento de las polticas.

( ) Designacin del funcionario responsable del proyecto.

( ) Integracin del grupo de trabajo.

( ) Integracin de un comit de decisiones.

( ) Desarrollo de la investigacin.

( ) Documentacin de la investigacin.

( ) Factibilidad de los sistemas.

( ) Anlisis y valuacin de propuestas.

( ) Seleccin de equipos.

Se l evan a cabo revisiones peridicas de los sistemas para determinar si

an cumplen con los objetivos para los cuales fueron diseados?

De anlisis

De programacin

Observaciones

SI

SI

NO

NO

Incluir el plazo estimado de acuerdo con los proyectos que se tienen en que

el departamento de informtica podra satisfacer las necesidades de la

dependencia, segn la situacin actual.

Como ejemplo de formato de control de proyectos vase en el anexo 3, del

calendario de actividades vanse los anexos 4 y 5, del reporte de los responsables

del sistema, vase el anexo 6, del control de programadores, vanse los anexos 7

y 8, de planeacin de la programacin, vanse los anexos 9 y 10, de los informes

de avance de programacin, vase el anexo 11, de control de avance de

programacin vanse los anexos 12, 13 y 14.

7.6 Control de diseo de sistemas de programacin

El objetivo es asegurarse de que el sistema funcione conforme a las

especificaciones funcionales, a fin de que el usuario tenga la suficiente

informacin para su manejo, operacin y aceptacin.

Las revisiones se efectan en forma paralela desde el anlisis hasta la

programacin y sus objetivos son los siguientes:

En laetapade anlisis.Identificar inexactitudes, ambigedades y

omisiones en las especificaciones.

En la etapa de diseo.Descubrir errores, debilidades, omisiones

antes de iniciar la codificacin.

En la etapa de programacin.Buscar la claridad, modularidad y

verificar con base en las especificaciones.

Esta actividad es muy importante ya que el costo de corregir errores es

directamente proporcional al momento que se detectan: si se descubren en el

momento de programacin ser ms alto el costo que si se detectan en la etapa

de anlisis.

Las pruebas del sistema tratan de garantizar que se cumplan los requisitos

de las especificaciones funcionales, verificando datos estadsticos, transacciones,

reportes, archivos, anotando las fallas que pudieran ocurrir y realizando los ajustes

necesarios. Los niveles de prueba pueden ser agrupados en mdulos, programas

y sistema total.

Esta funcin tiene una gran importancia en el ciclo de evaluacin de

aplicaciones de los sistemas de informacin y busca comprobar que la aplicacin

cumple las especificaciones del usuario, que se haya desarrollado dentro de lo

presupuestado, que tenga los controles necesarios y que efectivamente cumpla

con los objetivos y beneficios esperados.

Un cambio hecho a un sistema existente, como la creacin de uno nuevo,

presupone necesariamente cambios en la forma de obtener la informacin y un

costo adicional. Ambos debern ser evaluados.

Se debe evaluar el cambio (si lo hay) de la forma en que se ejecutan las

operaciones, se comprueba si mejora la exactitud de la informacin generada, si la

obtencin de los reportes efectivamente reduce el tiempo de entrega o si es ms

completa. Se determina cunto afecta las actividades del personal usuario o si

aumenta o disminuye el personal de la organizacin, as como los cambios entre

las interacciones entre los miembros de la organizacin. A fin de saber si aumenta

o disminuye el esfuerzo realizado y su relacin costo/beneficio para generar la

informacin destinada a la toma de decisiones, con objeto de estar en condiciones

de determinar la productividad y calidad del sistema.

El analista deber proporcionar la descripcin del funcionamiento del

sistema funcional desde el punto de vista del usuario, indicando todas las

interrelaciones del sistema, la descripcin lgica de cada dato, las estructuras que

esto forman, el flujo de informacin que tiene lugar en el sistema. Lo que el

sistema tomara como entrada, los procesos que ser realizados, las salidas que

deber proporcionar, los controles que se efectuarn para cada variable y los

procedimientos.

Cuestionarios para la evaluacin del diseo y prueba de los sistemas

Quienes intervienen al disear

Usuario.

Analista.

Programadores operadores.

Gerente de departamento.

Auditores internos. Asesores.

Otros.

Los analistas son tambin programadores?

SI( )

NO( )

Qu lenguaje o lenguajes conocen los analistas?

Cuntos analistas hay y qu experiencia tienen?

Qu lenguaje conocen los programadores?

Cmo se controla el trabajo de los analistas?

Cmo se controla el trabajo de los programadores?

Indique qu pasos siguen los programadores en el desarrol o de un

programa:

( ) Estudio de la definicin

( ) Discusin con el analista

( ) Diagrama de bloques

( ) Tabla de decisiones

( ) Prueba de escritorio

( ) Codificacin

( ) Compilacin

( ) Elaborar datos de prueba

( ) Solicitar datos al analista

( ) Correr programas con datos

( ) Revisin de resultados

( ) Correccin del programa

( ) Documentar el programa

( ) Someter resultados de prueba

( ) Entrega del programa

Es enviado a captura o los programadores capturan?

Quin los captura?

Qu documentacin acompaa al programa cuando se entrega?

Es muy frecuente que el programador no libere un sistema, esto es, que

contine dndole mantenimiento al sistema y sea el nico que lo conozca. Ello

puede deberse a amistad con el usuario, falta de documentacin, mal anlisis

preliminar del sistema, resistencia a cambiar a otro proyecto o bien a una situacin

que es muy grave dentro del rea de informtica: la aplicacin de "indispensables"

que son los nicos que tienen la informacin y, por lo tanto, son inamovibles.

Qu sucede respecto al mantenimiento o modificacin de un sistema

cuando el sistema no ha sido bien desarrollado (analizado, diseado, programado,

probado) e instalado? La respuesta es sencilla: necesitar cambios frecuentes por

omisiones o nuevos requerimientos.

En el caso de sistemas, muchas organizaciones estn gastando cerca del

80% de sus recursos de cmputo en mantenimiento.

El mantenimiento excesivo es consecuencia de falta de planeacin y control

del desarrollo de sistemas; la planeacin debe contemplar los recursos disponibles

y tcnicas apropiadas de desarrollo.

El control por su parte debe tener como soporte el establecimiento de

normas de desarrollo que han de ser verificadas continuamente en todas las

etapas del desarrollo de un sistema. Estas normas no pueden estar aisladas,

primero, del contexto particular de la direccin de informtica (ambiente) y,

segundo, de los lineamientos generales de la organizacin, para lo cual es

necesario contar con personal en desarrollo que posea suficiente experiencia en el

establecimiento de normas de desarrollo de sistemas. Estas mismas

caractersticas deben existir en el personal de auditora de sistemas.

Es poco improbable que un proyecto llegue a un final feliz cuando se ha

iniciado sin xito. Difcilmente estaremos controlando realmente el flujo de la

informacin de un sistema que desde su inicio ha sido mal analizado, mal

diseado, mal programado e incluso mal documentado.

El excesivo mantenimiento de los sistemas generalmente ocasionado por

un mal desarrollo, se inicia desde que el usuario establece sus requerimientos (en

ocasiones sin saber qu desea) hasta la instalacin del mismo, sin que se haya

establecido un plan de prueba del sistema para medir su grado de contabilidad en

la operacin que efectuar.

Para verificar si existe esta situacin, se debe pedir a los analistas y a los

programadores las actividades que estn desarrollando en el momento de la

auditora y evaluar si estn efectuando actividades de mantenimiento o de

realizacin de nuevos proyectos. En ambos casos se deber evaluar el tiempo que

llevan dentro del mismo sistema, la prioridad que se le asign y cmo est en el

tiempo real en relacin al tiempo estimado en el plan maestro.

El que los analistas, los programadores o unos y otros tengan acceso en

todo momento a los sistemas en operacin puede ser un grave problema y

ocasionar fallas de seguridad.

7.7 Instructivos de operacin

Debemos evaluar los instructivos de operacin de los sistemas para evitar

que los programadores tengan acceso a los sistemas en operacin y el contenido

mnimo de los instructivos de operacin.

El instructivo de operacin deber comprender:

Diagrama de flujo por cada programa.

- Diagrama particular de entrada-salida

- Mensaje y su explicacin

- Parmetros y su explicacin

- Diseo de impresin de resultados

- Cifras de control

- Frmulas de verificacin

- Observaciones

- instrucciones en caso de error

- Calendario de proceso y resultados

7.8 Forma de implantacin

La finalidad de evaluar los trabajos que se realizan para iniciar la operacin

de un sistema, esto es, la prueba integral del sistema, adecuacin, aceptacin por

parte del usuario, entrenamiento de los responsables del sistema, etc.

Indica cules puntos se toman en cuenta para la prueba de un sistema:

Prueba particular de cada programa

Prueba por fase validacin, actualizacin

Prueba integral del paralelo

Prueba en paralelo sistema

Otro (especificar)

( )

( )

( )

( )

( )

7.9 Equipo y facilidades de programacin

La seleccin de la configuracin de un sistema de cmputo incluye la

interaccin de numerosas y complejas decisiones de carcter tcnico. El impacto

en el rendimiento de un sistema de cmputo debido a cambios trascendentales en

el sistema operativo o en el equipo puede ser determinado por medio de un

paquete de pruebas (benchamark) que haya sido elaborado para este fin en la

direccin de informtica. Es conveniente solicitar pruebas y comparaciones entre

equipos (benchamark) para evaluar la situacin del equipo y del software en

relacin a otros que se encuentran en el mercado.

7.10 Entrevistas a usuarios

La entrevista se deber llevar a cabo para comparar datos proporcionados

y la situacin de la direccin de informtica desde el punto de vistas de los

usuarios.

Su objeto es conocer la opinin que tienen los usuarios sobre los servicios

proporcionados, as como la difusin de las aplicaciones de la computadora y de

los sistemas en operacin.

Las entrevistas se debern hacer, en caso de ser posible, a todos los

usuarios o bien en forma aleatoria a algunos de los usuarios, tanto de los ms

importantes como de los de menor importancia, en cuanto al uso del equipo.

Desde el punto de vista del usuario los sistemas deben:

1) Cumplir con los requerimientos totales del usuario.

2) Cubrir todos los controles necesarios.

3) No exceder las estimaciones del presupuesto inicial.

4) Sern fcilmente modificables.

Para que un sistema cumpla con los requerimientos del usuario, se necesita

una comunicacin completa entre usuario y el responsable del desarrollo del

sistema; en ella se deben definir claramente los elementos con que cuenta el

usuario, las necesidades de proceso de informacin y los requerimientos de

informacin de salida, almacenada o impresa.

En esta misma etapa debi haberse definido la calidad de la informacin

que ser procesada por la computadora, establecindose los riesgos de la misma

y la forma de minimizarlos. Para ello se debieron definir los controles adecuados,

establecindose adems los niveles de acceso a la informacin, es decir, quin

tiene privilegio de consultar, modificar o incluso borrar informacin.

Esta etapa habr de ser cuidadosamente verificada por el auditor interno

especialista en sistemas y por el auditor en informtica, para comprobar que se

logr una adecuada comprensin de los requerimientos del usuario y un control

satisfactorio de informacin.

Para verificar si los servicios que se proporcionan a los usuarios son los

requeridos y se estn proporcionando en forma adecuada, cuando menos ser

preciso considerar la siguiente informacin:

Descripcin de los servicios prestados.

Criterios de evaluacin que utilizan los usuarios para evaluar el nivel del

servicio prestado.

Reporte peridico del uso y concepto del usuario sobre el servicio.

Registro de los requerimientos planteados por el usuario.

Con esta informacin se puede comenzar a realizar la entrevista para

determinar si los servicios proporcionados y planeados por la direccin de

informtica cubren las necesidades de informacin de la organizacin.

Gua de cuestionario para la entrevista con el usuario

Considera que la direccin de informtica le da los resultados esperados?

SI ( )

Porqu?

NO ( )

Cmo considera usted, en general y el servicio proporcionado por la

direccin de informtica?

1. Deficiente

2. Aceptable

3. Satisfactorio

4. Excelente

Por qu?

Cubre sus necesidades de procesamiento?

1. No las cubre

2. Parcialmente

3. La mayor parte

4. Todas

Por qu?

Cmo considera la calidad del procesamiento que se le proporciona?

1. Deficiente

2. Aceptable

3. Satisfactorio

4. Excelente

Por qu?

Hay disponibilidad de procesamiento para sus requerimientos?

1. Generalmente no existe

2. Hay ocasionalmente

3. Regularmente

4. Siempre

Por qu?

Conoce los costos de los servicios proporcionados?

Que opina del costo del servicio proporcionado por el departamento de

procesos electrnicos?

1. Excesivo

2. Mnimo

3. Regular

4. Adecuado al servicio

5. No lo conoce

Por qu?

Son entregados con puntualidad los trabajos?

1. Nunca

2. Rara vez

3. Ocasionalmente

4. Generalmente

5. Siempre

Por qu?

Qu Piensa de la presentacin de los trabajos solicitados?

1. Deficiente

2. Aceptable

3. Satisfactoria

4. Excelente

Por qu?

Qu piensa de la atencin brindada por el personal de procesos

electrnicos?

1. Insatisfactoria

2. Satisfactoria

3. Excelente

Por qu?

Qu piensa de la asesora que se imparte sobre informtica?

1. No se proporciona

2. Es insuficiente

3. Satisfactoria

4. Excelente

Por qu?

Qu piensa de la seguridad en el manejo de la informacin proporcionada

para su procesamiento?

1. Nula

2. Riesgosa

3. Satisfactoria

4. Excelente

5. Lo desconoce

Por qu?

Existen fallas de exactitud en los procesos de informacin?

Cules?

Cmo utiliza los reportes que se le proporcionan?

Cules no utiliza?

De aquellos que no utiliza por qu razn los recibe?

Qu sugerencias presenta en cuanto a la eliminacin de reportes:

modificacin, fusin, divisin de reporte?

Se cuenta con un manual del usuario por sistema?

Si ( )

NO( )

Es claro y objetivo el manual del usuario?

SI ( )

NO( )

Qu opinin tiene sobre el manual?

NOTA: Pida el manual del usuario para evaluarlo

Quin interviene de su departamento en el diseo de sistemas?

En qu sistemas tiene actualmente su servicio de computacin?

Qu sistemas deseara que se incluyeran?

Observaciones: