PARTICIPACION DEL AUDITOR (COMO EVALUADOR Y COMO USUARIO) EN LAS DIFERENTES ETAPAS DE UN PROYECTO DE INGENIERIA DE SOFTWARE

EDWIN ROJAS PARRA

FASES DE ANALISIS Y DISEO EN UN PROYECTO DE INGENERA DE SOFTWARE

ING. DORA JANETH ALFONSO

UNIVERSIDAD ANTONIO NARIO ESPECIALIZACION EN AUDITORIA DE SISTEMAS SANTAFE DE BOGOTA D.C. 2012

Tabla de contenido
1. DEFINICION. .....................................................................................................................................4 2. AUDITORIA DE PROYECTOS DE DESARROLLO DE INGENERIA DE SOFTWARE. ................................5 2.1. AUDITORIA DE LA FASE DE ANALISIS ........................................................................................6 2.1.1 Anlisis de requisitos del sistema (ARS). .............................................................................6 2. 1.2. Especificaciones Funcionales del Sistema (EFS). ...............................................................7 2.1.3. Aspectos de consideracin de la fase de anlisis: .............................................................9 2.1.3.1 Estudio de Factibilidad / Viabilidad..............................................................................9 2.1.3.2. Definicin de Requerimientos. ................................................................................ 10 2.1.3.3. Adquisicin de Software (compra o desarrolla). ..................................................... 10 2.1.3.4. Documentacin de la fase........................................................................................ 11 2.1.3.5. Identificar, evaluar y controlar riesgos. ................................................................... 12 2.2. AUDITORIA DE LA FASE DE DISEO. ...................................................................................... 13 2.2.1. Definir el entorno tecnolgico. ....................................................................................... 13 2.2.2. Efectuar el diseo tcnico con la participacin del usuario. .......................................... 14 2.2.3. Documentacin de la fase............................................................................................... 15 2.2.4. Identificar, evaluar y controlar riesgos. .......................................................................... 15 CONCLUSION..................................................................................................................................... 17 BIBLIOGRAFIA.................................................................................................................................... 18

INTRODUCCION Este trabajo busca proveer una gua bsica a los auditores de sistemas en la administracin de las diferentes etapas del ciclo de vida del desarrollo de proyectos de ingeniera, tanto el equipo desarrollador como el equipo auditor necesita conocer los conceptos generales de los procesos y metodologas usadas en la gestin de desarrollo de nuevos proyectos de ingeniera, el plan de actividades del equipo desarrollador es diferente al del auditor, quien tiene la funcin de comprobar la existencia de los procedimientos de control y de verificar su correcta aplicacin en cada etapa del ciclo de vida del desarrollo del nuevo proyecto de ingeniera de software, lo cual permite el xito del proyecto.

1. DEFINICION.

Se entiende por ingeniera de software el establecimiento y uso de principios de ingeniera robustos. Orientados a obtener software econmico que sea fiable. Cumpla los requisitos previamente establecidos y funcionen de manera eficiente sobre maquinas reales (Fritz Bauer) La auditoria de desarrollo tratara de verificar la existencia y la aplicacin de procedimientos de control adecuado que permitan garantizar que el desarrollo de sistemas de informacin se ha llevado a cabo segn estos principios de ingeniera, o por el contrario, determinar las deficiencias existentes en este sentido. El software como producto es muy difcil de validar. Un mayor control en el

proceso de desarrollo incrementa la calidad del mismo y disminuye los costes de mantenimiento. Una vez fijado 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 ellos las pruebas de cumplimiento propuestas. Con cada prueba de cumplimiento se obtendr alguna evidencia, bien ser directa o indirecta, sobre la correccin de los controles. Si una simple comprobacin no ofrece ninguna evidencia, ser necesaria la realizacin de exmenes ms profundos.

2. AUDITORIA DE PROYECTOS DE DESARROLLO DE INGENERIA DE SOFTWARE.

Cada proyecto tendr unos objetivos marcados y afectara a determinadas unidades de la organizacin. Debe tener un responsable y ser guiados con tcnicas que permitan conseguir los objetivos marcados, teniendo en cuenta los recursos disponibles y las restricciones temporales del mismo. La auditoria de cada proyecto de desarrollo tendr un plan distinto dependiendo de los riesgos, la complejidad del mismo y los recursos disponible para realizar la auditoria. Esto obliga a que sea la pericia y experiencia del auditor las que

determinen las actividades del proyecto que se controlaran con mayor intensidad en funcin de los parmetros anteriores. Dentro del desarrollo de un sistema de informacin se han propuesto 5

subdivisiones, entre las cuales se encuentran: anlisis, diseo, construccin e implementacin. Estas fases son debidamente aceptadas en ingeniera de software para el desarrollo, son en concreto las que propone la metodologa de desarrollo de sistemas de informacin Mtrica versin 2.1. La aprobacin del proyecto es un hecho previo al comienzo del mismo, mientras que la gestin se aplica a lo largo de su desarrollo. La planificacin se realiza antes de iniciarse, pero sufrir cambios a medidas que el proyecto avance en el tiempo. La auditoria de un proyecto de desarrollo se debe hacer en dos momentos distintos: a medida que avanza el proyecto o una vez concluido el mismo. Las tcnicas a utilizar y los elementos a inspeccionar, normalmente los productos y documentos generados en la fase de desarrollo, sern los mismos en ambos casos. La nica diferencia es que en el primer caso las conclusiones que vaya aportando el auditor puede afectar el desarrollo del proyecto, aunque nunca participara en la toma de decisiones del mismo.

El auditor en esta fase inicial de aprobacin, planificacin y gestin del proyecto debe implementar varios controles, que permitan verificar; la existencia de la orden de aprobacin del proyecto, la cual debe definir claramente los objetivos, restricciones y las unidades afectadas. Debe estar firmada por un rgano o rea competente; la designacin del director del proyecto cumple o se llevo a cabo segn el procedimiento establecido; se han evaluados los riesgos asociados al proyecto, la seleccin el modelo del ciclo de vida es el mas adecuado al tipo de proyecto que se va desarrollar; el equipo de trabajo desarrollador y los participantes de las dems reas y externo cumplen con los perfiles profesionales adecuados; la comunicacin de la informacin del proyecto a todas las partes afectada e interesadas y la existencia de controles o procedimientos de cambios a lo largo del proyecto. 2.1. AUDITORIA DE LA FASE DE ANALISIS

La fase de anlisis pretende obtener un conjunto de especificaciones formales que describan la necesidad de informacin que pueden ser cubiertas por el nuevo sistema de una forma independiente del entorno tcnico. Se divide en dos mdulos. 2.1.1 Anlisis de requisitos del sistema (ARS).

En este modulo se identifican los requisitos del nuevo sistema. Se incluirn tantos los requisitos funcionales como los no funcionales, distinguiendo para cada uno de ellos su importancia y prioridad. A partir del conocimiento del sistemas actual y sus problemas asociados, juntos con los requisitos que se exigirn al nuevo sistema, se determinaran las posibles soluciones, alternativas que satisfagan estos requisitos y de entre ellas se elegirn las ms adecuadas.

En esta etapa el auditor debe implementar varios controles para verificar: La participacin activa de los usuarios y que sean representativos de las distintas funciones que se llevan a cabo en las unidades afectadas por el nuevo sistemas. Existe un plan de entrevista detallado con fecha, hora y lugar, tipo de entrevista, se entreviste a todas las partes afectadas y se cumpla con el plan. A partir de la informacin obtenida se debe documentar el sistema actual con sus inconvenientes y la lista de los nuevos requerimientos del nuevo sistema, el auditor debe verificar que el catalogo de requerimientos ha sido revisado y aprobado por las partes afectadas e interesadas, incluyendo los modelos lgicos de datos y lgico de procesos. Tambin verificar la existencia de procedimientos para el cambio en los requisitos del sistema por parte de los usuarios. En esta fase, el auditor debe comprobar que para solucionar los problemas existen mas de una alternativa de solucin, entre estas alternativas puede ser comprar la solucin o un desarrollo interno o externo y se debe verificar los criterio de seleccin de la solucin del proyecto. 2. 1.2. Especificaciones Funcionales del Sistema (EFS).

Una vez conocido el sistema actual, los requisitos del nuevo sistema y la alternativa de desarrollo ms favorable, se elaborara una especificacin funcional detallada del sistema que sea coherente con lo que se espera de l. El nuevo sistema debe especificarse de forma completa desde el punto de vista funcional, contando esta especificacin como la aprobacin de los usuarios. Se debe desarrollar un modelo lgico de nuevo sistema, incluyendo modelo lgico de procesos (MLP) y modelo lgico de datos (MLD). Ambos deben ser

consolidados para garantizar su coherencia.

7

El auditor debe revisar que los modelos se realizaron partiendo de los modelos realizados en el anlisis de requisitos del sistema con la participacin de los usuarios, se ha realizado con la tcnica adecuada y normalizado al menos hasta la tercera forma normal y verificar la aprobacin de los modelos por las partes afectadas e interesadas en el proyecto. Adems el auditor debe revisar que el nuevo sistema incluir los requisitos de seguridad y de auditoria, planes de pruebas y los procedimientos para el cambio o reajuste al proyecto o especificaciones del el.

2.1.3. Aspectos de consideracin de la fase de anlisis:

Dentro de la fase de anlisis, para auditar un proyecto de ingeniera de software, se clasifican en cinco puntos, que son de vital importancia para el auditor que est asignado en este proyecto como son: 2.1.3.1 Estudio de Factibilidad / Viabilidad. En el proyecto deben participar todas las unidades a las que afecta el nuevo sistema. Esta participacin ser normalmente a travs de entrevistas, en la cual se debe comprobar que: o Existe un documento aprobado por el comit de direccin en el que se determina formalmente el grupo de usuario que participa en el proyecto. o Los usuarios elegidos son suficientemente representativos de las distintas funciones que se lleva a cabo en las unidades afectadas por el nuevo sistema. o Se les han comunicado a los usuarios su participacin en el

proyecto. o Se desarrollo un plan detallado de entrevistas con el grupo de usuarios del proyecto y con los responsables de las unidades afectadas por el nuevo cambio del sistema. o Evaluar que las preguntas en la entrevista permitan obtener informacin sobres las funciones que se realiza y cules son los problemas que necesita resolver.

2.1.3.2. Definicin de Requerimientos.

Se definen las alternativas ms favorables para conseguir que el sistema cumpla con los requisitos establecidos. o Evaluar que se hayan definido alternativas de construccin para el desarrollo de nuevo proyecto de ingeniera de software. o Verificar que exista un modelo lgico de los procesos. o Evaluar que se haya buscado en el mercado nuevas alternativas para la adquisicin del software siempre y cuando cumpliendo con los requerimientos exigidos. o Evaluar que estos requerimientos vayan acorde con las respuestas obtenidas en la entrevista por parte de usuarios del sistema. Que no se descarte la opcin que se tiene, de compra o de desarrollo de software. o Evaluar que se estn cumpliendo los requerimientos de seguridad, rendimiento, copia de seguridad y recuperacin expuestos por los usuarios.

2.1.3.3. Adquisicin de Software (compra o desarrolla).

El comit directivo en conjunto con los usuarios que manejan el aplicativo se rene y exponen sus sugerencias y recomendaciones, basndose en las necesidades que se tienen en comn. Con el nico fin de definir si el nuevo proyecto de ingeniera de software ser comprado a un proveedor o solo se contratara para su desarrollo. El auditor debe: o Evaluar las diferentes alternativas que ofrecen los proveedores con relacin a las necesidades planteadas por los diferentes usuarios de

10

la unidad afectada, determinando desarrolla.

as, si se compra o si de

o Evaluar la forma en que el nuevo sistema interactuar con los distintos usuarios. Es considerada como la parte ms importante para los usuarios, ya que determinar su forma de trabajar. o Evaluar el diseo del nuevo software, que cumpla con las necesidades planteadas por el comit directivo. Que las pantallas por las cuales se navegara la aplicacin, muestren el detalle de funcionalidad, el manejo de las teclas est disponible para cada requerimiento. o Verificar que si el software anterior tena un diseo o estilo de informe determinado y unos formularios previamente diseados con cierto objetivo, estos deben ser respetados en la implementacin del nuevo software. o Evaluar en caso que sea compra de software, que se hayan realizado pruebas de aceptacin del sistema, el cual debe ser coherente con el catalogo de requisitos y con la especificaciones funcionales del sistemas, a la vez que haya sido aceptado por el grupo de usuarios y por el comit de direccin. 2.1.3.4. Documentacin de la fase.

A travs del resultado de la entrevista que fue desarrolla a cada funcionario se espera obtener informacin de cmo est el sistema actual al igual que sus problemas asociados. El auditor debe: o Verificar la existencia de un catalogo con los requisitos del nuevo sistema. o Verifica que exista un documento con el modelo fsico del sistema actual, que muestre los objetivos y funciones de cada unidad, as como el flujo de entrada y salida de informacin.

11

o Verificar la existencia de catlogos de requisitos los cuales deben estar justificados. Estos deben ser concretos y cuantificables, para que al final de proyecto puedan ser cumplidos. o Verificar que exista un documento con todas las alternativas presentada por el proveedor desarrollador del proyecto de ingeniera de software. o Evaluar el anlisis costo/beneficio de que cada una de las alternativas expuesta en el desarrollo del proyecto. o Verificar que exista un diccionario de datos, el cual debe incluir todo los conceptos utilizados en el desarrollo del proyecto de ingeniera de software, el cual debe gestionarse de forma automatizada. o Verificar que exista la documentacin donde se observe que la interfaz de usuario haya sido aprobada por el grupo de usuario y por el comit de direccin. o Verificar que el catalogo de requisitos haya sido evaluado y aprobado por cada usuario de la unidad y por el comit de direccin. Constituyendo as un contrato entre los usuarios y el equipo que desarrollara el proyecto.

2.1.3.5. Identificar, evaluar y controlar riesgos.

Es uno de los cinco puntos ms importante, aqu el auditor debe de implementar todo su conocimiento, entregndole al comit directivo toda la documentacin previa del anlisis realizado con los usuarios para el cambio correspondiente a un proyecto de ingeniera de software, en el que se analiz, identific, y evaluaron los posibles riesgos en los que se podra incurrir. Para esto destacamos las siguientes consideraciones evaluadas por el auditor.

12

o Evaluar que en durante toda la fase de anlisis se hayan identificado los posibles riesgos que se tendran durante del desarrollo o compra de un proyecto de ingeniera de software. Los cuales deben estar soportados en la documentacin. o Verificar que en la documentacin se tenga soportado, toda la evaluacin o anlisis previo al nuevo cambio realizado en el

software. Que los usuarios estn de acuerdo y hayan participado en su diseo y elaboracin con sus sugerencias, facilitndoles as su trabajo y mejor desempeo en cada una de sus actividades. o Evaluar los posibles riesgos a los cuales se ve expuesto la organizacin al momento de decidir realizar un proyecto de ingeniera de software, teniendo en cuenta varios aspectos que pueden influir como son: el tiempo de entrega, presupuesto asignado para dicho adquisicin y grupo de trabajo conformado. o Verificar que cada requerimiento expuesto en el contrato de adquisicin se est cumpliendo a cabalidad por parte del proveedor contratado. 2.2. AUDITORIA DE LA FASE DE DISEO.

En la fase de diseo se elaborar el conjunto de especificaciones, fsicas del nuevo sistema que servir de base para la construccin del mismo. 2.2.1. Definir el entorno tecnolgico.

En un proyecto de ingeniera de software el entorno tecnolgico con el que se desea trabajar debe ser definido, teniendo en cuenta sus

especificaciones funcionales. El auditor debe evaluar que se haya definido desde el principio del proyecto el entorno tecnolgico requerido. Evaluar que los equipos de cmputos, sistema operativo seleccionado, equipo de trabajo, conexiones de red, protocolos de transferencias, sean

13

los adecuados y estn en condiciones ptimas para el desarrollo del proyecto de ingeniera de software. Verificar que todos los elementos necesarios tantos tecnolgicos como humanos se encuentren acorde a los estndares del departamento de informtica, que sean capaces de cumplir con cada requerimiento expuesto en la fase de anlisis anteriormente mencionada. Logrando as un tiempo de respuesta optimo y seguridad en cada uno de sus procesos. Evaluar que los componente o programas de uno proyecto de ingeniera de software se hayan definido de acuerdo al sistema donde funcionaria, que su diseo modular este bien estructurado, con el fin que si llegara a

presentarse el caso de contratar un programador externo este desarrollara este el software sin ningn inconveniente. Constatar que se haya realizado un plan de prueba con el diseo tecnolgico sugerido por los usuarios. Este plan debe quedar como constancia en la documentacin del proyecto.

2.2.2. Efectuar el diseo tcnico con la participacin del usuario.

Verificar que en la documentacin se encuentren todas las actividades fsicas que debe desempear cada uno de los usuarios. Evaluar que el diseo tcnico sugerido por los usuarios, sea el correcto, que cumpla y satisfaga todas las necesidades planteadas en la fase de anlisis. Adems que sea fcil de manejar, que cualquier usuario pueda interactuar con el nuevo software.

Evaluar que el diseo tcnico, pueda ser utilizado para el desarrollo de otras aplicaciones, en caso de ser necesarios. Verificar que el diseo de estructura fsica de datos este acorde a las necesidades planteadas en la fase de anlisis, teniendo en cuenta su diseo tecnolgico.

14

2.2.3. Documentacin de la fase.

Constatar que en los requisitos se hayan especificado las caractersticas tecnolgicas y humanas necesarias para el desarrollo del proyecto de ingeniera de software.

Los directivos de la organizacin, deben estipular el recurso estimado necesario para el desarrollo o compra del proyecto. Verificar que exista en el documento final, el diseo modular del sistema, el cual fue aprobado y verificado por los diferentes usuarios. Evaluar que tanto los requerimientos como los posibles incumplimientos de las normas y estndares solicitados sean cumplidos, y en caso contrario que sanciones sern impuesta a este funcionario, sea proveedor interno o externo.

Verificar que exista documentacin que soporte el plan de prueba en el diseo tecnolgico sugerido por los usuarios. Este plan debi ser elaborado por personal diferente al que desarrollo el nuevo sistema.

2.2.4. Identificar, evaluar y controlar riesgos.

El auditor en cada uno de los puntos anteriores durante su anlisis desarrolla y comprueba que se cumpla a cabalidad lo soportado en la fase de documentacin, teniendo en cuenta siempre las posibles mejoras a las cuales est expuesto un proyecto de ingeniera de software. Analizando los riesgos que existen o podran existir.

En la parte del diseo tecnolgico podran existir muchos riesgos, los cuales podra afectar el buen desarrollo del nuevo sistema de software requerido en la organizacin, hay que evaluar que los recursos tantos tecnolgicos como humanos sean los adecuados para el desarrollo de ese proyecto, si se selecciona uno que no funciono como se desea, se podra

15

incurrir en riesgos, demora en la entrega, fallas tecnolgicas, demora en la entrega de las actividades por parte de los usuarios, entre otros. Al efectuar el diseo del proyecto de ingeniera de software, con la participacin de los usuarios, hay que destacar que su participacin juega un papel muy importante, debido a que ellos son los usuarios que conocen perfectamente el funcionamiento del sistema, y cualquier cambio lo van a desarrollar de la mejor manera. Los auditores deben verificar que se haya permitido su participacin en la parte del diseo del proyecto, que la estructura modular haya quedado bien diseada, lo que ayuda a que si llega una persona externa esta pueda empezar a desarrollar sin ningn inconveniente. En la documentacin del proyecto, tanto en la fase de anlisis como en la fase de diseo debe quedar todos los requerimientos, totalmente relacionados. Si existiera algn incumplimiento por parte del proveedor contratado que sanciones legales se les estara imponiendo. Esto asegurara el xito del proyecto.

16

CONCLUSION

Auditar un proyecto de ingeniera de software incurre en muchos aspectos claves que se deben desarrollar de manera ordenada, para as poder conseguir el objetivo propuesto. Este trabajo se desarroll tomando como base las fases del ciclo de vida propuesta por AUDITORA INFORMTICA UN ENFOQUE PRCTICO. Mario G. Piattini. A travs de este enfoque se puede desarrollar dicha auditoria, la fase de aprobacin y planeacin, Anlisis y Diseo detallan paso a paso cada uno de los procesos o actividades y controles esenciales que se deben tener en cuenta para el desarrollo de la auditoria del proyecto de ingeniera. Es muy importante establecer al inicio del proyecto la participacin del auditor, se puede considerar dos aspectos; el primero, la participacin del auditor desde el mismo inicio del proyecto hasta la culminacin; y el segundo, cuando el proyecto esta culminado. En cualquiera de los dos el auditor debe comprobar la existencia de los controles necesarios y el cumplimiento de todas las actividades de cada fase del ciclo de vida.

17

BIBLIOGRAFIA Auditoria Informtica, Un enfoque practico, 2 edicin ampliada y revisada, de Mario E Piattini, Emilio del Peso. Manual de informacin tcnica para la preparacin del examen CISA. ISACA

18