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:
Top Related