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 DISEÑO EN UN PROYECTO DE INGENERÍA DE

SOFTWARE

ING. DORA JANETH ALFONSO

UNIVERSIDAD ANTONIO NARIÑO

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 Análisis de requisitos del sistema (ARS).............................................................................6

2. 1.2. Especificaciones Funcionales del Sistema (EFS)...............................................................7

2.1.3. Aspectos de consideración de la fase de análisis:.............................................................9

2.1.3.1 Estudio de Factibilidad / Viabilidad............................................................................9

2.1.3.2. Definición de Requerimientos.................................................................................10

2.1.3.3. Adquisición de Software (compra o desarrolla).......................................................10

2.1.3.4. Documentación de la fase.......................................................................................11

2.1.3.5. Identificar, evaluar y controlar riesgos....................................................................12

2.2. AUDITORIA DE LA FASE DE DISEÑO.......................................................................................13

2.2.1. Definir el entorno tecnológico........................................................................................13

2.2.2. Efectuar el diseño técnico con la participación del usuario............................................14

2.2.3. Documentación de la fase..............................................................................................15

2.2.4. Identificar, evaluar y controlar riesgos...........................................................................15

CONCLUSION....................................................................................................................................17

BIBLIOGRAFIA...................................................................................................................................18

INTRODUCCION

Este trabajo busca proveer una guía básica a los auditores de sistemas en la

administración de las diferentes etapas del ciclo de vida del desarrollo de

proyectos de ingeniería, tanto el equipo desarrollador como el equipo auditor

necesita conocer los conceptos generales de los procesos y metodologías usadas

en la gestión de desarrollo de nuevos proyectos de ingeniería, el plan de

actividades del equipo desarrollador es diferente al del auditor, quien tiene la

función de comprobar la existencia de los procedimientos de control y de verificar

su correcta aplicación en cada etapa del ciclo de vida del desarrollo del nuevo

proyecto de ingeniería de software, lo cual permite el éxito del proyecto.

1. DEFINICION.

Se entiende por ingeniería de software “el establecimiento y uso de principios de

ingeniería robustos. Orientados a obtener software económico 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 aplicación de

procedimientos de control adecuado que permitan garantizar que el desarrollo de

sistemas de información se ha llevado a cabo según estos principios de ingeniería,

o por el contrario, determinar las deficiencias existentes en este sentido.

El software como producto es muy difícil 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á función 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 corrección de los controles. Si una simple

comprobación no ofrece ninguna evidencia, será necesaria la realización de

exámenes más profundos.

4

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

Cada proyecto tendrá unos objetivos marcados y afectara a determinadas

unidades de la organización. Debe tener un responsable y ser guiados con

técnicas 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 función de los parámetros anteriores.

Dentro del desarrollo de un sistema de información se han propuesto 5

subdivisiones, entre las cuales se encuentran: análisis, diseño, construcción e

implementación. Estas fases son debidamente aceptadas en ingeniería de

software para el desarrollo, son en concreto las que propone la metodología de

desarrollo de sistemas de información Métrica versión 2.1.

La aprobación del proyecto es un hecho previo al comienzo del mismo, mientras

que la gestión se aplica a lo largo de su desarrollo. La planificación 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

técnicas a utilizar y los elementos a inspeccionar, normalmente los productos y

documentos generados en la fase de desarrollo, serán los mismos en ambos

casos. La única diferencia es que en el primer caso las conclusiones que vaya

5

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 aprobación, planificación y gestión del proyecto

debe implementar varios controles, que permitan verificar; la existencia de la

orden de aprobación del proyecto, la cual debe definir claramente los objetivos,

restricciones y las unidades afectadas. Debe estar firmada por un órgano o área

competente; la designación del director del proyecto cumple o se llevo a cabo

según el procedimiento establecido; se han evaluados los riesgos asociados al

proyecto, la selección 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 demás áreas y externo cumplen con los perfiles profesionales

adecuados; la comunicación de la información 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 análisis pretende obtener un conjunto de especificaciones formales que

describan la necesidad de información que pueden ser cubiertas por el nuevo

sistema de una forma independiente del entorno técnico. Se divide en dos

módulos.

2.1.1 Análisis de requisitos del sistema (ARS).

En este modulo se identifican los requisitos del nuevo sistema. Se incluirán 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 exigirán al nuevo sistema, se determinaran las posibles

6

soluciones, alternativas que satisfagan estos requisitos y de entre ellas se elegirán

las más adecuadas.

En esta etapa el auditor debe implementar varios controles para verificar:

La participación 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 información 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 lógicos

de datos y lógico de procesos. También 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 solución, entre estas alternativas puede ser comprar la

solución o un desarrollo interno o externo y se debe verificar los criterio de

selección de la solución 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 más favorable, se elaborara una especificación 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 especificación como la aprobación de los usuarios.

7

Se debe desarrollar un modelo lógico de nuevo sistema, incluyendo modelo lógico

de procesos (MLP) y modelo lógico de datos (MLD). Ambos deben ser

consolidados para garantizar su coherencia.

El auditor debe revisar que los modelos se realizaron partiendo de los modelos

realizados en el análisis de requisitos del sistema con la participación de los

usuarios, se ha realizado con la técnica adecuada y normalizado al menos hasta la

tercera forma normal y verificar la aprobación de los modelos por las partes

afectadas e interesadas en el proyecto. Además 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.

8

2.1.3. Aspectos de consideración de la fase de análisis:

Dentro de la fase de análisis, para auditar un proyecto de ingeniería 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 participación será normalmente a través de entrevistas, en la cual se

debe comprobar que:

o Existe un documento aprobado por el comité de dirección 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 participación 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

información sobres las funciones que se realiza y cuáles son los

problemas que necesita resolver.

9

2.1.3.2. Definición de Requerimientos.

Se definen las alternativas más favorables para conseguir que el sistema cumpla

con los requisitos establecidos.

o Evaluar que se hayan definido alternativas de construcción para el

desarrollo de nuevo proyecto de ingeniería de software.

o Verificar que exista un modelo lógico de los procesos.

o Evaluar que se haya buscado en el mercado nuevas alternativas

para la adquisición 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 opción que se tiene, de compra o de desarrollo de

software.

o Evaluar que se estén cumpliendo los requerimientos de seguridad,

rendimiento, copia de seguridad y recuperación expuestos por los

usuarios.

2.1.3.3. Adquisición de Software (compra o desarrolla).

El comité directivo en conjunto con los usuarios que manejan el aplicativo se reúne

y exponen sus sugerencias y recomendaciones, basándose en las necesidades

que se tienen en común. Con el único fin de definir si el nuevo proyecto de

ingeniería 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

relación a las necesidades planteadas por los diferentes usuarios de

10

la unidad afectada, determinando así, si se compra o si de

desarrolla.

o Evaluar la forma en que el nuevo sistema interactuará con los

distintos usuarios. Es considerada como la parte más importante

para los usuarios, ya que determinará su forma de trabajar.

o Evaluar el diseño del nuevo software, que cumpla con las

necesidades planteadas por el comité directivo. Que las pantallas por

las cuales se navegara la aplicación, muestren el detalle de

funcionalidad, el manejo de las teclas esté disponible para cada

requerimiento.

o Verificar que si el software anterior tenía un diseño o estilo de

informe determinado y unos formularios previamente diseñados con

cierto objetivo, estos deben ser respetados en la implementación del

nuevo software.

o Evaluar en caso que sea compra de software, que se hayan

realizado pruebas de aceptación 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 dirección.

2.1.3.4. Documentación de la fase.

A través del resultado de la entrevista que fue desarrolla a cada funcionario se

espera obtener información de cómo 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 físico del sistema

actual, que muestre los objetivos y funciones de cada unidad, así

como el flujo de entrada y salida de información.

11

o Verificar la existencia de catálogos 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 ingeniería

de software.

o Evaluar el análisis 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 ingeniería de

software, el cual debe gestionarse de forma automatizada.

o Verificar que exista la documentación donde se observe que la

interfaz de usuario haya sido aprobada por el grupo de usuario y por

el comité de dirección.

o Verificar que el catalogo de requisitos haya sido evaluado y aprobado

por cada usuario de la unidad y por el comité de dirección.

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 más importante, aquí el auditor debe de implementar

todo su conocimiento, entregándole al comité directivo toda la documentación

previa del análisis realizado con los usuarios para el cambio correspondiente a un

proyecto de ingeniería de software, en el que se analizó, identificó, y evaluaron los

posibles riesgos en los que se podría incurrir. Para esto destacamos las siguientes

consideraciones evaluadas por el auditor.

12

o Evaluar que en durante toda la fase de análisis se hayan identificado

los posibles riesgos que se tendrían durante del desarrollo o compra

de un proyecto de ingeniería de software. Los cuales deben estar

soportados en la documentación.

o Verificar que en la documentación se tenga soportado, toda la

evaluación o análisis previo al nuevo cambio realizado en el

software. Que los usuarios estén de acuerdo y hayan participado en

su diseño y elaboración con sus sugerencias, facilitándoles así su

trabajo y mejor desempeño en cada una de sus actividades.

o Evaluar los posibles riesgos a los cuales se ve expuesto la

organización al momento de decidir realizar un proyecto de

ingeniería de software, teniendo en cuenta varios aspectos que

pueden influir como son: el tiempo de entrega, presupuesto asignado

para dicho adquisición y grupo de trabajo conformado.

o Verificar que cada requerimiento expuesto en el contrato de

adquisición se esté cumpliendo a cabalidad por parte del proveedor

contratado.

2.2. AUDITORIA DE LA FASE DE DISEÑO.

En la fase de diseño se elaborar el conjunto de especificaciones, físicas del nuevo

sistema que servirá de base para la construcción del mismo.

2.2.1. Definir el entorno tecnológico.

En un proyecto de ingeniería de software el entorno tecnológico 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 tecnológico requerido.

Evaluar que los equipos de cómputos, sistema operativo seleccionado,

equipo de trabajo, conexiones de red, protocolos de transferencias, sean

13

los adecuados y estén en condiciones óptimas para el desarrollo del

proyecto de ingeniería de software.

Verificar que todos los elementos necesarios tantos tecnológicos como

humanos se encuentren acorde a los estándares del departamento de

informática, que sean capaces de cumplir con cada requerimiento expuesto

en la fase de análisis 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 ingeniería de

software se hayan definido de acuerdo al sistema donde funcionaria, que su

diseño modular este bien estructurado, con el fin que si llegara a

presentarse el caso de contratar un programador externo este desarrollaría

este el software sin ningún inconveniente.

Constatar que se haya realizado un plan de prueba con el diseño

tecnológico sugerido por los usuarios. Este plan debe quedar como

constancia en la documentación del proyecto.

   2.2.2. Efectuar el diseño técnico con la participación del usuario.

Verificar que en la documentación se encuentren todas las actividades

físicas que debe desempeñar cada uno de los usuarios.

Evaluar que el diseño técnico sugerido por los usuarios, sea el correcto,

que cumpla y satisfaga todas las necesidades planteadas en la fase de

análisis. Además que sea fácil de manejar, que cualquier usuario pueda

interactuar con el nuevo software.

Evaluar que el diseño técnico, pueda ser utilizado para el desarrollo de

otras aplicaciones, en caso de ser necesarios.

Verificar que el diseño de estructura física de datos este acorde a las

necesidades planteadas en la fase de análisis, teniendo en cuenta su

diseño tecnológico.

14

2.2.3. Documentación de la fase.

Constatar que en los requisitos se hayan especificado las características

tecnológicas y humanas necesarias para el desarrollo del proyecto de

ingeniería de software.

Los directivos de la organización, deben estipular el recurso estimado

necesario para el desarrollo o compra del proyecto.

Verificar que exista en el documento final, el diseño 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 estándares solicitados sean cumplidos, y en caso contrario

que sanciones serán impuesta a este funcionario, sea proveedor interno o

externo.

Verificar que exista documentación que soporte el plan de prueba en el

diseño tecnológico 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 análisis

desarrolla y comprueba que se cumpla a cabalidad lo soportado en la fase

de documentación, teniendo en cuenta siempre las posibles mejoras a las

cuales está expuesto un proyecto de ingeniería de software. Analizando los

riesgos que existen o podrían existir.

En la parte del diseño tecnológico podrían existir muchos riesgos, los

cuales podría afectar el buen desarrollo del nuevo sistema de software

requerido en la organización, hay que evaluar que los recursos tantos

tecnológicos como humanos sean los adecuados para el desarrollo de ese

proyecto, si se selecciona uno que no funciono como se desea, se podría

15

incurrir en riesgos, demora en la entrega, fallas tecnológicas, demora en la

entrega de las actividades por parte de los usuarios, entre otros.

Al efectuar el diseño del proyecto de ingeniería de software, con la

participación de los usuarios, hay que destacar que su participación 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 participación en la parte del diseño del proyecto, que la

estructura modular haya quedado bien diseñada, lo que ayuda a que si

llega una persona externa esta pueda empezar a desarrollar sin ningún

inconveniente.

En la documentación del proyecto, tanto en la fase de análisis como en la

fase de diseño debe quedar todos los requerimientos, totalmente

relacionados. Si existiera algún incumplimiento por parte del proveedor

contratado que sanciones legales se les estaría imponiendo. Esto

aseguraría el éxito del proyecto.

16

CONCLUSION

Auditar un proyecto de ingeniería 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 AUDITORÍA INFORMÁTICA UN ENFOQUE

PRÁCTICO. Mario G. Piattini.

A través de este enfoque se puede desarrollar dicha auditoria, la fase de

aprobación y planeación, Análisis y Diseño 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 ingeniería.

Es muy importante establecer al inicio del proyecto la participación del auditor, se

puede considerar dos aspectos; el primero, la participación del auditor desde el

mismo inicio del proyecto hasta la culminación; 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 Informática, Un enfoque practico, 2ª edición ampliada y revisada,

de Mario E Piattini, Emilio del Peso.

Manual de información técnica para la preparación del examen CISA.

ISACA

18