Del software y sus estimaciones: Los puntos de función.

 

Erase una vez, las valoraciones económicas.

Una mañana cualquiera, después de una reunión de una hora:

- Bueno, pues creo que con todo lo que hemos hablado, tendrás claro lo que necesitamos.

- Hombre, aún hay algún punto que aclarar, lo que me has contado del proceso de importación de ficheros Excel hay que concretarlo un poco más.

- Pero hombre, si eso es subir unos ficheritos a la web con los pedidos de los clientes y listo ¿no?.

- Bueno, eso parece a priori. Pero hay alguna que otra laguna... ¿que pasa con los productos no visibles? ¿y si se modifica el Excel? ¿todo el mundo puede subir ficheros?, entiendo que no... pero desde luego tenemos que profundizar un poco... vamos, creo yo.

- Bueno, seguro que cuando te pongas con ello, lo veremos más claro.

- Ya, ya... pero es que también tenemos que ver la parte del gestor de contenidos. Como idea está bien, pero no es sencillo y tenemos que definir bien lo que necesitan los usuarios. Creo que no nos vendrían mal un par de reuniones más.

- A ver, eso también lo hemos visto. Échale un vistazo a Joomla o a Umbraco y te haces a la idea. Claro que no necesitamos tanto... pero por ahí irán los tiros. Además, tengo que reunirme con dirección para presentar el proyecto y necesito que me des tu valoración.

- ¿Valoración?

- Si, por supuesto aproximada. Necesito una cifra para este viernes... y que me digas aproximadamente (risilla maquiavélica) cuanto vais a tardar.

- (con síntomas evidentes de resignación) Veré que podemos hacer...

¿Os suena todo esto? A mi más de lo que me gustaría, la verdad. Podría ser una conversación cualquiera, de un cliente cualquiera con un pobre desarrollador cualquiera... maldita sea! nos ha tocado a nosotros!

Al final, al pobre desarrollador le toca utilizar métodos cuando menos dudosos, para dar una “Valoración aproximada”... como podemos ver aquí.

Y digo yo ¿Debe ser así? Todos sabemos que es muy difícil estimar correctamente el coste inicial de un proyecto de software, más aún si pretendemos (y deberíamos) que este software cumpla unos mínimos de calidad, la tarea se presenta ardua y complicada.

 

Hacer software no es hacer churros, aunque el resultado pueda aproximarse.

Cualquier software que desarrollemos, tiene que cumplir las siguientes premisas:

• Debe alcanzar unas determinadas funcionalidades.
• Respetando los plazos (impuestos o propuestos).
• Respetando el presupuesto económico.

Así expuesto y resumidito, queda fenomenal. Pero claro, la realidad es cuando menos.... pues eso, muy real.

Además, llevar a buen puerto cualquier desarrollo implica conocer los riesgos que, a priori, nos podemos encontrar por el camino. Voy a enumerar los que considero más relevantes:

• El tamaño y la duración: cuanto más grande sea un proyecto, más posibilidades de error y fracaso existen.
• La tecnología: si el equipo conoce la tecnología a utilizar tendremos menos riesgo. además, el ritmo de cambio de la misma convierte en difícil la utilización de la experiencia técnica anterior, porque rápidamente se queda obsoleta.
• Dificultad de determinar las especificaciones: a menudo contamos con unas especificaciones muy difusas e inciertas sobre el sistema que debemos construir. A las primeras de cambio, podemos encontrarnos con unos requisitos crecientes, difíciles de contener sin unas buenas especificaciones.
• La calidad y estabilidad de las especificaciones: Los requisitos de adaptación a la realidad y la complejidad del trato con los futuros usuarios de la  aplicación, provoca que nunca se pueda estar seguro de la estabilidad de las especificaciones, hecho que introduce incertidumbre y riesgo en cualquier proyecto. El dominio de nuestro software puede cambiar en cualquier momento, y con él, todas nuestras especificaciones.
• Mal análisis del problema: esto conducirá a una descomposición del proyecto en actividades y tareas que no es eficiente, e incluso a una definición incorrecta de los límites del proyecto.
• Falta de capacidad de decisión (comunicación deficiente con el cliente) que provoca que demasiadas cuestiones queden sin respuesta, y que nos obligará a trabajar sobre hipótesis provisionales, que cuando son incorrectas o falsas, retrasan y ponen en peligro todo el proyecto.
• Reusabilidad de los sistemas: nuestro software debe tener una duración elevada, y debe ser modificable y escalable, para adaptarse al entorno siempre cambiante de la informática de gestión.

Como veis, los aspectos a tener en cuenta para llegar a nuestro destino no son pocos. Pero si pensabais que esto es un problema relativamente reciente... nada más lejos de la realidad.

Ya en el año 1968 se empezó a detectar un problema central e intrínseco de los proyectos informáticos de construcción de software: diseñar, construir y mantener software seguro, fiable y de calidad es una actividad siempre llena de dificultades. No es una crisis momentánea, algunos autores lo denominan “una verdadera enfermedad crónica”.

¿El cambio es nuestro amigo? no mucho, pero siempre está con nosotros.

Una de las características inherentes al desarrollo de software es la complejidad... así que... eso ya lo sabíamos, nos gusta resolver problemas, y por eso nos metimos en estos “fregaos”. Un proyecto de software es casi algo vivo, no se puede planificar ni tratar como una actividad lineal. Debemos estar preparados para el más que previsible cambio.

Lo primero para poder absorber de una manera lo menos traumática posible los cambios es descomponer el proyecto en diferentes fases. De hecho, y en dado el carácter completamente crucial que tienen las especificaciones del software a construir, algunos autores recomiendan dividir un proyecto informático en dos proyectos consecutivos:

• Un primer proyecto que tenga como objetivo funcional principal establecer simplemente las especificaciones detalladas de lo que después se debe programar e instalar.

• Un segundo proyecto, generalmente con un volumen de esfuerzo y un coste más elevado, que cubra la etapa de programación y pruebas, una vez se han determinado con cierto detalle en el primer proyecto, las especificaciones y las funcionalidades concretas que deben implementarse.

(Sinceramente, creo que me moriré sin ver esa fantástica y práctica división...)

Una buena división en etapas nos permitirá tratar cada fase como un pequeño subproyecto, y de esta manera también protegeremos del cambio (en la medida de lo posible) cada una de las distintas etapas.

Y después de todo esto... seguimos con la valoración. De una manera muy básica, lo que nos va a tocar es dividir nuestro proyecto en actividades, valorar cada etapa o tarea por separado (normalmente en horas), sumar horas... multiplicar por nuestro precio/hora... y... ¿listo?

No tan rápido, Mac Gregor... Acabamos de encontrar el primer problema: planificar y valorar de una manera lo más próxima a la realidad, un proyecto de software.

Para ello debemos encontrar un método de valoración que nos ayude a controlar dos aspectos clave de nuestro próximo desarrollo de software: la duración y la complejidad… Pues existe!

Bienvenido al mundo de los puntos de función, atrevido lector.

Los puntos de función. Nuestros “nuevos” amiguitos.

Los puntos de función (Function Points) fueron definidos en el año 1979 por J.Albretch. Son métricas que se centran en las funcionalidades que debe incluir el producto final, no en su tamaño. Vamos a conocerlos!

Uno de los criterios de diseño iniciales para los puntos de función fue proveer un mecanismo que tanto los usuarios como los desarrolladores pudiesen utilizar para definir los requerimientos funcionales de un sistema.

Se determinó que la mejor manera de comprender las necesidades de los usuarios era enfocar el problema desde la perspectiva de como ellos ven los resultados producidos por el sistema. Por ello, una de las primeras metas del análisis de puntos de función es evaluar las capacidades del sistema desde el punto de vista de un usuario. Para conseguir esa meta, el análisis se basa en analizar las distintas maneras de interactuar que tiene un usuario con el sistema.

Desde la perspectiva de un usuario, cualquier software le ayuda a realizar su trabajo basándose en cinco funciones básicas: dos de ellas se refieren a los requerimientos de datos del usuario final, (Data Funcions) y las otras tres se refieren a la necesidad del usuario de acceder a los datos (Transactional Functions).

Cada uno de los cinco tipos de componentes funcionales tiene una valoración, que se establece en baja, media y alta. Esta valoración se traduce en un valor en puntos para cada componente.

Por tanto, la estimación de proyectos de software mediante el análisis de los puntos de función se basa en transformar los elementos que forman nuestro futuro software (valorando además complejidad)  a puntos, según la valoración que se otorga a cada componente. Vamos a ver más en detalle los cinco elementos que propone J.Albretch.

Data Functions. los datos.

Ficheros lógicos internos (Logical Internal File o LIF): Archivos internos que residen dentro del sistema y que se mantienen mediante el sistema (por ejemplo, mediante una pantalla de mantenimiento). Pueden ser identificados claramente, y que siempre se mantienen dentro de los límites de la aplicación (son internos y propios a ella). Se pueden identificar con las tablas de la base de datos.

Ficheros de interfaces externas (External Interface File o EIF): Grupo de datos interrelacionados y que pueden ser identificados por los usuarios, pero en este caso proceden de fuera de los límites de la aplicación. Ni son mantenidos por el sistema ni creados por él. Un ejemplo puede ser un fichero ASCII que debemos importar a nuestro sistema, o con el que debemos interactuar.

La complejidad funcional de estos dos elementos, se determina a partir de dos conceptos:

Data Element Type (DET): El número de elementos (campos) de un fichero.

Record Element Type (RET): El número de registros elementales diferentes. Este concepto es fácilmente identificable, si pensamos por ejemplo, en una tabla de base de datos que guarda canciones y podcasts (por ejemplo) en una misma tabla, y que mediante un campo [Tipo] los diferencia. Estaríamos hablando de un fichero con un RET de 2 (Canciones y podcasts).

Estos dos conceptos debemos tenerlos en cuenta para cada función de datos que localicemos. Así, la complejidad de las características funcionales sale de una tabla como la que sigue:

	1 a 19 DET	20 a 50 DET	51 DET o más
1 RET	Baja	Baja	Media
2 a 5 RET	Baja	Media	Alta
6 RET o más	Media	Alta	Alta

En función de la complejidad, tenemos esta otra tabla para asignar los valores a aplicar para nuestro cálculo:

	Baja	Media	Alta
LIF	x 7	x 10	x 15
EIF	x 5	x 7	x 10

Esto significa, que si hemos localizado dos ficheros LIF de complejidad baja, su valor es 2 x 7 = 14 Puntos de función sin ajustar.

Transactional Functions. Los procesos.

Vamos a ver ahora los otros tres elementos que deberemos valorar. Estas tres funciones son las siguientes:

Entradas Externas (External Inputs o EI): hacen referencia a los tratamientos que procesan datos o información de control introducidos en la aplicación desde fuera de sus límites. El actor (ojo, no solo usuarios!) introduce datos en el sistema que pueden ser para agregar, modificar o eliminar un archivo o información de control del sistema. Son entradas a la aplicación. Si localizamos un EI, casi seguro que tendremos uno o varios LIF asociados.

Salidas Externas (External Output o EO): cualquier proceso elemental que genere datos o información de control que salta de los límites de la aplicación. Equivale a las salidas que genera la aplicación y pueden utilizar uno o más ficheros LIF o EIF para llevar a cabo su cometido. Ejemplos de uso pueden ser actualizaciones de ficheros o para creaciones de un reports o ficheros. Si tenemos un EO, seguro que tenemos un LIF.

Consultas Externas (External Queries o EQ): es un proceso elemental con procesos de entrada y salida, donde se rescatan datos de uno o más archivos lógicos internos o de interfaz externos. los datos de entrada no actualizan ni mantienen ningún archivo, y los datos de salida no contienen datos calculados. Dentro de este tipo de transacciones encontramos los listados y las búsquedas.

Si os habéis fijado, es sencillo confundir las Salidas Externas (EQ) con las Consultas Externas (EQ). Para ello, podemos aplicar una sencilla regla: las EQ no realizan ninguna operación sobre los ficheros que tengan relacionados y no ofrecen datos calculados.

Para determinar la complejidad de las transacciones, debemos tener en cuenta los siguientes conceptos:

Data Element Type (DET): conocemos este concepto, ya que es lo mismo que en las funciones de datos: se corresponde con los campos que tiene el fichero afectado.

File Type Referenced (FTR): número de archivos lógicos internos (LIF) o archivos de interfaz externa (EIF) que utilizamos en la transacción objeto de nuestra valoración.

Y ahora que ya tenemos todos los elementos, veamos nuestras tablas de complejidad:

Esta es válida para las Entradas Externas (EI):

	1-4 DET	5-15 DET	+15 DET
0-1 FTR	Baja	Baja	Media
2 FTR	Baja	Media	Alta
3 o +3 FTR	Media	Alta	Alta

Esta otra, para las Salidas Externas (EO) y para las Consultas Externas (EQ):

	1-4 DET	6-19 DET	+19 DET
0-1 FTR	Baja	Baja	Media
2-3 FTR	Baja	Media	Alta
+3 FTR	Media	Alta	Alta

Y esta última la utilizaremos para asignar un valor a nuestros elementos en función de la complejidad obtenida:

	Salidas Externas (EO)	Consultas Externas (EQ)	Entradas Externas (EI)
Baja	x 4	x 3	x 3
Media	x 5	x 4	x 4
Alta	x 7	x 6	x 6

Igual que antes, si tenemos por ejemplo una Salida Externa (EO) que utiliza dos ficheros (tiene un FTR de 2) y que tiene 10 campos (10DET) estableceríamos su complejidad como Baja, estableciendo su valor en puntos de función en 1 x 5 =  5.

Aún hay más: factores de ajuste

Hemos visto los elementos principales a tener en cuenta para realizar una estimación de la carga de un proyecto de software mediante los puntos de función.

Si realizamos el análisis de un aplicativo teniendo en cuenta sólo los cinco elementos que hemos presentado, obtendremos los denominados puntos de función sin ajustar (Unadjusted Function Points). Es el primer paso para tener una valoración en puntos de función definitiva.

El señor J.Albretch ya pensó que las características funcionales indicadas no agotaban todas las posibilidades de definir funcionalmente un software de aplicación. Debido a eso, añadió que se debían tener en cuenta las características generales del sistema.

Albretch propone catorce características funcionales, que se evalúan de 1 a 5 de la siguiente manera:

0 – No presente o sin influencia
1 – Influencia incidental
2 – Influencia moderada
3 – Influencia media
4 – Influencia significativa
5 – Fuerte influencia

Las catorce características propuestas son:

Característica	Descripción
Comunicación de datos	¿Cuantas facilidades de comunicación hay disponibles para ayudar con el intercambio de información con la aplicación o el sistema?
Procesamiento distribuido de los datos	¿Cómo se manejan los datos y las funciones de procesamiento distribuido?
Rendimiento	¿Existen requerimientos de velocidad o tiempo de respuesta?
Configuraciones fuertemente utilizadas	¿Que tan intensivamente se utiliza la plataforma de hardware donde se ejecutará la aplicación o el sistema?
Frecuencia de las transacciones	¿Con qué frecuencia se ejecutan las transacciones? diarias, semanales, mensuales…
Entrada de datos On-line	¿Qué porcentaje de la información se ingresa on-line?
Eficiencia del usuario final	¿se designa la aplicación para maximizar la eficiencia del usuario final?
Actualizaciones on-line	¿Cuantos archivos lógicos internos se actualizan por una transacción on-line?
Procesamiento complejo	¿Hay procesamientos lógicos o matemáticos intensos en la aplicación?
Reusabilidad	La aplicación se desarrolla para suplir una o muchas de las necesidades de los usuarios
Facilidad de instalación	¿Es muy difícil la instalación y la conversión al nuevo sistema?
Facilidad de operación	¿cómo de efectivos y automatizados son los procedimientos de arranque, parada, backup y restore del sistema?
Instalación en distintos lugares	¿La aplicación fue concebida para su instalación en múltiples sitios y organizaciones?
Facilidad de cambio	La aplicación fue concebida para facilitar los cambios sobre la misma

Si desconocemos alguna de estas características cuando estemos realizando nuestro análisis, podemos utilizar un valor medio (2,5) para su valoración.

La suma de la valoración de todas las características generales de nuestro sistema, arroja una cantidad, que se denomina grado total de influencia (Total degree of influence). Con ese grado y mediante la siguiente fórmula:

PCA = 0,65 + (0,01 * TDI)

Obtendremos el ajuste por la complejidad del proceso (PCA, Processing Complexity Adjustment).

Pues muy bonito! y después de esto… ¿Qué?

Pues bien, ya tenemos todos los elementos necesarios! por un lado, hemos realizado el cálculo de cada una de las funcionalidades de nuestro sistema, con lo que ya tenemos el total de puntos de función sin ajustar (TUFP, Total unadjusted function points) de nuestro sistema.

Por otro, hemos evaluado las características funcionales de nuestros sistema, y hemos valorado su incidencia sobre el mismo, obteniendo el grado total de influencia. Gracias a ese grado total de influencia, podemos calcular los puntos de función de nuestro sistema, con la fórmula:

FP = TUFP * PCA

Lo hemos conseguido! tenemos la valoración de nuestro proyecto de software en puntos de función! Ahora sólo tenemos que pasar los puntos de función a horas, para poder calcular costes, valoración para el cliente y poder planificar nuestro proyecto.

Lo ideal es contar con una base estadística y datos de productividad propios, que pueden haber sido obtenidos en proyectos anteriores del mismo tipo, y con equipos de desarrollo de características similares.

Ojala lo tuviésemos todo!! todo llegará, pero mientras llega, tened en cuenta que una productividad de 2 o 3 horas por punto de función es lo habitual.

Por este motivo (y muchos otros), es tan importante disponer de la documentación de gestión y de los datos de productividad de proyectos informáticos anteriores.

Concluyendo, que es gerundio

Siempre he sentido cierta obsesión por obtener una valoración de los proyectos de software en los que he participado lo más cercana a la realidad. Si habéis visto el enlace que hay al principio del post, en la mayoría de las ocasiones es casi una labor de brujería y adivinación.

Los motivos son muy diversos, aunque principalmente me encuentro con que los usuarios a los que va dirigido el software o bien los responsables de solicitarlo no nos dan unas especificaciones todo lo formales que nos gustaría, bien por falta de tiempo, por desconocimiento de los procesos a mecanizar o por el entorno cambiante en el que nos toca desarrollar. En otras ocasiones somos nosotros, los que en un alarde de optimismo pensamos que somos capaces de multiplicar los panes, los peces, los teclados, las líneas de código… y a veces hasta a nosotros mismos!!

Esto no es ni bueno ni malo, simplemente es una realidad con la que tenemos que lidiar, lo mejor que podemos y sobre todo con todo el rigor del que seamos capaces.

Desde luego, contar con un método establecido y estándar para realizar estimaciones ya es un gran paso. La mayoría de nosotros hemos realizado valoraciones basándonos en nuestra propia experiencia, y en la experiencia que hemos tenido en los proyectos que hemos realizado. Esto implica de manera directa que, en una misma empresa, dependiendo de quien valore un proyecto tendremos desviaciones más o menos notables.

Y digo yo, ¿pero no es el mismo software? ¿no debe cumplir las mismas especificaciones? ¿que demonios pasa aquí!!?

Pues pasa que las metodologías “in house” (nombre bonito donde los haya), o el “mira Mariano, a ver por donde sopla el viento” es lo que tienen, y que si deseamos profesionalizarnos, debemos huir de ellas y tender a adoptar en la medida en la que podamos metodologías estándar, testeadas y de probada capacidad.

La valoración y estimación de un proyecto de software es una parte vital dentro del ciclo de vida del desarrollo de software, y puede significar la diferencia entre el éxito y el infierno del fracaso, las horas extra, los clientes cabreados y los programadores frustrados.

No se a vosotros, pero a mi los infiernos no me motivan (salvo que sea el nombre de un bar).

Por otro lado, una vez que el proyecto comienza, no hay marcha atrás, y sólo nos queda realizar un correcto seguimiento del mismo. Hay que prepararse para el cambio.

Un seguimiento efectivo nos permitirá efectuar controles regulares y medir las desviaciones entre la realidad y aquello que se ha planificado anteriormente. con estos datos, debe reelaborarse tanto la estimación (a partir de los datos reales de productividad que se toman del equipo humano que interviene en el proyecto) como la planificación (por los cambios en la estimación del esfuerzo necesario, y también por los posibles desajustes en la disponibilidad de los recursos).

Hay que tener muy en cuenta que cualquier estimación de cargas, riesgos y costes para el desarrollo de software, es una conjetura, y por tanto posiblemente sea falsa. Las estimaciones y planificaciones deben revisarse, y cuando convenga, corregirse.

Casi ná… vamos con pies de barro, montando software por el mundo! y encima nos encanta! Definitivamente, estamos fatal.

Si habéis aguantado, Muchas gracias! Creo firmemente que la aplicación del análisis y estimaciones mediante puntos de función puede reportar sin ninguna duda, más beneficios que cualquier otra metodología “casera”.

Sin embargo, adolece de lo mismo que casi todas: si no tenemos unas buenas especificaciones, vamos dados. Nuestra labor fundamental en esta fase es hacer todo lo posible por obtenerlas!

Espero que os haya resultado interesante, y que os haya abierto una vía más para clarificar una tarea ya de por sí complicada, como puede ser la valoración de software.

Para el próximo post, un ejemplo de todo lo expuesto aquí.

Un cordial saludo!