Auditoria de Sistemas
Auditoria del proceso de construcción de sistemas
El auditor ha de analizar y asegurarse de la existencia, adecuación y cumplimiento de las funciones de planificación, control y administración de recursos y actividades.
Estas funciones son responsabilidad del jefe de proyecto. Ha de tenerse en cuenta que esas funciones consumen tiempo, por lo que deberán estar previstas en el cálculo de cargas de trabajo.
Una persona puede dirigir, controlar y supervisar el trabajo de cinco a ocho colaboradores, y esta ocupación normalmente consumirá todo su tiempo útil. La dirección de un proyecto puede estar encomendada a usuarios, técnicos en organización y técnicos en computación.
En rigor, en cuanto a su función propia, el jefe de proyecto precisa solamente conocimientos de técnicas de planificación, técnicas de administración y dirección de recursos, así como técnicas de control de avance de proyectos.
Evidentemente, la primera parte (técnicas de planificación), exige conocer la estructura básica o modelo de realización del proyecto; fases, actividades, técnicas, perfiles de los profesionales que intervienen, etc.
Las demás técnicas son comunes a la dirección de cualquier tipo de proyecto (marketing, ingeniería, etc. )
Principios fundamentales de la gestión de proyectos
En la gestión de proyectos hay que tener en cuenta los siguientes principios fundamentales:
1.- El proyecto ha de descomponerse, por medio de un proceso analítico, en partes cada vez más elementales, hasta llegar a tener unidades controlables y medibles; se debe saber cuándo empiezan, cuando terminan, y en que grado de realización (porcentaje) se está en un instante dado.
2.- Las unidades han de estructurarse en el tiempo teniendo en cuenta precedencias y prioridades.
3.- Se estiman coste, plazos y esfuerzos para cada unidad de trabajo y para el conjunto de ellos. Han de tenerse en cuenta las esperas motivadas por precedencias, y el consumo de tiempo y esfuerzos que implican las entrevistas, reuniones, trabajo de coordinación, etc.
4.- Asignación de unidades de trabajo a recursos concretos. Como consecuencia de este punto puede ser preciso reestructurar las actividades.
5.- Definición de calendarios, con fechas estimadas para los sucesos más importantes. Normalmente se suelen establecer varios ( optimista, más probable y pesimista ), en función de las estimaciones realizadas.
6.- Definición, implantación y uso de mecanismos de control, medida y corrección de desviaciones. Para este punto deben sentarse normas y procedimientos de informe de avances, control y evaluación de cambios, evaluaciones de la realidad frente a lo planificado, ajustes y correcciones, e implantación y seguimiento de normas y estándares, sobre todo tendentes a garantizar la calidad del producto: documentación, modo y técnicas de trabajo, repaso y verificación de las pruebas y validaciones, características del producto (modularidad, flexibilidad, reutilidad, etc.).
La planificación en la construcción de sistemas
El plan estratégico o computacional identifica y define las líneas maestras de todos y cada uno de los proyectos a realizar, así como los contactos y relaciones entre ellos.
Cada proyecto, por separado, ha de tener un plan a nivel táctico y operacional (medio y corto plazo), y debe ser posible, estar formalizado, y ser correcto.
Normalmente la descomposición de un proyecto, suele ser en tres o cuatro niveles, que son: proyecto, fase, actividad, tarea o paso.
No hay un acuerdo sobre las fases típicas de un proyecto computarizado, cada metodología tiene las suyas, aunque sí hay ciertas similitudes entre ellas.
Fases en el proceso de construcción de sistemas
Como norma general, cualquier metodología ha de prever y sistematizar (o dar como realizada por órganos aparte) las tareas siguientes:
1.- Estudio de mercado: para el producto que ha de soportarse por medio del sistema computarizado.
2.- Estudio de viabilidad o rentabilidad: determinar que es posible y rentable utilizar la función computacional como soporte del producto en cuestión, y en que grado y forma.
3.- Estudio inicial: estudio breve de los elementos dimensionales del sistema computarizado a implantar; volúmenes, tendencias, funciones, requisitos, cuyo objetivo es proporcionar una definición global de la arquitectura del sistema; presentación de posibles alternativas de solución para que los órganos apropiados elijan la más conveniente; estructuración global.
4.- Estudio detallado: una vez definido el modelo elegido, definición de todas y cada una de las funciones a soportar por el sistema; definición de las cadenas en que se resolverá el sistema. Estimación mucho más firme. Escritura de los cuadernos de especificaciones de los programas a realizar. Planes de detalle para la transición del sistema antiguo al nuevo.
5.- Realización: programación, prueba e integración de programas, cadenas y aplicaciones.
6.- Implantación: inicialización de ficheros, formación y entrenamiento de usuarios; transición paulatina, tal vez con fase en paralelo; medida y evaluación de resultados esperados contra los previstos; corrección de fallos y defectos.
7.- Explotación: utilización rutinaria del sistema durante un periodo más o menos largo de tiempo. En esta etapa hay actividades de mantenimiento (preventivo, correctivo y modificativo) así como de seguimiento y medida de resultados.
8.- Baja del sistema: al cabo de cierto tiempo se sustituye el producto por otro debido a su obsolescencia técnica; incapacidad de soporte técnico; incapacidad de soportar los requisitos y necesidades de exactitud, tiempo de respuesta, volumen de uso, cantidad de usuarios; o a repetidos fallos o defectos que lo hacen poco fiable.
El conjunto de las ocho etapas citadas se conoce como “ciclo de vida del software”. El auditor computacional ha de revisar la calidad o adecuación del producto, o bien la calidad o adecuación del método de diseño, desarrollo, implantación y control.
Puntos clave de la buena planificación de un proyecto
Para tener una buena planificación hay que tener muy presentes los diez puntos siguientes:
1.- La planificación y estructuración ha de realizarse previendo esperas, aprobaciones, reuniones, validaciones, etc.
2.- Los representantes de los usuarios han de considerarse como miembros participantes del proyecto, con tareas y responsabilidades asignadas, así como con planificación de los momentos en que han de participar y con qué esfuerzo. Este uso de recursos de usuarios debe ser, lógicamente, conocido y aprobado por los jefes de los mismos.
3.- A lo largo del proyecto aparecen instantes en que se pueden tomar dos o más caminos diferentes:
a) ¿centralizar o descentralizar?
b) ¿dispositivos de una clase o de otra?
c) ¿desarrollo propio o contratación de un paquete?
d) ¿modificación de estructura del servicio usuario?
Algunos de estos caminos pueden ser decididos por el equipo de proyecto: otros estarán fijados por las políticas de la empresa, pero otros exigirán la decisión de in nivel superior, de igual forma que si surge una diferencia grave de estimación o apreciación entre miembros del proyecto.
El órgano con capacidad de resolver o de obtener la resolución de esas alternativas debe estar especificado claramente en la definición del proyecto.
4.- Como resultado de los trabajos, aparecerán visiones de síntesis de situaciones reales, apreciaciones, etc., que podrán ser más o menos acertadas, teniendo en cuenta que el estudio de departamentos usuarios, o el conocimiento de técnicas complejas, como diseño de sistemas online, no es todo lo profundo que debiera por parte de los miembros del proyecto como para poder asumir con certeza la totalidad de las visiones. En esos casos harán falta valuadores y asesores. El jefe de una sección dirá si la visión global de la misma, si las deficiencias a solucionar o las necesidades detectadas son acertadas o no.
5.- La estimación de costos, plazos y esfuerzos ha de realizarse a partir de estándares de la instalación; los de otras instalaciones no suelen servir. Como factores a tener en cuenta para estimar un proyecto, los más importantes son:
a) Complejidad
b) Cantidad y complejidad de informes y destinatarios de los mismos.
c) Cantidad y complejidad de transacciones de entrada.
d) Controles y validaciones a realizar.
e) Cantidad y complejidad de archivos y bases de datos.
f) Necesidades de flexibilidad y crecimiento.
6.- Ha de verificarse la adecuación de personas a las actividades encomendadas.
7.- Ha de verificarse la existencia de mecanismos de comunicación entre los distintos proyectos y entre las partes de cada uno de ellos.
8.- Existencia de un mecanismo de control de cambios.
9.- Existencia de reuniones de repaso y coordinación.
10.- Mecanismo de control de proyectos.
Auditoria de la calidad de un producto computarizado
El auditor computacional debe realizar revisiones sobre la calidad de las aplicaciones desde fases muy tempranas del ciclo de vida software. Ha de considerarse que el coste de una aplicación puede ser bastante elevado, por lo que si se obtiene como producto algo inútil, se ha realizado un gasto que es muchas veces mayor, que el coste de un posible fraude o error, para los cuales se prevén mecanismos adecuados de control.
Principios clave
El coste de resolución de un error u omisión, cometido en un punto dado de la vida de un producto software, aumenta exponencialmente con el tiempo transcurrido ( o el esfuerzo realizado), hasta que se detecta y se adoptan las medidas correctoras precisas. Esto supone que un diagnóstico temprano puede ahorrar cantidades importantes de esfuerzo, tiempo y dinero.
Las funciones de auditoria o de control interno intervenir desde las fases iniciales del proyecto, en aspectos determinados o propios, fijados por hitos (principio o final de una fase, etc.), periódicamente (quincenal o mensualmente) o en aspectos elegidos al azar (muestreos). Evidentemente, el auditor no puede revisar y asegurar la bondad del producto en su totalidad, ya que ello le exigiría un esfuerzo de magnitud similar al de todo proyecto, por lo que ha de concentrarse en puntos clave (seguridad, calidad de diseño, control) y verificar que los trabajos se realizan con métodos apropiados que aseguren una elevada probabilidad de éxito.
Definición de calidad
Como síntesis de varias definiciones, se pueden citar como características deseables del software: la utilidad, la fiabilidad, la exactitud, la seguridad, la modularidad, la flexibilidad, la comodidad, el mantenimiento, la dimensión adecuada, la documentación adecuada, la aceptación por los usuarios, la existencia de mecanismos de medida de nivel de servicio de los usuarios, la existencia de mecanismos de control interno que proporcionen seguridad, privacidad, controles de fechas, arqueos, cuadres, etc.
Plan de garantía de calidad del software
Es un plan de aplicación a uno o a todos los productos software, de un modelo planificado y sistemático de acciones necesarias para obtener un grado adecuado de confianza de que el producto en cuestión cumple con los requisitos, entre ellos el de calidad.
El contenido del diseño preliminar del modelo propuesto por la IEEE (Asociación de Ingenieros Eléctricos y Electrónicos de USA) consiste en:
1.- Propósito: justificación de por qué se decide implantar el plan de garantía de calidad del software.
2.- Documentos a que se hace referencia: normalizados, lista de ellos.
3.- Gestión del plan: organización del plan, tareas, responsabilidades.
4.- Documentación: propósito, documentación (especificación de requisitos, descripción del diseño, plan de verificación y validación, informe de verificación y validación, documentación para los usuarios).
5.- Otra documentación: plan de desarrollo del software, plan de gestión de configuración del software, normas y procedimientos.
6.-Documentación adicional: definición de requisitos del usuario, especificaciones de relaciones externas (ficheros, bases de datos, software).
7.- Especificaciones de relaciones internas.
8.- Manual de entrenamiento.
9.- Manual de operación.
10.- Manual de instalación.
11.- Manual de mantenimiento.
12.- Plan de entrenamiento.
13.- Normas, prácticas y convenios: propósito, contenido (requisitos, diseño, implantación, prueba, documentación).
14.- Revisiones y auditorias: propósito, requisitos mínimos a revisar (requisitos del software, diseño preliminar, diseño crítico, plan de verificación y validación, auditoria funcional, auditoria física).
15.-Gestión de la configuración software.
16.- Gestión de problemas.
17.-Herramientas, técnicas y metodología.
18.- Control del software.
19.- Control físico: acceso no autorizado, daño, inadecuación o degradación.
20.- Control de proveedores de software.
21.- Registro, mantenimiento y retención de la documentación de garantía de calidad.
Para su implantación, lógicamente deben seguirse las fases siguientes:
a) Propuesta a la dirección.
b) Aceptación por la dirección.
c) Presentación al personal de desarrollo.
d) Aceptación del personal de desarrollo.
e) Planificación de la implantación: identificación de recursos precisos, planificación en el tiempo, evaluación de riesgos.
f) Formación del personal.
g) Distribución del plan.
h) Ejecución del plan.
Medidas de control interno del software
Debido a que el software de aplicación constituye la plasmación para un sistema computarizado de un procedimiento anteriormente realizado en forma manual, ha de dotársele de las medidas de control precisas: prevención, detección y corrección de errores, fallos y fraudes o sabotajes.
En principio las medidas citadas han de definirse funcionalmente, como si se fueran a implantar en sistemas administrativos comunes. Ejemplos de ellos serían los códigos auto verificados, el uso de sumarios de importes y fechas, doble pulsación de datos muy importantes, verificaciones de formato y verosimilitud, control de acceso a la información, custodia de documentos negociables, etc.
Esas medidas funcionales, complementadas con otras que son específicamente precisas por las peculiaridades del proceso computarizado (respaldos, etc.) se traducirán en especificaciones que ha de cumplir el software.
A continuación se especifican familias de controles a implantar en el software:
1.- Controles en entrada
2.- Controles en procesos
3.- Controles en salida
4.-Controles de recuperación y arranque.
