Capítulo 18 AUDITORIA DE APLICACIONES

18.2 Principales modelos de referencia

El modelo más utilizado es el desarrollado por McCall, en el que la calidad de un
producto software se descompone en factores agrupados en categorías.
Para comprobar la calidad de estos factores lo normal es hacer uso de valores y
para ello es necesario un proceso de medición de software.
Por otro lado, en la calidad de una aplicación software se suelen distinguir tres
aspectos diferentes:
 Calidad interna: medible a partir de las características intrínsecas, como el
código fuente, etc.
Otro modelo de referencia a destacar es el COBIT, desarrollado por el Information
Technology Governance institute, se estructura en cuatro dominios de actividad:
 Planificar y organizar
 Adquirir e implementar
 Entregar y dar soporte
 Monitorizar y evaluar

18.3 Las métricas como herramienta básica en las auditorias de aplicaciones
Las métricas son un buen medio para evaluar y auditar aplicaciones software y
puede ser utilizada para tomar mejores decisiones.
Por lo general, en las auditorias de aplicaciones la medición está centrada en
evaluar la calidad de los entregables, productos del software o salidas del proceso
de producción del software, que incluyen todos los productos intermedios
entregados o documentos que son producidos durante el ciclo de vida del
software. Y la manera más rápida y fiable de tener visibilidad sobre un producto es
recogiendo métricas del producto.
Para un estudio en profundidad de las métricas software, su aplicación y
automatización remitimos al lector.

18.4 Entornos para la evaluación de la calidad de las aplicaciones

La medición es pieza básica a la hora de auditar la calidad de la aplicación, más
aún si el desarrollo es realizado por equipos externos o fábricas software, donde el
receptor del software debe establecer sus propios sistemas de control de calidad.
18.5.1 Fase 1.- Definir el plan de la auditoria de la aplicación
18.5.1.1 Definir el alcance de la auditoria, objetivo y método
Para focalizar bien el objetivo conviene determinar, además de que parte de la
aplicación será el objetivo del estudio, ver que parte de la aplicación será el
objetivo y que método se usará, ya sea estatuto o dinámico.
Para una auditoria hay que destacar los elementos más importantes, como las
fuentes y los objetos o ejecutable. En cuanto a las fuentes, la correcta
construcción de éste, influirán en el mantenimiento de el mismo, evolución y el
impacto económico qué pueda derivarse.
Los ejecutable recogen información sobre el funcionamiento de la aplicación. En
este aso solo se tiene que ver que el software trabaje de manera correcta según
los requisitos.
Cuando se habla sobre observar la aplicación dinámica, se refiere al conjunto de
pruebas o inspecciones qué sé pueden realizar con la ejecución de la aplicación.
Las auditorías refieren a comprobar la funcionalidad de la aplicación y que sea la
esperada.
El estudio de carácter estático se observan los productos que forman la aplicación,
documentos, códigos, etc. Las auditorías de este tipo se enfocan más a observar
la calidad de la programación, diseño, etc., y en muchas ocasiones, al nivel de
mantenibilidad.

18.5.1.2 ESTIMACIÓN Y PLANIFICAR

Después de observar el tamaño de la aplicación a auditar y en función del alcance
ya definido, se definirá el plan temporal y de recursos.
Para cada elemento a estudiar se tendrá un método para adaptarse a realizar una
aproximación de tiempo que la auditoria requiera. Ya determinada la estimación,
se elabora el plan temporal y de recursos.

18.5.1.3 DEFINIR EL EQUIPO DE LA AUDITORIA Y EL PLAN DE

COMUNICACIÓN
Se aprobará con el cliente la estructura de la auditoria, por fases tanto del auditor
como del cliente. El cliente necesitara preparar la aplicación, documentación, etc.,
planificarse y añadirse al plan de auditoria.

18.5.1.4 DEFINIR LAS HERRAMIENTAS DE USO EN LA AUDITORIA

Estas deben especificarse, herramientas de prueba de funcionalidad, carga,
inspección, extracción de métricas etc. Las herramientas para auditar la calidad
suelen clasificarse en dinámicas y estáticas.
Herramientas estáticas obtienen métricas y elementos que muestran su calidad.

Ejemplos de tipos de detecciones:

 Atributo privado no utilizado
 Variable local no utilizada
 Sentencia condicional vacía
 Bucle “while” vacío
 Problemas de Javadoc en métodos
 Estilos Javadoc
 Javadoc en clases de interfaces
 Estándares documentación
 Bucles “for” que deberían ser “while”
 Evitar asignaciones en parámetros
 Densidad en sentencias switch
 Evitar inicializadores estáticos
 Convenios para nombrar clases
Aplicaciones como PMD, Checkstyle de software libre, soportan una amplia
variedad de lenguajes en programación y que contemplan un gran número de
métricas y problemas de calidad, también pueden trabajar en modo batch como
plugins Maven.
Por otro lado, las herramientas dinámicas trabajan sobre la aplicación mientras
ésta se ejecuta y no usan código fuente generalmente, como Purify, de IBM
Rational.
El conjunto de herramientas orientadas a medir la cobertura de las pruebas son
herramientas como EclEmma, que trabaja sobre el entorno de desarrollo Eclipse,
o Cobertura que calcula el porcentaje de código que cubren los casos de prueba.

18.5.2 Fase 2,- Ejecución de la auditoría

La ejecución consta de llevar a cabo los objetivos y tareas con las herramientas
definidas según el plan de auditoria.
En caso de informes o hallazgos encontrados a directivos suelen resumirse y
agruparse. Los informes deben ser siempre concisos, cuidando que la información
que muestre sea significativa. Ya elaborados los informes estos serán comentados
y discutidos con los responsables directos de las áreas afectadas con el fin de
comunicar y corroborar los resultados. Se presentará un informe en el que se
expongan las conclusiones más importantes.

18.6 RECOMENDACIÓNES Y BUENAS PRÁCTICAS

Como conclusión final, buenas prácticas o recomendaciones son:
 Utilizar métricas y factores cuantitativos
 La periodicidad con la que pretenda realizar las auditorias de la aplicación
en muchas ocasiones vendrá determinada por la complejidad del método e
infraestructura para medir la calidad de la aplicación.
 Hay que tener presente que es fácil caer en el problema de recopilar un
excesivo volumen de información y no saber que hacer con ella, por eso es
importante tener objetivos claros y el alcance de las auditorias.
 Es importante definir qué información mostrar, cuando y a quién, según el
nivel de abstracción e información que se requiera en cada situación.
 Lo más conveniente en algunos casos es externar la actividad de auditar la
aplicación a empresas especializadas.
Nunca se debe perder el objetivo final de la auditoria, que será en ejemplo, alinear
objetivos de negocio con planes de mejora, incrementar la productividad y
rentabilidad del desarrollo, aumentar la calidad del software y satisfacción del
usuario, crear ventaja competitiva.