|
(Publicado originalmente en
American Programmer, diciembre
de 1995.)
Copiar
a su computadora este artículo
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:
- ¿Cómo identificamos las
aplicaciones a someter a un proceso de
reingeniería?
- ¿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
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.
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.
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.
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.
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.
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.
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.
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 Home
Questions or
Comments? webmaster@softwaremetrics.com
Copyright © 1996, 1997 New Vintage, Inc. All rights
reserved.
Revised: July 05, 2001.
|
