DE QUÉ MANERA SON ÚTILES LOS PUNTOS DE FUNCIONALIDAD

(Publicado originalmente en American Programmer, diciembre de 1995.)

Copiar a su computadora este artículo

El uso de Puntos de Funcionalidad para ayudar a definir cuándo y qué someter a un proceso de reingeniería

Muchos proyectos de reingeniería se emprenden sin un análisis costo-beneficio. El análisis costo-beneficio busca la mejor proporción de beneficio contra costo, esto significa por ejemplo encontrar las aplicaciones que se benefician más con un proceso de reingeniería. Para determinar qué aplicaciones se beneficiarían más de un proceso de reingeniería, se deben contestar dos preguntas:

  1. ¿Cómo identificamos las aplicaciones a someter a un proceso de reingeniería?
  2. ¿Cómo calcular los beneficios potenciales de un esfuerzo de reingeniería?

Identificación de las aplicaciones a someter a un proceso de reingeniería

Una vez que una organización ha completado una línea base (establecido el número de Puntos de Funcionalidad) de todas las aplicaciones de producción, las horas de mantenimiento para cada Punto de Funcionalidad se puede calcular para cada aplicación. Las horas de mantenimiento por Punto de Funcionalidad se pueden graficar en un diagrama similar al que se muestra abajo. En el eje X está el tamaño (tal como se mide en Puntos de Funcionalidad) y en el eje Y están las horas de mantenimiento por Punto de Funcionalidad. Los puntos representan cada aplicación individual.

Tamaño (en Puntos de Funcionalidad)

En la esquina superior derecha están las aplicaciones que son a la vez grandes y caras de mantener por Puntos de Funcionalidad. Estas son las aplicaciones que deben ser consideradas para proyectos de reingeniería. Esto significa que, estas aplicaciones proporcionan el mayor beneficio. Una vez que se aplicó la reingeniería, las Horas de Mantenimiento / Punto de Funcionalidad de cada aplicación deben ser reevaluadas, y el diagrama redibujado. Las horas de mantenimiento por Punto de Funcionalidad de aquellas aplicaciones que se sometieron a reingeniería deben reducirse y estas aplicaciones deben bajar al cuadrante inferior derecho.

Estimando los beneficios (calculando las ganancias)

Hay solo unas cuantas piezas de información necesarias para estimar los beneficios de un proyecto de reingeniería. Estas incluyen las horas de mantenimiento actuales por Punto de Funcionalidad, las horas de mantenimiento esperadas por Punto de Funcionalidad después del proyecto de reingeniería, y el periodo deseado de recuperación. Lo deseable, bajar al cuadrante inferior izquierdo, resulta en horas de mantenimiento por Punto de Funcionalidad de 8 horas. Esto significa que, el proyecto de reingeniería debe reducir el costo por hora por un factor de 2 por Punto de Funcionalidad. Si el periodo deseado de recuperación es de un año entonces el proyecto de reingeniería no debe tomar mas de 2,000 horas para completarse. Simplemente, 2,000 horas es la diferencia entre el tiempo anterior y el nuevo de horas de mantenimiento por Punto de Funcionalidad (2 en este caso) multiplicado por el número de Puntos de Funcionalidad (1,000 en este caso)

El mismo análisis hecho arriba debe ejecutarse para comparar costos de mantenimiento contra costos de desarrollo. Es un hecho aceptado que los dólares de mantenimiento por Punto de Funcionalidad deben ser menores a los dólares de desarrollo por Punto de Funcionalidad. Si los dólares de desarrollo por Punto de Funcionalidad son menos que los dólares de mantenimiento por Punto de Funcionalidad, entonces es más económico desarrollar una nueva aplicación que darle mantenimiento a la aplicación actúal
Back to Top

El uso de Puntos de Funcionalidad para estimar casos de prueba

Muchos intentos se han realizado para tratar de establecer una relación entre Puntos de Funcionalidad y los esfuerzos asociados con el desarrollo de software. La dificultad de establecer esta relación estriba en el hecho de que solo la relación entre Puntos de Funcionalidad y el ciclo de vida completo del software son examinados. Esta sección examina la relación entre Puntos de Funcionalidad y las pruebas -- en particular la relación entre los casos de prueba y los Puntos de Funcionalidad.

La relación entre Puntos de Funcionalidad y el número de casos de prueba es muy fuerte. Capers Jones estima que el número de casos de prueba aproximadamente será igual al número de Puntos de Funcionalidad elevado a la potencia 1.2 (FP 1.2). Esto es, los casos de prueba crecen en una proporción mayor que los Puntos de Funcionalidad. Esto es intuitivo porque cuando una aplicación crece, el número de interrelaciones dentro de la aplicación se vuelven más complejas.

Por ejemplo, si una aplicación de desarrollo tiene 1,000 Puntos de Funcionalidad, debe haber aproximadamente 4,000 casos de prueba. Obviamente, el equipo de desarrollo debe empezar a crear casos de prueba tan pronto como sea posible. Si el equipo de desarrollo espera hasta que el código ha sido completado, posiblemente sólo lograrán crear menos de 4,000 casos de prueba.

Entendiendo el Potencial de Defectos

El número de defectos está relacionado con el número de posibles resultados. El número de posibles resultados está relacionado con el número de casos de prueba. Hay un gran beneficio en la estimación del número de casos de prueba. Entendiendo que el número de casos de prueba nos lleva al análisis lógico de comparar los casos de prueba actuales con los casos de prueba esperados. Si los casos de prueba actuales son menores que los casos de prueba esperados, entonces hay una cobertura de pruebas inadecuada. La cobertura de prueba representa una indicación de defectos potenciales y de futuros costos de mantenimiento. Entre más sea la brecha entre los casos de prueba esperados y los casos de prueba actuales, más grande es el potencial de defectos que no se detectan durante las pruebas.

El siguiente es un principio básico de calidad de software. La única manera que la producción de software va a mejorar es si y sólo si todo el software nuevo integrado a producción es de una calidad más alta que el software que existe actualmente. Es importante entender tanto el potencial de defectos del software actual y el potencial de defectos del nuevo software. Puede ser imposible estimar el número de defectos inherentes en la producción del software actual, pero el potencial de defectos para cada versión de software se puede estimar. La brecha entre los casos de prueba esperados y los casos de prueba actuales es un buen indicador de defectos potenciales.
Back to Top

El uso de Puntos de Funcionalidad para ayudar a entender rangos de productividad amplios

Las medidas de productividad inconsistentes entre proyectos pueden ser un indicador de que un proceso estándar no se está siguiendo. Productividad se define como la razón entre entradas / salidas. Para software, productividad se define como la cantidad de esfuerzo requerido para lograr un cierto grado de funcionalidad (como se mide en Puntos de Funcionalidad).

Muchas organizaciones sufren cuando sus niveles de productividad son mayores o menores del 100 por ciento. Esto es verdad aun cuando hayan contado los Puntos de Funcionalidad correctamente y capturado los tiempos consistentemente. Las organizaciones de seguido se quejan de análisis de productividad sin valor. En la mayoría de las organizaciones, el software se crea de muy diferentes maneras, usando muy diferentes procesos (y en muchos casos, sin procesos). Si el software se desarrolla inconsistentemente, como consecuencia las medidas de productividad también resultan inconsistentes. Lo mismo puede ser cierto para cualquier proceso de producción. Cambios bruscos en medidas de productividad entre proyectos es una indicación que no se está siguiendo un proceso estándar. En la medida que los equipos de trabajo se adhieren a un proceso estándar de desarrollo, los rangos de productividad se deben estabilizar y ser más consistentes.
Back to Top

El uso de Puntos de Funcionalidad para ayudar a entender el sobrecrecimiento de proyectos

El análisis de Puntos de Funcionalidad provee un mecanismo para monitoriar el sobrecrecimiento de proyectos. El conteo de Puntos de Funcionalidad al final de las fases de obtención de requerimientos, análisis, diseño e implementación se pueden comparar. El conteo de Puntos de Funcionalidad al final de los requerimientos y/o diseño se puede comparar a los Puntos de Funcionalidad al final del proyecto. Si el número de Puntos de Funcionalidad se ha incrementado, se puede asumir que el proyecto ha sido definido de mejor manera o que el proyecto ha crecido en realidad. El crecimiento es una indicación de qué tan bien los requerimientos fueron recogidos y/o comunicados al equipo del proyecto. El crecimiento de todos los proyectos debe ser monitoriado. Si el crecimiento de los proyectos declina a través del tiempo, se asume de manera natural que la comunicación con el usuario ha mejorado.
Back to Top

El uso de Puntos de Funcionalidad para ayudar a calcular el costo real del software

La mayoría de las organizaciones subestima en gran medida el costo del software. El costo real del software es la suma de todos los costos durante la vida de un proyecto, incluyendo los mejoramientos esperados y los costos de mantenimiento. De hecho, el cálculo real debería ser el valor presente de todos los desarrollos, mejoras, y costos de mantenimiento esperados durante la vida del proyecto. Este tipo de análisis demuestra la recompensa de invertir en un diseño y análisis de primera. Entre más se invierta en un buen diseño, se va a ahorrar más en futuros costos de mantenimiento y mejoras. Es importante tener un costo unitario para evaluar la inversión inicial y comparar ésta con los gastos posteriores. El costo unitario puede ser horas/PF o $/PF. Los incrementos en la inversión inicial deben reducir el costo unitario de actividades de mejora y mantenimiento futuras.
Back to Top

El uso de Puntos de Funcionalidad para ayudar a estimar el costo de proyectos, la programación y el esfuerzo

La estimación exitosa usando Puntos de Funcionalidad se basa en varias técnicas de estimación: Top-Down, Analogía y Consejo de Expertos. La estimación Top-Down es una técnica de estimación que calcula el programa entero, costo y esfuerzo usando parámetros amplios. Los parámetros amplios y las comparaciones están basados en datos históricos usando técnicas estimativas de Analogía. El Consejo de Expertos se obtiene de expertos con experiencia en proyectos similares o experiencia en el uso de Puntos de Funcionalidad.

La comparación de proyectos con otros similares es una actividad crítica para lograr una estimación exitosa. Cuando se evalúan proyectos similares, se debe considerar lo siguiente:

  • Tipo de plataforma de hardware - Mainframe, Cliente-Servidor, PC
  • Tipo de lenguaje - COBOL, C, C++
  • Tipo de proyecto - Software del Sistema, Software intermedio, Software de aplicación
  • Tipo de sistema operativo: MVS, Windows, Unix

Una vez que los proyectos han sido determinados, obtener los siguientes datos:

  • Medida histórica de entrega (horas por Punto de Funcionalidad) de proyectos similares
  • Programas históricos (duración de programas por Punto de Funcionalidad) de proyectos similares
  • Costos históricos (dólares por Punto de Funcionalidad)

Una vez que el tamaño del proyecto se ha determinado en Puntos de Funcionalidad, el estimado de horas, costo y programa se puede calcular. Los cálculos se deben hacer con datos de proyectos similares como se describió anteriormente.

Por ejemplo, si se determina que el tamaño del proyecto actual es de 500 Puntos de Funcionalidad y la medida de entrega de un proyecto similar es $10 por Punto de Funcionalidad, entonces el costo total esperado para el proyecto sería $10 ($/Punto de Funcionalidad) x 500 PF’s = $5,000 dólares. Cálculos similares pueden ser hechos para programas, duración y horas.

Back to Top

El uso de Puntos de Funcionalidad para ayudar a entender los costos de mantenimiento

Muchos presupuestos de mantenimiento son establecidos basados en ejecuciones de años pasados. Muchas organizaciones tratan de reducir los costos de mantenimiento y no planean incrementarlos año por año para cualquier aplicación particular. Si la nueva funcionalidad es encontrada y añadida al producto base, los costos unitarios de mantenimiento pueden bajar mientras los gastos reales de mantenimiento permanecen constantes o se incrementan. Si los costos de mantenimiento se incrementan a un ritmo menor que los Puntos de Funcionalidad, el crecimiento de los costos de mantenimiento en realidad disminuye. Por ejemplo, si una organización gasta $100,000 para mantener 10,000 Puntos de Funcionalidad o $10 por Punto de Funcionalidad, pero el número de Puntos de Funcionalidad crece 10% a 11,000 y los dólares de mantenimiento permanecen constantes, entonces los costos de mantenimiento por Punto de Funcionalidad disminuye a $9. Muchos ejecutivos de sistemas no entienden ni asimilan este concepto.
Back to Top

El uso de Puntos de Funcionalidad para ayudar con las negociaciones de contrato

Los administradores de contratos pueden usar su conocimiento en Puntos de Funcionalidad para construir y manejar proyectos basados en el precio por Punto de Funcionalidad y también en la comparación de los precios de los vendedores. Estas personas establecen un uso efectivo en cuanto a costo, de terceras partes, en el desarrollo, validan las propuestas basados en el tamaño de Puntos de Funcionalidad y pueden evaluar el impacto de proyectos cancelados.

Los Puntos de Funcionalidad pueden ser usados para ayudar a especificar los productos claves a entregar a un vendedor, para asegurar que los niveles apropiados de funcionalidad van a ser entregados y desarrollar medidas objetivas de efectividad de costos y calidad. Son los más efectivamente usados en contratos de precio fijo como un medio para especificar exactamente lo que se va a entregar. Desde una perspectiva interna, el manejo exitoso de los contratos de precio fijo depende absolutamente en la representación precisa del esfuerzo. La estimación de este esfuerzo (en el ciclo de vida completo) puede ocurrir solo cuando una métrica normalizada, tal como la proveída por los Puntos de Funcionalidad, se aplica.

Resumiendo, el análisis de Puntos de Funcionalidad provee el mejor método objetivo para medir los proyectos de software, y para manejar el tamaño de los proyectos de software durante su desarrollo. Es el mejor método de manejar el riesgo en dos vertientes. Primero, el cliente (usuario/especificador) puede aceptar más fácilmente el riesgo para un determinado tamaño de proyecto de software (en Puntos de Funcionalidad). Segundo, el desarrollador puede más fácilmente aceptar los riesgos para el costo de producción (el costo por Punto de Funcionalidad). Adherirse a un conteo consistente de Puntos de Funcionalidad optimiza esta relación y facilita el desarrollo en línea y bajo presupuesto.

La asignación de precios de "software externo" (p.ej. el diseñado para uso fuera de la organización) puede ser encauzado directamente al esfuerzo de producción cuando se requieren métricas funcionales. Si un desarrollador de software sabe exactamente cuál va a ser su costo interno de desarrollo de un Punto de Funcionalidad, se puede incorporar a los algoritmos de costeo usados para determinar los precios externos. Sin un entendimiento claro del tiempo y esfuerzo por Punto de Funcionalidad, la asignación de precios a los paquetes de software continuará siendo difícil.
Back to Top

El uso de Puntos de Funcionalidad para desarrollar un estándar de establecimiento de métricas

Por supuesto, los Puntos de Funcionalidad necesitan usarse en asociación con las otras medidas. De hecho, los Puntos de Funcionalidad por sí mismos proveen poco o nada de beneficio. Muchas métricas necesitan ser reportadas al nivel organizacional. Por ejemplo, tanto la métrica de productividad/costo como la métrica de calidad necesitan ser reportadas al nivel organizacional. Las métricas de productividad/costo son usadas para demostrar la medida y el costo de la funcionalidad que se está entregando. Las métricas de calidad son usadas para demostrar niveles existentes de calidad y para monitoriar los esfuerzos continuos de mejoramiento en el proceso de desarrollo del software. Estas métricas deben ser monitoriadas y estudiadas en sus tendencias.

Productividad / Métricas de Costo

1. Costo por Punto de Funcionalidad: mide el costo promedio para entregar o mantener un Punto de Funcionalidad. Estos datos pueden ser usados para desarrollar una base de datos histórica que puede ser usada para estimar proyectos futuros.

2. Puntos de Funcionalidad por Calendario del Mes del Año: mide el tiempo promedio que toma en entregar un Punto de Funcionalidad a producción, dados ciertos niveles de staff.

3. Puntos de Funcionalidad por Staff por Mes: mide el número promedio de Puntos de Funcionalidad entregados por mes de esfuerzo aplicado

Métricas de Calidad

1. Defectos por Puntos de Funcionalidad Instalados: correlaciona la calidad del software al tamaño de la aplicación

2. Horas de Mantenimiento por Puntos de Funcionalidad Instalados: correlaciona los esfuerzos de soporte al tamaño de la aplicación para el software instalado actualmente y los sistemas nuevos. Las aplicaciones con altas proporciones son buenas candidatas para reingeniería o para reemplazo.

3. Defectos por Puntos de Funcionalidad Instalados Recientemente: evalúa la calidad del software reciente para asegurar que las mejoras en el proceso de entrega sean efectivas

Las métricas deben ser indicadores de nivel de ejecución, no medidores exactos del nivel de ejecución. Deben proveer suficiente granularidad para mostrar tendencias generales, identificar áreas problemáticas, y demostrar el progreso. Si el tratar de lograr métricas perfectas causa que se reporten dos o tres meses después de que son tomadas, entonces se deduce que se está gastando mucho tiempo en precisión y no suficientemente en acción. Evite el realizar métricas demasiado precisas.

Resumen

Este artículo empezó al preguntarse: "¿Son los Puntos de Funcionalidad Útiles? Hay muchos usos de los Puntos de Funcionalidad más allá de los programas de estimación, esfuerzo y costo. Muchos administradores de proyectos no creen que los Puntos de Funcionalidad sean útiles. En cierto sentido, están en lo correcto. Muchas organizaciones usan los Puntos de Funcionalidad y las métricas de software solo para reportar tendencias de niveles organizacionales. Muchos equipos de trabajo reportan datos a un grupo de métricas central y nunca ven esos datos otra vez. Esto es análogo a reportar datos a un agujero negro. Si los administradores de proyectos empiezan a entender cómo los Puntos de Funcionalidad pueden ser usados para estimar casos de prueba, calcular costos de mantenimiento, etc., etc., va a ser más probable que inviertan en conteos de Puntos de Funcionalidad. Back to Top


Back to Home


Questions or Comments? webmaster@softwaremetrics.com
Copyright © 1996, 1997 New Vintage, Inc. All rights reserved.
Revised: July 05, 2001.