Estimación Basada en Puntos de Función y Soluciones Híbridas (página 2)

Sus objetivos son:

• Medir lo que el usuario pide y lo que el usuario recibe.
• Medir independientemente de la tecnología utilizada en la implantación del sistema.
• Proporcionar una métrica del tamaño.
• Proporcionar un medio para la estimación del software.
• Proporcionar un factor de normalización para la comparación de distintos software.

Una vez presentado el método, su autor realizó mejoras sobre el modelo inicial y ha publicado diferentes versiones del mismo. En 1986, Allan Albrecht funda el Grupo Internacional de Usuarios de Puntos de Función (en inglés International Function Point User Group – IFPUG). Esta organización se encarga de la difusión del método y de la publicación de manuales de uso y documentos de cómo sacar provecho del mismo.

Los Puntos de Función fueron diseñados originariamente para ser aplicados a sistemas de información de gestión, es por ello que se puso énfasis en la dimensión de datos, excluyendo las dimensiones funcionales y de control. Su aplicación no era del todo adecuada para sistemas de ingeniería y embebidos, pero con el correr del tiempo, se fueron subsanando estos inconvenientes. Aún así, han surgido algunas variantes, entre las que se pueden contar:

Feature Points (Puntos de Características): este método fue propuesto por Caper Jones [Jones, 1987] como una alternativa que permitiera obtener puntos de función en software científico y de ingeniería. Para evitar confusiones con los Puntos de Función, Jones lo denominó puntos de característica (en inglés feature points). Actualmente es usado con mucho éxito en software del tipo CAD (del inglés Computer Aided Design), sistemas embebidos y sistemas en tiempo real.

MK II FPA: propuesto por Charles R. Symons [Symons, 1998], este método es una derivación de los Puntos de Función de Albrecht, el que considera al sistema que se está analizando, compuesto por cinco tipos de componentes (entradas externas, salidas externas, consultas externas, grupos de datos lógicos internos y externos), mientras que el MK II FPA mira al sistema como una colección de transacciones lógicas discretas, compuestas cada una de ellas por entrada, proceso y salida. Si se usan herramientas modernas de diseño para el desarrollo del software, y esas herramientas permiten identificar fácilmente las transacciones lógicas, resulta apropiado el uso de este método.

3-D Function Point: entre los años 1989 y 1992, Scott Whitmire [Whitmire, 1992] desarrolló un método para la empresa internacional de aeronavegación Boing. El objetivo fue ampliar su espectro a sistemas con elevada complejidad como los sistemas en tiempo real. El término 3D, se refiere a que considera tres dimensiones en las que puede proyectarse un sistema software; ellas son: datos, funciones y control. Visto de esta forma, resulta atractivo el uso del método, para aquel tipo de software, pero presenta el inconveniente de la necesidad de disponer de mayor cantidad de información acerca del sistema, sobre todo de la complejidad de los algoritmos a implementarse; esta información no siempre está disponible en las primeras etapas del desarrollo.

Full Function Points (Puntos de Función Completos): esta técnica ha sido desarrollada por un equipo de la Universidad de Québec en Montreal (Canadá) [Abran A., et al., 1998], siendo muy eficiente en la medición de puntos de función en sistemas de control, tiempo real y embebido. Particularmente, los sistemas en tiempo real presentan dos factores críticos: primero, el tiempo de respuesta y en segundo lugar, su interacción con entidades externas. Los puntos de función de Albrecht tienen limitaciones para medir sistemas software en tiempo real. Estos últimos trabajan con dos tipos de estructura de datos de control: grupo lógico de ocurrencia múltiple, que puede tener más de una instancia por cada tipo de registro y el grupo lógico de ocurrencia única, que puede tener solamente una instancia por cada tipo de registro. En lo que respecta a las transacciones, los sistemas en tiempo real, presentan una variación importante en la cantidad de subprocesos por proceso; es decir, el método debería contemplar que unos procesos contarían con unos pocos subprocesos y otros en cambio, con un número significativo de ellos. Los puntos de función se basan más en el número de procesos que en el de subprocesos. Para paliar este inconveniente, Full Function Points introduce en el cálculo no solamente a los procesos, sino que también incluye a los subprocesos.

COSMIC FFP: a finales de 1998, un grupo de expertos en métricas de software, establecieron el Common Software Measurement International Consortium (COSMIC FFP). La iniciativa de COSMIC, ha sido básicamente la de dar respuesta a proveedores y a clientes de servicios de desarrollo de software, principalmente en aquellos contratos de terceros donde no había reglas claras acerca del valor de este tipo de servicio. En tal sentido COSMIC apunta a satisfacer tanto a proveedores de software que deben traducir los requerimientos del cliente en un tamaño del software como un paso clave en la estimación de los costos del proyecto, como a los clientes que quieren conocer ese tamaño recibido como un componente importante para la medición del rendimiento del proveedor. El método se puede aplicar a dominios de software de gestión, tiempo real e híbridos.

Fig 1. Evolución de los métodos de estimación basados en FP

Existen herramientas automáticas de estimación que implementan técnicas de descomposición o modelos empíricos y están provistas de entornos gráficos, interfaz interactiva y uso estandarizado que hacen de ellas una buena opción. Además permiten describir características de la organización (experiencia, entorno, etc.) y el software a desarrollar para que a partir de estos datos, sea posible obtener estimaciones de costo, tiempo y esfuerzo. Algunas herramientas se muestran en la tabla 1:

Tabla 1. Ejemplos de herramientas automáticas de estimación

La técnica de medición del tamaño en punto-función consiste en asignar una cantidad de "puntos" a una aplicación informática según la complejidad de los datos que maneja y de los procesos que realiza sobre ellos, siempre tratando de considerarlo desde el punto de vista del usuario.

Los puntos de función se calculan completando la tabla de la Figura 3. Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de los dominios de información se definen de la forma siguiente:

Número de entradas de usuario. Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan de forma separada.

Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada.

Número de peticiones de usuario. Una petición se define como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada petición por separado.

Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un archivo independiente).

Número de interfaces externas. Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de complejidad. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. No obstante la determinación de la complejidad es algo subjetiva.

Fig 3. Cálculo de puntos de función.

Para calcular puntos de función, se utiliza la relación siguiente:

FP = cuenta-total x [ 0,65 + 0,01 x Σ (Fi ) ] (1)

Donde cuenta-total es la suma de todas las entradas obtenidas de la figura 3. Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las respuestas a las siguientes preguntas:

1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?

2. ¿Se requiere comunicación de datos?

3. ¿Existen funciones de procesamiento distribuido?

4. ¿Es crítico el rendimiento?

5. ¿Se ejecutaría el sistema en un entorno operativo existente y fuertemente utilizado?

6. ¿Requiere el sistema entrada de datos interactiva?

7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones?

8. ¿Se actualizan los archivos maestros de forma interactiva?

9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?

10. ¿Es complejo el procesamiento interno?

11. ¿Se ha diseñado el código para ser reutilizable?

12. ¿Están incluidas en el diseño la conversi6n y la instalaci6n?

13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?

14. ¿Se ha diseñado la aplicaci6n para facilitar los cambios y para ser fácilmente utilizada por el usuario?

Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial).

Los valores constantes de la ecuación (1) y los factores de peso que se aplican a las cuentas de los dominios de información se determinan empíricamente. Una vez que se han calculado los puntos de función, se utilizan de forma análoga a las líneas de código como forma de normalizar las medidas de productividad, calidad y otros atributos del software.

Una vez calculado los puntos de función se usan de forma analógica a las líneas de código como medida de la productividad, calidad y otros productos del software.

Productividad = PF / persona-mes

Calidad = Errores / PF

Costo = Dólares / PF

Documentación = Pags. Doc / PF

El proceso de cálculo y obtención de puntos de función y su posible transformación a líneas de código se esquematiza en la figura:

Fig. 2 Proceso de cálculo de puntos de función y transformación a líneas de código

Hay muchos usos de los puntos función más allá de los programas de estimación, esfuerzo y costo. Entre ellos tenemos:

• El uso de puntos función para estimar casos de prueba.
• El uso de puntos función para ayudar a entender rangos de productividad amplios.
• El uso de puntos función para ayudar a entender el crecimiento de Proyectos.
• El uso de puntos función para ayudar a calcular el costo real del software.
• El uso de puntos función para ayudar a estimar el costo de proyectos, la programación y el esfuerzo.
• El uso de puntos función para ayudar a entender los costos de mantenimiento.
• El uso de puntos función para ayudar con las negociaciones de contrato.
• El uso de puntos función para desarrollar un estándar de establecimiento de métricas.

El uso de puntos función para estimar casos de prueba

Muchos intentos se han realizado para tratar de establecer una relación entre puntos función 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 función y el ciclo de vida completo del software son examinados. Esta sección examina la relación entre puntos función y las pruebas — en particular la relación entre los casos de prueba y los puntos función. La relación entre puntos función 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 función elevado a la potencia 1.2 (FP 1.2). Esto es, los casos de prueba crecen en una proporción mayor que los puntos función. 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 función, 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.

 El uso de puntos función 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 función).

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 función correctamente y capturado los tiempos consistentemente. Las organizaciones 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. Los cambios bruscos en las medidas de productividad entre proyectos son una indicación de 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 función para ayudar a entender el crecimiento de proyectos

El análisis de puntos función provee un mecanismo para monitorizar el crecimiento de proyectos. El conteo de puntos función al final de las fases de obtención de requisitos, análisis, diseño e implementación se pueden comparar. El conteo de puntos función al final de los requisitos y/o diseño se puede comparar a los puntos función al final del proyecto. Si el número de puntos función 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 la exactitud con que los requisitos fueron recogidos y/o comunicados al equipo del proyecto. El crecimiento de todos los proyectos debe ser monitorizado. 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 función 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. Cuanto más se invierta en un buen diseño, más se va a ahorrar 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 función para ayudar a estimar el costo de proyectos, la programación y el esfuerzo

La estimación exitosa usando puntos función 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 función.

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 función) de proyectos similares
• Programas históricos (duración de programas por punto función) de proyectos similares
• Costos históricos (dólares por punto función)

Una vez que el tamaño del proyecto se ha determinado en puntos función, 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 función y la medida de entrega de un proyecto similar es $10 por punto función, entonces el costo total esperado para el proyecto sería $10 ($/punto función)  x 500 PF’s = $5,000 dólares. Pueden hacerse cálculos similares  para programas, duración y horas.

El uso de puntos función para ayudar a entender los costos de mantenimiento

Muchos presupuestos de mantenimiento se establecen 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 función, el crecimiento de los costos de mantenimiento en realidad disminuye. Por ejemplo, si una organización gasta $100,000 para mantener 10,000 puntos función o $10 por punto función, pero el número de puntos función crece 10% a 11,000 y los dólares de mantenimiento permanecen constantes, entonces los costos de mantenimiento por punto función disminuye a $9. Muchos ejecutivos de sistemas no entienden ni asimilan este concepto.

El uso de puntos función para ayudar con las negociaciones de contrato

Los administradores de contratos pueden usar su conocimiento en puntos función para construir y manejar proyectos basados en el precio por punto función 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 función y pueden evaluar el impacto de proyectos cancelados.

Los puntos función 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 de la representación precisa del esfuerzo. La estimación de este esfuerzo (en el ciclo de vida completo) puede ocurrir sólo cuando una métrica normalizada, tal como la provista por los puntos función, se aplica.

Resumiendo, el análisis de puntos función 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 función). Segundo, el desarrollador puede más fácilmente aceptar los riesgos para el costo de producción (el costo por punto función). Adherirse a un conteo consistente de puntos función 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 función, se puede incorporar a los algoritmos de costeo usados para determinar los precios externos. Sin un entendimiento claro del tiempo y esfuerzo por punto función, la asignación de precios a los paquetes de software continuará siendo difícil.

El uso de puntos función para desarrollar un estándar de establecimiento de métricas

Por supuesto, los puntos función necesitan usarse en asociación con las otras medidas. De hecho, los puntos función por sí mismos proveen poco o nada de beneficio. Muchas métricas necesitan ser reportadas al nivel organizativo. Por ejemplo, tanto la métrica de productividad/costo como la métrica de calidad necesitan ser reportadas al nivel organizativo. 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 monitorizar los esfuerzos continuos de mejoramiento en el proceso de desarrollo del software. Estas métricas deben ser monitorizadas y estudiadas en sus tendencias.

Resultados de una Experiencia en la Determinación del Tamaño de un Software.

La experiencia se desarrolló dentro de la asignatura Gestión de Proyectos de Ingeniería de Software, un electivo de quinto año de la carrera de Ingeniería Informática en la Universidad de Concepción. Esta experiencia consistió en un simulacro de llamado a licitación para el desarrollo de un producto software para una organización ficticia. La experiencia se realizó sobre la base de una especificación de requisitos considerada buena (no ambigua y bastante completa).

Una de las tareas que los alumnos debieron ejecutar para responder a este llamado, fue determinar el tamaño del producto, estimar costos y plazos. La mayoría de ellos escogió la métrica puntos de función por sobre otras (puntos de característica, líneas de código) por las ventajas que esta métrica tiene. Todos los alumnos manejaban la técnica de conteo de puntos de función, y utilizaron el mismo método (guía) para realizar el conteo. Todos los alumnos debieron entregar el detalle de las tareas desarrolladas como anexo a la propuesta, por lo que se pudo verificar la correcta aplicación del método para el caso de la estimación del tamaño del software a desarrollar. A continuación, se presentan los resultados obtenidos en la experiencia descrita anteriormente y una hipótesis explicativa de los resultados.

Para presentar una respuesta a un llamado a licitación, 13 alumnos de quinto año debieron determinar una buena estimación del tamaño del producto a desarrollar, eligiendo 10 de ellos la métrica puntos de función.

Los resultados obtenidos se muestran en la tabla y gráficos siguientes. En ellos se muestra la medida en puntos de función obtenida por cada alumno, en un rango de 181 a 759.

La desviación estándar de estos datos es de aproximadamente 211 PF (Puntos de Función) sobre el promedio, lo que es sin duda muy alto. Esta gran diferencia condujo a estimaciones de esfuerzo y plazos drásticamente distintas. Esto influyó directamente en la cantidad de personal que cada alumno asignó al proyecto y a la organización del mismo (provocando impacto también en la función de staffing), además de la influencia directa en los costos y plazos. Durante el desarrollo del proyecto, las diferencias en estas estimaciones provocarían grandes diferencias también en la dirección, por lo que estaría efectivamente afectando al proyecto en su conjunto, y por lo tanto al éxito o fracaso del mismo.

Algo interesante e inesperado resultó este cálculo dispar entre candidatos a ingenieros civiles informáticos sobre la base de una misma especificación de requisitos y un mismo método de cálculo de puntos de función.

La asignación de complejidad que el método exige para cada ítem (entrada, salida, consulta, archivo lógico, archivo de interfaz), es un tanto subjetiva y normalmente difiere de un desarrollador a otro, pero esto no explicaría una desviación de tal magnitud (211 puntos de función).

La causa de estas diferencias de tamaño estimado está en el entendimiento de qué constituye efectivamente una salida externa, una entrada externa, un archivo lógico interno y una consulta.

La especificación del software que fue objeto de medición, está organizada por tipo de información. Los reportes y consultas están claramente especificados, mediante un diseño de formularios, pero no así las entradas. Sólo se especifican los datos que se deben ingresar.

De lo anterior, se puede deducir que el número de salidas y consultas estaba más bien claro, y que la causa de las grandes diferencias estuvo en las entradas y archivos lógicos internos.

Para el caso de las entradas, dado que no se especificaba cuál conjunto de datos sería ingresado simultáneamente, algunos alumnos los agruparon según su criterio, obteniendo un número de entradas cercano al número de consultas y salidas, pero otros consideraron que cada dato a ingresar constituía una entrada, por lo que el número de entradas aumentó en gran medida. A pesar de que la complejidad de las entradas que involucran a más de un dato es mayor que la de una entrada de un solo dato, esto no alcanzó a corregir la diferencia entre las medidas.

Para el caso de los archivos lógicos internos, algunos alumnos agruparon grandes conjuntos de información en un archivo lógico interno, mientras que otros modelaron la información en un esquema entidad relación, obteniendo una aproximación mucho más cercana a la cantidad de tablas que efectivamente implementarían. Evidentemente, el número de archivos lógicos internos fue mucho mayor en el segundo caso.

Otro factor de dificultad para realizar el cálculo del tamaño del software fue la existencia del requisito "se debe posibilitar la capacidad de realizar consultas no estructuradas". Este requisito fue tratado de maneras disímiles: fue dejado fuera, considerado al equivalente de 15 o más consultas complejas, o se decidió que se utilizaría una interfaz a alguna herramienta que proveyera dicha funcionalidad. Este punto también provocó diferencias.

Otro factor importante, que se da también en los casos reales (esta experiencia fue académica), fue la presión a la que estaban sujetos los participantes. Debían entregar una propuesta de calidad dentro de los plazos, o su castigo sería equivalente a no ganarse el proyecto: una baja calificación, o peor aún, reprobar la asignatura. Por otro lado, al tener el conocimiento de que el ganador del proyecto no tendría que desarrollarlo, podían arriesgarse a hacer ofrecimientos interesantes y convenientes, pues no ponían en juego su prestigio. Este es un riesgo que normalmente no debieran correr las empresas proveedoras de servicios de desarrollo de software serias, las que debieran hacer estimaciones más bien conservadoras.

Combinación de las alternativas para la estimación de Proyectos de Software.

Cocomo y la técnica de estimación de puntos de función

El método Cocomo permite determinar los valores de las siguientes dos variables:

• Meses/hombre a aplicar al proyecto

• Meses totales del proyecto (dependiendo de factores tales como los atributos de fiabilidad requerida del software, tamaño de la base de datos, complejidad del producto, limitaciones en el tiempo de ejecución, limitaciones de memoria principal, volatilidad de la máquina virtual, frecuencia de cambio en el modelo de explotación del ordenador, capacitación de los analistas, experiencia en aplicaciones, capacitación de los programadores, experiencia en la máquina virtual, experiencia en el lenguaje de programación, prácticas modernas de programación, uso de herramientas para el desarrollo del software y limitaciones en la planificación).

Esta técnica requiere de un dato elemental determinado por la cantidad de sentencias de código del proyecto a la que posteriormente se aplican diferentes algoritmos que varían de acuerdo al modelo de desarrollo elegido (Orgánico, Semilibre o Libre) para entallarlo finalmente de acuerdo a factores de ajuste seleccionados a partir de las características específicas del proyecto.

Esta información se convierte en el aspecto crítico del método ya que ese valor es un parámetro difícil de determinar con exactitud y puede variar considerablemente según las metodologías de desarrollo utilizadas. El camino para resolver este aspecto crítico es mediante la aplicación de otra técnica, la de Puntos de Función.

Figura 4: Estimación de Proyectos por el método de Puntos de Función

En opinión de varios autores el método de Puntos de Función presenta un aspecto crítico en lo referido a la reutilización de módulos preexistentes (por ejemplo varias salidas similares que poseen una misma estructura con variaciones propias de cada una de ellas). En este caso el método las considera a todas diferentes y se miden de la forma descrita anteriormente con lo que se considera que la cantidad de puntos de función daría una cifra superior a la real deformando el número final con la consabida incidencia (número de sentencias de código del software) en la aplicación del método Cocomo.

En resumen, la utilización combinada de dos métodos (Puntos de Función y Cocomo) tienden a proporcionar una estimación más precisa tratándolos de la siguiente forma:

Primero la aplicación del método de Puntos de Función para determinar las sentencias de código del proyecto software, la cual mantiene una distorsión, producida por no considerar esta técnica la reutilización de módulos preexistentes.

En segundo lugar la aplicación del método Cocomo partiendo de la información producida por el anterior (sentencias de código) para llegar a una estimación precisa de las horas hombre a aplicar y fundamentalmente a la estimación de la duración total del proyecto.

Finalmente y basándonos en que el paradigma de objetos considera la reusabilidad como un factor básico y entendiendo que el método descripto (Puntos de Función) pareciera no tomar en cuenta estas características, queda planteado a partir del presente trabajo, una línea de investigación tendiente a analizar la incidencia de las metodologías orientadas a objetos en esta técnica de estimación a fin de elaborar los factores de ajuste necesarios para reducir la distorsión provocada.

Los casos de uso y la técnica de estimación de puntos de función

Los casos de uso fueron introducidos en 1987 como una herramienta de la técnica Objetory. Su utilización en los procesos de Ingeniería de Software fue propuesta por Ivar Jacobson y publicada en su libro Object Oriented Software Engineering. Actualmente, su empleo se ha extendido aún más, debido a su inclusión en UML, por lo que su uso en el desarrollo de software orientado a objetos se ha vuelto altamente recomendable, y obligatorio. David Longstreet, en uno de sus artículos, señala que el análisis de puntos de función se puede aplicar de manera sencilla con los casos de uso mejorando la calidad de los documentos de requerimientos y, a la vez, mejorando la estimación del proyecto de software. El aplicar la técnica de puntos de función permite verificar y validar el contenido de un documento de especificación de Requisitos de software. Lo interesante de la aplicación de ambas técnicas es que se puede actualizar el conteo de los puntos de función cada vez que los casos de uso cambien y, de esta manera, determinar el impacto que un caso de uso específico puede producir en la estimación del desarrollo de todo el proyecto.

Conclusiones

Puede concluirse, entonces, que el tiempo total de duración de un proyecto está relacionado con las características propias del mismo y no depende directamente del lenguaje de implementación del diseño como así tampoco de la cantidad de personal a utilizar, sino que esta última es una consecuencia directa de los dos valores estimados por el método.

Para realizar la planificación de un proyecto software, es necesario poseer una estimación certera del esfuerzo necesario para el desarrollo lo más temprano posible, idealmente, con sólo la etapa de especificación de requisitos cubierta. De más está decir que sin la especificación de requisitos cualquier estimación será en la más completa incertidumbre, pues cómo estimar el costo de realizar algo que desconocemos? A esta altura del desarrollo del software, difícilmente se puede realizar una estimación certera de la cantidad de líneas de código que tendrá la aplicación, ya que en este nivel no tiene por qué estar decidida la herramienta de desarrollo y la cantidad de líneas de código que serán necesarias para implementar una función del software dependen fuertemente del programador y la herramienta de desarrollo.

Por otra parte, los puntos de función pueden ser estimados con mayor certeza a partir de una buena especificación de requisitos (aunque no con toda la certeza deseada). Lamentablemente, cuando los proyectos se plantean sobre la base de especificaciones vagas o inexistentes, es muy poco lo que se puede hacer. La técnica de estimación de proyectos Puntos de Función es muy útil pero se deben tener en cuenta varios aspectos antes de ponerla en práctica con el objetivo de lograr un resultado lo más cercano posible a la realidad.

El Punto Función es una medida del tamaño de un sistema de software y del proyecto que lo construye. Es una unidad de medida así como la hora lo es para medir el tiempo o el kilómetro para medir la distancia. El Análisis de Punto Función se basa en la teoría de que las funciones de una aplicación son la mejor medida del tamaño de un sistema. El Punto Función mide el software mediante la cuantificación de la funcionalidad que el sistema le brinda al usuario basado fundamentalmente en el diseño lógico. Es independiente del lenguaje de computación, de la metodología de desarrollo, de la tecnología utilizada y de la capacidad del equipo de trabajo para desarrollar la aplicación.

El Análisis del Punto Función es un método estándar de medición de desarrollo de software desde el punto de vista del usuario. La cuenta de Punto Función para proyectos de desarrollo mide las funcionalidades que se le proporcionan al usuario conjuntamente con la primera instalación del software producido cuando el proyecto es terminado.

El método de cálculo por puntos de función es subjetivo y puede arrojar resultados diversos dependiendo de quién ejecute el método. Para realizar el cálculo de los puntos de función debe existir un consenso dentro de la organización para el tratamiento de los requisitos que no se ajustan al método, además de realizar un pre diseño para que este tamaño sea una buena estimación del tamaño real de la aplicación. Por otra parte, se deben manejar aspectos como la re estimación del tamaño cada vez que se va teniendo mayor conocimiento del producto, esto es, una vez que se va avanzando dentro del desarrollo.

Requiere una dedicación adicional en los proyectos de desarrollo de software, que suelen desenvolverse con presupuestos ajustados. Su implantación en una organización no acostumbrada a su uso suele resultar penosa y requerir un fuerte compromiso de la dirección. Suele ser vista por los desarrolladores como un mecanismo de control de su trabajo.

Otros aspectos negativos serían:

• Resulta arduo formar al personal en su utilización y más todavía mantener unos criterios homogéneos de recuento.
• Carece de precisión cuando se trata de proyectos pequeños. Por debajo de unos 100 pf resulta demasiado poco fiable.
• Para resultar realmente útil, una organización de desarrollo y mantenimiento de software debe tener recontada la mayor parte de su base instalada, pero hacerlo resulta muy costoso especialmente si mantiene software adquirido a terceros.
• El factor de ajuste calculado a partir de las características generales del sistema resulta de dudosa utilidad.

Si bien el mismo es criticado por no ser aplicable a todos los sistemas, el tamaño de la gran mayoría de los sistemas del mercado puede ser estimado utilizando esta técnica. En general, la mayoría de las soluciones alternativas que se proponen se basan en esta técnica de Albrecht, modificando ligeramente algunos aspectos o incorporándole algún nuevo elemento a estos cinco identificados.

Bibliografía

[Albrecht, 1979] Albrecht, Allan J. 1979. Measuring Aplication Development Productivity. Proc Of IBM applications. Development Joint SHARE/GUIDE Symposium, Monterrey, Páginas 83-92.

[Jones, 1987]. Jones, C. 1987. A Short History of Function Points and Feature Points. Software Productivity Research Inc. USA.

[Symons, 1998]. Symons, Charles R. 1998. Function Point Analysis Difficulties and

Improvements. IEEE Transactions on Software Engineering. Páginas 2-11.

[Whitmire, 1992]. Whitmire, Scott A. 1992. 3D Function Points: Scientific and Real-Time Extensions to Function Points. Pacific Nothwest Software Quality Conference.

[Abran A., et al., 1998]. Abran, A.; Desharnais J. M.; Maya M.; St-Pierre D.; Bourque P. 1998. Design of a Functional size Measurement for Real-Time Software. Research Report N° 13.Software Engineering Management Research Laboratory, Universite du Québec a Montreal, Canada.

[Pressman, 1998]. Pressman, Roger S 1998. Ingeniería del Software. Un Enfoque Práctico. Cuarta Edición. 581 páginas. Editorial Mc Graw-Hill. ISBN 84-481-1186-9.

Pressman R.S, Ingeniería del Software. Un enfoque práctico. Mc Grow Hill. 1994

Symons, Charles R. 1998. Function Point Análisis Difficulties and Improvements. IEEE Transactions on Software Engineering.

International Function Point users Group. Function Point Counting Practices Manual. Release 4.0. 1994.

Sobre los Autores:

Elsydania López Guerra. Estudiante de cuarto año de Universidad de las Ciencias Informáticas. Ciudad de la Habana, Cuba.

Yulia Fustiel Alvarez. Estudiante de cuarto año de Universidad de las Ciencias Informáticas. Ciudad de la Habana, Cuba.

Abdiel Matos Nieto. Estudiante de cuarto año de Universidad de las Ciencias Informáticas. Ciudad de la Habana, Cuba.

Abdel Pérez López. Estudiante de cuarto año de Universidad de las Ciencias Informáticas. Ciudad de la Habana, Cuba.

Cuba, Ciudad de la Habana, diciembre de 2007.

Elsydania Lopez Guerra