AUDITORIA DEL CONTEO DE PUNTOS DE FUNCIONALIDAD

Originalmente publicado en IFPUG de marzo de 1996.

por David Longstreet
Copiar a disco este artículo

Introducción

Los términos auditor y auditoría nos hacen sentir intranquilos a muchos de nosotros. Muchas industrias tienen inspectores y auditores independientes. En la medida en que los Puntos de Funcionalidad se vuelven más ampliamente usados y se convierten en una parte importante para la toma de decisiones, aquellos que usan conteos de Puntos de Funcionalidad van a querer que sean independientemente revisados y auditados. La auditoría es el proceso mediante el cual una persona competente e independiente acumula y evalúa evidencias acerca de información cuantificable relacionada con una entidad específica para el propósito de determinar y reportar el grado de correspondencia entre la información cuantificable y los criterios establecidos.

Como muchas otras industrias que han establecido guías (tales como la contabilidad), auditores independientes pueden proveer retroalimentación valiosa acerca del conteo de Puntos de Funcionalidad y acerca del proceso de conteo de Puntos de Funcionalidad en general. Un auditor de Puntos de Funcionalidad debe ser independiente, pero un auditor puede también estar en el interior de su compañía, quizás como parte de su equipo de métricas, o puede ser también una tercera persona trabajando independientemente.

Para realizar una auditoría de cualquier tipo, debe haber información en una forma verificable y que cumpla con un estándar (de preferencia IFPUG 4.0) para que el auditor pueda evaluar la información. El auditor puede ir donde la compañía a examinar los registros y obtener información acerca de la confiabilidad del conteo de los Puntos de Funcionalidad. Por otra parte, puede haber información apropiada que puede ser enviada al auditor de Puntos de Funcionalidad para que la revise fuera de la compañía.

Acumulación y Evaluación de Evidencia

La revisión de un conteo de Puntos de Funcionalidad para asegurar que las guías IFPUG 4.0 fueron seguidas, se considera como cumplimiento de la auditoría. El propósito de una auditoría de cumplimiento es determinar si un conteo de Puntos de Funcionalidad sigue los procedimientos y guías específicos establecidos por el comité de prácticas de conteo del grupo IFPUG. Los resultados de una auditoría de cumplimiento son generalmente reportados a alguien dentro de la unidad organizacional que está siendo auditada en vez de a un espectro amplio de usuarios.

La evidencia es definida como cualquier información usada por el auditor para determinar si el conteo de los Puntos de Funcionalidad que está siendo auditado está en cumplimiento con las guías del grupo IFPUG. La evidencia puede tomar muchas formas diferentes, el conteo de Puntos de Funcionalidad, la documentación del sistema, conversaciones con desarrolladores e usuarios, y entrevistas con personas que llevaron a cabo el conteo original. El auditor reúne la evidencia y saca conclusiones.

Por supuesto el conteo de Puntos de Funcionalidad en sí puede ser usado como evidencia, pero el uso de solo el conteo de Puntos de Funcionalidad sería muy inadecuado. Es imposible determinar la precisión de un conteo de Puntos de Funcionalidad sin la evaluación de evidencia adicional.

Si a un auditor se le da la tarea de auditar una compañía con 500,000 Puntos de Funcionalidad, sería imposible revisar cada conteo. El auditor puede seleccionar solo de 20 a 30 aplicaciones para practicar la auditoría. El tamaño de la muestra variará de auditor en auditor y de auditoría en auditoría. La decisión de cuántos elementos probar debe ser hecha por el auditor para cada procedimiento de auditoría. Hay varios factores que determinan el tamaño apropiado de la muestra en las auditorías. Los dos más importantes son las expectativas de los auditores en cuanto al número de errores y la efectividad de los procedimientos de conteo de Puntos de Funcionalidad de los clientes internos. Los procedimientos sugeridos al final de este documento pueden ayudar a determinar ambos criterios.

Adicionalmente, la evidencia debe incumbir o ser relevante en la auditoría. El auditor debe ser diestro en encontrar áreas para probar o revisar con más detenimiento. Por ejemplo, el auditor puede determinar durante las conversaciones que hubo cierta confusión acerca de las entradas externas y de los archivos de interfase externos. En este caso, el auditor debe revisar el sistema actual de documentación y el conteo de los Puntos de Funcionalidad para asegurarse que todas las entradas externas y los archivos de interfase externos fueron tratados correctamente. Otro ejemplo, sería que el contador de Puntos de Funcionalidad nunca hubiera contado una aplicación GUI. El auditor revisaría una serie de pantallas para determinar se el contador original contó correctamente tales elementos como botones de opción, cajas de verificación, etc.

La evidencia se debe considerar creíble y digna de confianza. Si la evidencia se considera digna de confianza, representa una gran ayuda para el auditor en la auditoría de Puntos de Funcionalidad. Por otra parte, si la evidencia es cuestionable tal como una documentación incompleta (o documentación vieja) entonces el auditor tendría que escrutar esas áreas de conteo más concienzudamente. Adicionalmente, el auditor debe tomar nota en el reporte final de cualquier evidencia que pidió y el cliente no se la pudo proporcionar.

Toda evidencia debe ser evaluada en base a valuación, grado de terminación, clasificación, rango, precisión mecánica y análisis analítico.

Valuación [Valuation]: El objetivo trata acerca de si algunos elementos incluidos en el conteo de los Puntos de Funcionalidad debieron haber sido incluidos. Quizás el conteo original de los Puntos de Funcionalidad incluyó transacciones o archivos adicionales que no debieron ser incluidos.

Grado de Terminación [Completeness]: El objetivo trata de incluir todas las transacciones y archivos en el conteo final de Puntos de Funcionalidad. Es importante que el equipo de la aplicación revise el conteo final de los Puntos de Funcionalidad para asegurar que todas las transacciones y archivos han sido incluidos. Los objetivos de valuación y grado de terminación enfatizan intereses de auditoría contrarios. La valuación trata con sobrestimaciones potenciales y el grado de terminación trata con transacciones y archivos no registrados.

Rango [Rating]: Este objetivo trata de determinar si las transacciones y los archivos fueron clasificados correctamente como bajo, promedio o alto. Para completar este objetivo se debe realizar un examen detallado de los elementos de datos y archivos referenciados.

Precisión Mecánica [Mechanical Accuracy]: El probar la precisión mecánica involucra la revisión de una muestra de los cálculos y transferencias de información de un documento a otro. La revisión de los cálculos consiste en probar la precisión aritmética del conteo original de Puntos de Funcionalidad. Esto es más importante si no se usó una herramienta automática para contar los Puntos de Funcionalidad.

Análisis Analítico [Analyticial Analysis]: Este procedimiento es otra manera de validar el conteo de Puntos de Funcionalidad. Por ejemplo, la proporción de entradas externas, salidas externas, consultas externas, archivos lógicos internos y archivos de interfase externos pueden ser comparados con otras aplicaciones que cumplan con necesidades similares. También, las características generales del sistema pueden ser revisadas y comparadas con aplicaciones similares. Los procedimientos analíticos deben ser realizados durante las primeras fases de una auditoría de tal manera que puedan ayudar al auditor a determinar las áreas que necesitan ser investigadas más profundamente.

Antes de realizar una auditoría o una validación de un conteo de Puntos de Funcionalidad se debe seguir un procedimiento para evaluar el(los) conteo(s). Un procedimiento, como mínimo, que debe cubrir todas las áreas mencionadas anteriormente. El procedimiento no tiene que ser un documento rígido, sino una guía para conducir una auditoría. Al final de este artículo hay un procedimiento de 20 pasos que será de gran utilidad para cualquiera que esté desarrollando sus propias guías o que esté realizando una auditoría de un conteo de Puntos de Funcionalidad.

El Auditor

El auditor debe ser capaz de entender los criterios usados y competente para saber los tipos y la cantidad de evidencia que se debe tener para llegar a una conclusión después que la evidencia ha sido examinada. El auditor también debe tener una actitud mental independiente. No ayuda en nada el tener una persona competente pero con prejuicios, haciendo una auditoría.

La independencia no debe ser absoluta de ninguna manera, pero debe ser una meta. Por ejemplo, aunque la compañía le pague sus servicios al auditor, éste debe ser lo suficientemente independiente como para conducir auditorias en que los usuarios puedan confiar. Los auditores pueden no ser lo suficientemente independientes si son también empleados de la compañía.

Tipos de Reportes

La etapa final del proceso de auditoría es el reporte de auditoría - la comunicación de los resultados a los usuarios. Los reportes difieren en naturaleza, pero en todos los casos deben informar a los lectores del cumplimiento de las guías de conteo del grupo IFPUG. El auditor puede tener tres tipos de reportes:

Como en todas las auditorias, el reporte más común que se usa es el Reporte Completo Estándar de Auditoría (Standard Unqualified Audit Report). Es usado en un 90 por ciento de todas las auditorías, y no debe ser diferente para una auditoría de Puntos de Funcionalidad. Este reporte es usado cuando las siguientes condiciones se cumplen:

  1. Toda la documentación de los sistemas y usuarios ha sido incluida en el conteo original de Puntos de Funcionalidad.
  2. Las guías prácticas de conteo del grupo IFPUG se cumplieron
  3. El conteo de Puntos de Funcionalidad se documentó sin problemas

Otro tipo de reporte de auditoría es "condiciones que requieren una desviación." Hay dos condiciones que requieren una desviación del Reporte Completo Estándar de Auditoría.

  1. El alcance del auditor ha sido restringido. Este es el caso cuando el auditor no ha reunido suficiente evidencia para concluir si el conteo de Puntos de Funcionalidad se realizó de acuerdo a las guías de conteo IFPUG 4.0
  2. El conteo de Puntos de Funcionalidad no se realizó de acuerdo a las guías de conteo IFPUG 4.0. En este caso, se debe incluir en el reporte final un análisis detallado de las áreas específicas.

Adicionalmente, el auditor puede emitir una opinión adversa. Una opinión adversa se usa solo cuando el auditor cree que el conteo de los Puntos de Funcionalidad está tan engañoso que no representa propiamente el tamaño funcional de la aplicación que se está midiendo. El auditor debe ser muy específico en el porqué está llegando a esta conclusión.

Un Procedimiento de 20 Pasos para Auditar el Conteo de Puntos de Funcionalidad

1. ¿Fue la tarea de conteo de Puntos de Funcionalidad incluida en el plan general del proyecto?

Todas la actividades que el equipo de trabajo emprende deben estar incluidas en el plan del proyecto. Asegúrese que se dedica la cantidad de tiempo necesaria para completar la tarea en su totalidad.

2. ¿Ha recibido entrenamiento formal en el conteo de Puntos de Funcionalidad la persona a cargo del conteo? ¿Están certificados los encargados de impartir el entrenamiento?

Muy a menudo los conteos de Puntos de Funcionalidad son realizados por personal que no ha sido formalmente entrenado. No es necesario tener un salón de clases para entrenamiento, pero lo que si es necesario es que la persona que imparte el entrenamiento esté familiarizada con las reglas de conteo IFPUG 4.0

Es aun más deseable que la persona que realiza el conteo haya pasado el examen de certificación IFPUG. Pasar el examen no asegura que el conteo sea preciso, pero garantiza al menos un nivel mínimo de competencia.

3. ¿Se tomaron en cuanta las prácticas de conteo IFPUG 4.0?

4. ¿El contador de Puntos de Funcionalidad usó documentación reciente del proyecto para contar los Puntos de Funcionalidad? Si no, ¿qué tan antigua era la documentación?

5. ¿El equipo de trabajo participó en el conteo de Puntos de Funcionalidad?

El equipo de trabajo debe estar integrado por las personas más conocedoras con respecto a la funcionalidad entregada al usuario. Ellos son la mejor fuente de información con respecto al proyecto. Frecuentemente el equipo de trabajo no tiene participación alguna cuando se realiza un conteo de Puntos de Funcionalidad. El contador de Puntos de Funcionalidad reúne alguna documentación y se sienta en su cuarto de trabajo por varios días hasta obtener un conteo de Puntos de Funcionalidad. Esto ocasionaría el cuestionamiento de los integrantes del equipo de trabajo en cuanto a la precisión del conteo.

6. ¿Se siguieron las guías internas de conteo de Puntos de Funcionalidad?

7. ¿Se midió la aplicación desde el punto de vista del usuario?

8. ¿Se midió el sistema desde un punto de vista lógico, no físico?

9. ¿El límite establecido para el conteo de Puntos de Funcionalidad está de acuerdo con los límites de otras métricas (reporte de tiempo, rastreo de defectos)? Si no, ¿Por qué?

10. ¿Si el conteo de Puntos de Funcionalidad era para un mantenimiento, era el límite el mismo que el límite para la aplicación? Si no, ¿Por qué?

11. ¿Ha cambiado el límite?, Si es así, ¿Por qué?

12. ¿Se usó alguna herramienta en el conteo de Puntos de Funcionalidad, o el conteo se realizó manualmente?

Si el conteo se realizó manualmente, se debe revisar la aritmética usada

13. ¿Los porcentajes de los componentes individuales de los Puntos de Funcionalidad (EI, EO, EQ, ILF, EIF ) están en conformidad con el promedio de la industria?, Si no, ¿Hay alguna razón válida?

Si se auditan varias aplicaciones, ¿son los porcentajes de transacciones y archivos similares?

14. ¿Ha sido revisado por el equipo de trabajo un inventario de transacciones (EI, EO, EQ) y archivos (ILF, EIF)?

El error más grande cuando se cuentan Puntos de Funcionalidad es el error de omisión (no incluir todo). Es importante que el equipo de la aplicación revise el conteo de Puntos de Funcionalidad para verificar el grado de terminación y de precisión.

15. ¿El Factor de Ajuste total es compatible con otros proyectos? El Factor de Ajuste total debe caer dentro del +/- 5 por ciento del promedio del factor de ajuste para todas las aplicaciones revisadas. Si cae fuera de este rango, se debe incluir una explicación por escrito junto con el conteo de Puntos de Funcionalidad. Por ejemplo, si el VAF promedio fue de 1.05, entonces el VAF debió haber estado entre 1.0 y 1.1

16. ¿Cada una de las 14 Características Generales del Sistema cae dentro de los rangos de otros proyectos? ¿ Cada una de las Características Generales del Sistema está dentro de 1 punto del promedio de GSC’s?. Por ejemplo, si una GSC particular se mide como 2.0, entonces la GSC debe ser 1, 2 o 3. Si la GSC está fuera de este rango, se debe incluir una explicación por escrito junto con el conteo de Puntos de Funcionalidad.

17. ¿Se han documentado todas las suposiciones hechas en el conteo de Puntos de Funcionalidad? Todas las suposiciones deben ser documentadas para que puedan ser revisadas posteriormente en caso necesario

18. ¿Son estas suposiciones consistentes con otros proyectos?

19. ¿Se han enviado todas las suposiciones que afectan el conteo de Puntos de Funcionalidad a un grupo central de Puntos de Funcionalidad? Todas las suposiciones deben ser revisadas por un grupo central de Puntos de Funcionalidad

20. ¿Ha sido revisado el conteo por un especialista certificado en conteos de Puntos de Funcionalidad?

Conclusiones

En casi cada industria compleja, hay auditores e inspectores y el análisis de Puntos de Funcionalidad no debe ser la excepción. No hay que temer ni a las auditorias ni a los auditores. Si las auditorias se realizan apropiadamente, deben proveer retroalimentación valiosa acerca del proceso de conteo de Puntos de Funcionalidad. El reporte de auditoría puede permitirle que corrija cualquier conteo de Puntos de Funcionalidad incorrecto, y reevaluar posteriormente las decisiones que se han tomado.

Acerca del autor

David Longstreet se graduó de Texas A&M University. El Sr. Longstreet ha escrito varios artículos acerca de métricas de software, Puntos de Funcionalidad, mantenimiento de software, y pruebas. Es coautor del libro Software Measurement and Computers (IEEE Computer Society Press, 1990). Ha sido editor técnico de varias conferencias y publicaciones.

El Sr. Longstreet es un consultor independiente y ha sido miembro de la mesa directiva de IFPUG desde 1993, teniendo la posición de director de la conferencia. Recientemente ganó la distinción de "Quest of the Month" del mes de septiembre en el foro CompuServe’s CASE-DCI, donde discutió y contestó preguntas acerca de Puntos de Funcionalidad.

Al Sr. Longstreet se le puede localizar en la dirección: 2207 West Walnut, Blue Springs, MO 64015 (816/224-0419; fax 816/224-0419; david@softwaremetrics.com; www.softwaremetrics.com


Back to Home


Questions or Comments? webmaster@softwaremetrics.com
Copyright © 1996, 1997, 1998, 1999, 2000, 2001 Longstreet Consulting Inc.
Revised: July 05, 2001.