AUDITORIA INFORMATICA DE DESARROLLO DE PROYECTOS

El rea de Desarrollo de Proyectos o de Aplicaciones es objeto frecuente de la Auditoria informtica. Indicando inmediatamente que la funcin de Desarrollo es una evolucin del llamado Anlisis y Programacin de Sistemas y Aplicaciones, trmino presente en los ltimos aos. La funcin Desarrollo engloba a su vez muchas reas, tantas como sectores informatizables tiene la empresa. Muy escuetamente, una Aplicacin recorre las siguientes fases: a) Prerrequisitos del Usuario (nico o plural), y del entorno. b) Anlisis funcional. c) Anlisis orgnico. (Pre programacin y Programacin). d) Pruebas. e) Entrega a Explotacin y alta para el Proceso Se deduce fcilmente la importancia de la metodologa utilizada en el desarrollo de los Proyectos informticos. Esta metodologa debe ser semejante al menos en los Proyectos correspondientes a cada rea de negocio de la empresa, aunque preferiblemente debera extenderse a la empresa en su conjunto. En caso contrario, adems del aumento significativo de los costos, podr producirse fcilmente la insatisfaccin del usuario, si ste no ha participado o no ha sido consultado peridicamente en las diversas fases del mismo, y no solamente en la fase de prerrequisitos. Finalmente, la Auditoria informtica deber comprobar la seguridad de los programas, en el sentido de garantizar que los ejecutados por la mquina son totalmente los previstos y no otros. Una razonable Auditoria informtica de Aplicaciones pasa indefectiblemente por la observacin y el anlisis de estas consideraciones. a) Revisin de las metodologas utilizadas Se analizarn stas, de modo que se asegure la modularidad de las posibles futuras ampliaciones de la Aplicacin y el fcil mantenimiento de las mismas. b) Control Interno de las Aplicaciones

La Auditoria informtica de Desarrollo de Aplicaciones deber revisar lasmismas fases que presuntamente ha debido seguir el rea correspondiente deDesarrollo. Las principales son: 1. Estudio de Viabilidad de la Aplicacin .2.Definicin Lgica de la Aplicacin .3.Desarrollo Tcnico de la Aplicacin .4.Diseo de Programas .5.Mtodos de Pruebas .6.Documentacin .7.Equipo de Programacin c) Satisfaccin de Usuarios Una Aplicacin eficiente y bien desarrollada tericamente, deber considerarse un fracaso si no sirve a los intereses del usuario que la solicit. Surgen nuevamente las premisas fundamentales de la informtica eficaz: fines y utilidad. No puede desarrollarse de espaldas al usuario, sino contando con sus puntos de vista durante todas las etapas del Proyecto. La presencia del usuario proporcionar adems grandes ventajas posteriores, evitar reprogramaciones y disminuir el mantenimiento de la Aplicacin. d) Control de Procesos y Ejecuciones de Programas Crticos El auditor no debe descartar la posibilidad de que se est ejecutando un mdulo lo que no se corresponde con el programa fuente que desarroll, codific y prob el rea de Desarrollo de Aplicaciones. Se est diciendo que el auditor habr de comprobar fehaciente y personalmente la correspondencia biunvoca y exclusiva entre el programa codificado y el producto obtenido como resultado de su compilacin y su conversin en ejecutables mediante la linkeditacin (Linkage Editor). Obsrvense las consecuencias de todo tipo que podran derivarse del hecho de que los programas fuente y los programas mdulos no coincidieran provocando graves retrasos y altos costos de mantenimiento, hasta fraudes, pasando por acciones de sabotaje, espionaje industrial-informtico, etc.

Esta problemtica ha llevado a establecer una normativa muy rgida en todo lo referente al acceso a las Libreras de programas. Una Informtica medianamente desarrollada y eficiente dispone de un solo juego de Libreras de Programas de la Instalacin. En efecto, Explotacin debe recepcionar programas fuente, y solamente fuente. Cules? Aquellos que Desarrollo haya dado como buenos. La asumir la responsabilidad de: 1. Copiar el programa fuente que Desarrollo de Aplicaciones ha dado por bueno en la Librera de Fuentes de Explotacin, a la que nadie ms tiene acceso. 2. Compilar y link editar ese programa, depositndolo en la Librera de Mdulos de Explotacin, a la que nadie ms tiene acceso. 3. Copiar los programas fuente que les sean solicitados para modificar los, arreglarlos, etc., en el lugar que se le indique. Cualquier cambio exigir pasar nuevamente al punto 1. Ciertamente, hay que considerar las cotas de honestidad exigible a Explotacin. Adems de su presuncin, la informtica se ha dotado de herramientas de seguridad sofisticadas que permiten identificar la personalidad del que accede a las Libreras. No obstante, adems, el equipo auditor intervendr los programas crticos, compilando y link editando nuevamente los mismos para verificar su biunivocidad.

12.2.IMPORTANCIA DE LA AUDITORIA DEL DESARROLLO Aunque cualquier departamento o rea de una organizacin es susceptible de ser auditado, hay una serie de circunstancias que hacen especialmente importante al rea de desarrollo y, por tanto, tambin su auditoria, frente a otras funciones o reas dentro del departamento de informtica: Los avances en tecnologas de los computadores han hecho que actualmente el desafo mas importante y el principal factor de xito de la informtica sea la mejora de calidad del software. El gasto destinado a software es cada vez superior al que se dedica a hardware. A pesar de la juventud de la ciencia informtica, hace aos que se produjo la denominada crisis del software. Incluye problemas asociados con el desarrollo y mantenimiento del software y afecta a un gran nmero de organizaciones. En el rea del hardware no se ha dado una crisis equivalente. El software como producto en muy difcil de validar. Un mayor control en el proceso de desarrollo incrementa la calidad del mismo y disminuye los costos de mantenimiento. El ndice de fracasos en proyectos de desarrollo es demasiado alto, lo cual denota la inexistencia o mal funcionamiento de los controles en este proceso. Los datos del government accounting office report(EE.UU.) sobre diversos proyectos de software (valorados en 6,8 millones de dlares) son ilustrativos. Un 1.5% se uso tal y como se entrego. Un 3.0% se uso despus de algunos cambios. Un 19.5% se uso y luego se abandono o se rehzo. Un 47 % se entrego pero nunca se uso. Un 29% se pago pero nunca se entrego. Las aplicaciones informticas, que son el producto principal obtenido al final del desarrollo, pasan a ser la herramienta de trabajo principal de las reas informatizadas, convirtindose en un factor esencial para la gestin y la toma de decisiones.

12.3. PLANTEMIENTO Y METODOLOGIA Para tratar la auditoria del rea de desarrolloes necesario, en primer lugar, acotar las funciones o tareas que son responsabilidad del rea. Teniendo en cuenta que puede haber variaciones de una organizacin a otra, las funciones que tradicionalmente se asignan al rea de desarrollo son:

Planificacin del rea y participacin, en la medida que responda, en la elaboracin del plan estratgico de informtica. Desarrollo de nuevos sistemas. Esta es la funcin principal y la que da sentido al rea de desarrollo. Incluir para cada uno de los sistemas, el anlisis, diseo, construccin e implantacin, el mantenimiento se supondr funcin de otra rea. Estudio de nuevos lenguajes, tcnicas, metodolgicas, estndares, herramientas, etc. Relacionados con el desarrollo y adopcin de los mismos cuando se considere oportuno para mantener un nivel de vigencia adecuado a la tecnologa del momento. Establecimiento de un plan de formacin para el personal adscrito al rea. Establecimiento de normas y controles para todas las actividades que se realizan en el rea y comprobacin de su observancia.

Una vez conocidas las tareas que se realizan en el rea de desarrollo, se abordara la auditoria de la misma desglosndola en dos grandes apartados, que mas tarde se subdividirn con mas detalles: Auditoria de la organizacin y gestin del rea de desarrollo. Auditoria de proyectos de desarrollo de sistemas de informtica.

De estos dos apartados se hara mas nfasis en el segundo por tratarse de la funcin principal del rea, aunque ha de tenerse en cuenta que una buena organizacin y gestin es imprescindible para que los proyectos tengan una calidad aceptable. La metodologa que se aplicara es la propuesta por la ISACA (information Systems Audit and Control Association). Que basada en la evaluacin de riesgos: partindo de los riesgos potenciales a los que esta sometida una actividad, en este caso el desarrollo de un sistema de informacin, se determinan una serie de objetivos de control que minimicen esos riesgos. Para cada objetivo de control se especifican una o mas tcnicas de control, tambin denominadas simplemente controles, que contribuyan a lograr el cumplimiento de dicho objetivo. Adems, se aportan una serie de pruebas de cumplimiento que permitan la comprobacin de la existencia y correcta aplicacin de dichos controles. El esquema para cada objetivo de control es: OBJETIVO DE CONTROL X: C-X-I: Tecnica de control I del objetivo de control x Pruebas de cumplimiento de C-X-I

C-X-m: Tcnica de control m del objetivo de control x Pruebas de cumplimiento de C-X-m

Una vez fijados los objetivos de control, ser funcin del auditor determinar el grado de cumplimiento de cada uno de ellos. para cada objetivo se estudiaran todos los controles asociados al mismo, usando para ello las pruebas de cumplimiento propuestas. Con cada prueba de cumplimiento se obtendr alguna evidencia, bien sea directa o indirecta, sobre la correccin de los controles, si una simple comprobacin no ofrece ninguna evidencia, ser necesaria, la realizacin de exmenes mas profundos. En los controles en los que sea impracticable una revisin exhaustiva de los elementos de verificacin, bien porque los recursos de auditoria sean limitados o porque el numero de elementos a inspeccionar sea muy elevado, se examinara una muestra representativa que permita inferir el estado de todo el conjunto. El estudio global de todas las conclusiones, pruebas y evidencias obtenidas sobre cada control permitirn al auditor obtener el nivel de satisfaccin de cada objetivo de control. Asi como cuales son los puntos fuertes y dbiles del mismo. Con esta informacin, y teniendo en cuenta las particularidades de la organizacin en estudio, se determinara cuales son los riesgos no cubiertos, en que medida lo son y que consecuencias se pueden derivar de esa situacin. Estas conclusiones, junto con las recomendaciones formuladas, sern las que se plasmen en el informe de auditoria. En los apartados siguientes se agrupan los distintos objetivos de control en varias series, detallndose para cada uno de ellos sus controles asociados y pruebas de cumplimiento, el esquema seguido en el siguiente: Organizacin y gestin del rea de desarrollo( serie a, aptdo.4) Proyectos de desarrollo de sistemas de informacin Aprobacion, planificacin y gestin del proyecto( serie B, aptdo. 5.1) Analisis Analisis de requisitos( Serie C, aptdo. 5.2.2) Diseo Diseo tcnico ( serie E, aptdo. 5.3.1) Construccion Desarrollo de componentes ( serie F, aptdo. 5.4.1) Desarrollo de procedimientos de usuario ( serie G, aptdo. 5.4.2) Implantacion Pruebas, implantacin y aceptacin ( serie H, aptdo. 5.5.1)

12.4. AUDITORIA DE LA ORGANIZACAION Y GESTION DEL AREA DE DESARROLLO Aunque cada proyecto de desarrollo tenga entidad propia y se gestione con cierta autonoma, para poderse llevar a efecto necesita apoyarse en el personal del rea y en los procedimientos establecidos, la importancia de estos aspectos ha motivado que se dedique un apartado exclusivo a la organizacin y gestin del rea de desarrollo. Se consideran ocho objetivos de control (serie A): OBJETIVO DE CONTROL A1: El rea de desarrollo debe tener unos cometidos asignados dentro del apartamento y una organizacin que le permita el cumplimiento de los mismos. C-AI-1: Deben establecerse de forma clara las funciones del rea de desarrollo dentro del departamento de informtica. Se debe comprobar que: Existe el documento que contiene las funciones que son competencia del rea de desarrollo, que est aprobado por la direccin de informtica y que se respeta.

C-AI-2: Debe especificarse el organigrama con la relacin de puestos del rea, asi como el personal adscrito y el puesto que ocupa cada persona. Debe existir un procedimiento para la promocin de personal. Se debe comprobar que: Existe un organigrama con la escritura de organizacin del rea. Para cada puesto debe describir las funciones a desempear, los requisitos minimos de formacin y experiencia, y de la dependencia jerarquica del mismo. Existe un manual de organizacin que regula las relaciones entre puestos. Existe la relacin de personal adscrito al rea, incluyendo el puesto ocupado por cada persona. Se deben cumplir los requisitos de los puestos. Estn establecidos los procedimientos de promocin de personal a puestos superiores, teniendo siempre en cuenta la experiencia y formacin.

C-AI-3: El rea debe tener y difundir su propio plan a corto, medio y largo plazo, que ser coherente con el plan de sistemas, si este existe. Se debe comprobar que: El plan existe, es claro y realista. Los recursos actuales, ms los que este planificado que se incorporen al rea, son suficientes para su cumplimiento. Se revisa y actualiza con periodicidad en funcin de las nuevas situaciones. Se difunde a todos los empleados para que se sientan partcipes del mismo, al resto del apartamento y a los departamentos a los que les atae.

C-AI-4: El rea de desarrollo llevara su propio control presupuestario. Se debe comprobar que: Se hace un presupuesto por ejercicio, y se cumple. El presupuesto est en consonancia con los objetivos a cumplir.

OBJETIVO DE CONTROL, A2: El personal del rea de desarrollo debe contar con la formacin adecuada y estar motivado para la realizacin de su trabajo. C-A2-1: Deben existir procedimientos de contratacin objetivos. Se debe comprobar que: Las ofertas de puestos del rea se difunden de forma suficiente fuera de la organizacin y las selecciones se hacen de forma objetiva. Las personas seleccionadas cumplen los requisitos del puesto al que acceden.

C-A2-2: debe existir un plan de formacin que este en consonancia con los objetivos tecnolgicos que se tengan en el rea. Se debe comprobar que: Se tiene aprobado un plan de formacin a corto, medio y largo plazo que sea coherente con la poltica tecnolgica. Incluye toda la informacin relevante para cada actividad formativa: fechas, horarios, lugar, ponentes, asistentes, material, medios necesarios, etc. Las actividades formativas se evalan por parte de los asistentes y esta evaluacin se tiene en cuenta a la hora de redefinir el plan de formacin.

Contempla la formacin de todos los empleados y tiene en cuenta el puesto que ocupan. El plan de trabajo del rea tiene en cuenta los tiempos de formacin. C-A2-3: Debe existir un protocolo de recepcin/abandono para las personas que se incorporan o dejan el rea. Se debe comprobar que: El protocolo existe y se respeta para cada incorporacin/abandono. Para la incorporacin, incluye al menos los estndares definidos, manual de organizacin del rea, definicon de puestos. Etc. En los abandonos de personal se garantiza la proteccin del rea.

C-A2-4: Debe existir una biblioteca y una hemeroteca accesibles por el personal del rea. Se debe comprobar que: Estn disponibles un numero suficiente de libros, publicaciones peridicas, monogramas, etc, de reconocido prestigio y el personal tiene acceso a ellos.

C-A2-5: El personal debe estar motivado en la realizacin de su trabajo. Este aspecto es difcil de valorar y no es puramente tcnico. Se debe comprobar que: Existe algn mecanismo que permita a los empleados hacer sugerencias sobre mejoras en la organizacin del rea. No existe una gran rotacin y hay un buen ambiente de trabajo. El rendimiento laboral es similar al del resto de la organizacin.

OBJETIVO DE CONTROL A3: Si existe un plan de sistemas, los proyectos que se lleven a cabo se basaran en dicho plan y lo mantendr actualizado. C-A3-1: La realizacin de nuevos proyectos debe basarse en el plan de sistemas en cuanto a objetivos, marco general y horizonte temporal. Se debe comprobar que: Las fechas de realizacin coinciden con las del plan de sistemas. La documentacin relativa a cada proyecto que hay en el plan de sistemas se pone a disposicin del director de proyecto una vez comenzado el mismo. Esta informacin debe contener los objetivos, los requisitos generales y un plan inicial.

C-A3-2: El plan de sistemas debe actualizarse con la informacin que se genera a lo largo de un proceso de desarrollo. Se debe comprobar que: Los cambios en los planes de los proyectos se comunican al responsable de mantenimiento del plan de sistemas por las implicaciones que pudiera tener.

OBJETIVO DE CONTROL A4: La propuesta y aprobacin de nuevos proyectos debe realizarse de forma reglada. C-A4-1: Debe existir un procedimiento para la propuesta de realizacin de nuevos proyectos. Se debe comprobar que: Existe un mecanismo para registrar necesidades de desarrollo de nuevos sistemas y en todo caso se aportan los siguientes datos: descripcin, necesidad, departamento patrocinador, riesgos, marco temporal costo de la no realizacin, ventajas que aporta, adaptacin a los planes de negocio. Etc. Se respeta este mecanismo en todas las propuestas.

C-A4-2: Debe existir un procedimiento de aprobacin de nuevos proyectos que depender de que exista o no plan de sistemas. Si hay un plan de sistemas se debe comprobar que: Se parte de las pautas, prioridades y planificacin que este marque para el desarrollo de cada nuevo sistema.