1. 2. 3. 4. 5. 6. 7.

Resumen Desarrollo El uso de puntos funcin para estimar casos de prueba El uso de puntos funcin para ayudar a entender rangos de productividad amplios El uso de puntos funcin para ayudar a entender el crecimiento de proyectos El uso de puntos funcin para ayudar a calcular el costo real del software El uso de puntos funcin para ayudar a estimar el costo de proyectos, la programacin y el esfuerzo 8. El uso de puntos funcin para ayudar a entender los costos de mantenimiento 9. El uso de puntos funcin para ayudar con las negociaciones de contrato 10. El uso de puntos funcin para desarrollar un estndar de establecimiento de mtricas 11. Resultados de una Experiencia en la Determinacin del Tamao de un Software 12. Combinacin de las alternativas para la estimacin de Proyectos de Software 13. 14. Bibliografa

Resumen
En el presente artculo se aborda el tema de la estimacin de Proyectos Informticos, especficamente se analiza el mtodo de Puntos de Funcin, adems de su combinacin con otras tcnicas de estimacin como Cocomo y Casos de Uso. La estimacin es una de las primeras actividades de la gestin de proyectos informticos. Su objetivo es conocer en etapas tempranas y de manera aproximada, el costo, la duracin y los recursos necesarios para el desarrollo de proyectos de software.

Desarrollo
El tamao del software podra medirse en trminos de los bytes que ocupa en el disco, el nmero de programas, el nmero de lneas de cdigo, la funcionalidad que proporciona, o simplemente el nmero de pantallas o reportes que tiene. A simple vista podramos intuir que algunas de estas propuestas son mejores que otras si queremos medir el tamao de una forma que tenga ms correlacin con el esfuerzo. Pero antes de seleccionar alguna, hagamos otras consideraciones. Una aplicacin de software es un conjunto de lneas de cdigo que se ejecutan en una computadora. Sin embargo mucho del costo de producir ese software no est directamente relacionado con la codificacin, que es entre el 20 y 25% del costo total. Elementos como la administracin del proyecto, el nivel de detalle de la documentacin tcnica o la documentacin de pruebas, y las pruebas por s mismas tambin deben considerarse. Por otro lado, hoy en da hay una amplia gama de lenguajes y herramientas para producir software, lo que ha provocado que pueda generarse la misma funcionalidad con lenguajes de programacin distintos, y esto con un nmero de lneas de cdigos distintos y, lo que es ms impactante, con un esfuerzo distinto. La estimacin es un proceso continuo que acompaa a todo el desarrollo del proyecto y comienza usando pocas variables en un nivel alto de abstraccin. A esta primera etapa se la denomina macroestimacin y permite obtener valores aproximados de costo, tiempo y esfuerzo como para estudiar la viabilidad del proyecto. Una vez comenzado el proyecto y obtenidos estos valores se pueden efectuar comparaciones, detectar desvos en el plan y realizar los ajustes correspondientes. A medida que el proyecto progresa, aumenta la informacin del mismo, la estimacin se torna de grano ms fino y los parmetros descriptivos de las etapas iniciales se convierten en otros ms detallados (como por ejemplo cantidad de mdulos o nmero de lneas de cdigo). El aporte de un mayor caudal de informacin, proveniente del diseo, programacin e implementacin disminuye el margen de error, hasta hacerse mnimo en la fase de aceptacin del software. No se puede considerar a la estimacin como una ciencia exacta ya que existen numerosas variables humanas, tcnicas, del entorno y polticas, entre otras, que intervienen en su proceso y que pueden afectar los resultados finales. Sin embargo, cuando es llevada a cabo en forma sistemtica, se pueden lograr resultados con un grado aceptable de riesgo y convertirla en un instrumento til para la toma de decisiones. Los Puntos de Funcin permiten estimar el tamao del software a partir de sus requerimientos, mientras que los Casos de Uso permiten documentar los requerimientos del software. Ambos tratan de ser independientes de las tecnologas utilizadas para la implementacin. En etapas tempranas del ciclo de vida, se identifican los Actores y los Casos de Uso del sistema, y se documenta cada uno de ellos mediante una brevedescripcin. Aplicando el Anlisis de Puntos de Funcin a estos Casos de Uso, se

podr obtener una estimacin bastante imprecisa debida principalmente a la escasa informacin que se tiene sobre el software al principio de un proyecto, pero permitir obtener una idea del esfuerzo necesario para llevar adelante el mismo, y podr ser refinada a medida que se obtenga ms informacin. Si se aplica nuevamente el Anlisis de Puntos de Funcin sobre una descripcin ms detallada de los Casos de Uso, la estimacin del tamao y esfuerzo ser ms precisa que la anterior. Esta mtrica se define como una mtrica funcional, dado que se enfoca a la funcionalidad que el software proporciona al usuario. Es una mtrica para establecer el tamao y complejidad de los sistemas informticos basada en la cantidad de funcionalidad requerida y entregada a los usuarios. Los Puntos de Funcin miden el tamao lgico o funcional de los proyectos o aplicaciones de software basado en los requerimientos funcionales del usuario. .Partamos de la primera definicin para entender las caractersticas de la mtrica: TAMAO es una mtrica de tamao, no de la calidad con la que se hizo ese software, o del valor de ese producto, o del esfuerzo requerido para desarrollarlo, etc. APLICACIONES mide las aplicaciones de software, no considera el hardware que utilizar, ni la administracin del proyecto, ni la documentacin, etc. FUNCIONALIDAD se refiere a la capacidad del software para que un usuario pueda realizar transacciones (lectura, escritura, etc.) y el guardar datos. Si analizamos a detalle, con estos elementos podemos describir cualquier sistema. USUARIO quien lo va a usar y no quien lo desarroll o quien lo dise. As como existe el metro lineal para medir longitudes, Puntos Funcin es "el metro" para medir tamao de una aplicacin de software. El mtodo de Puntos de Funcin fue publicado por primera vez en el ao 1979 por Allan J. Albrecht [Albrecht, 1979] y se obtienen utilizando una relacin emprica basada en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivas de su complejidad. Es un mtodo para medir el tamao del software. Pretende medir la funcionalidad entregada al usuario independientemente de la tecnologa utilizada para la construccin y explotacin del software, y tambin ser til en cualquiera de las fases de vida del software, desde el diseo inicial hasta la explotacin y mantenimiento.

Sus objetivos son: Medir lo que el usuario pide y lo que el usuario recibe. Medir independientemente de la tecnologa utilizada en la implantacin del sistema. Proporcionar una mtrica del tamao. Proporcionar un medio para la estimacin del software. Proporcionar un factor de normalizacin para la comparacin de distintos software. Una vez presentado el mtodo, 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 Funcin (en ingls International Function Point User Group IFPUG). Esta organizacin se encarga de la difusin del mtodo y de la publicacin de manuales de uso y documentos de cmo sacar provecho del mismo. Los Puntos de Funcin fueron diseados originariamente para ser aplicados a sistemas de informacin de gestin, es por ello que se puso nfasis en la dimensin de datos, excluyendo las dimensiones funcionales y de control. Su aplicacin no era del todo adecuada para sistemas de ingeniera y embebidos, pero con el correr del tiempo, se fueron subsanando estos inconvenientes. An as, han surgido algunas variantes, entre las que se pueden contar: Feature Points (Puntos de Caractersticas): este mtodo fue propuesto por Caper Jones [Jones, 1987] como una alternativa que permitiera obtener puntos de funcin en software cientfico y de ingeniera. Para evitar confusiones con los Puntos de Funcin, Jones lo denomin puntos de caracterstica (en ingls feature points). Actualmente es usado con mucho xito en software del tipo CAD (del ingls Computer Aided Design), sistemas embebidos y sistemas en tiempo real. MK II FPA: propuesto por Charles R. Symons [Symons, 1998], este mtodo es una derivacin de los Puntos de Funcin 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 lgicos internos y externos), mientras que el MK II FPA mira al sistema como una coleccin de transacciones lgicas discretas, compuestas cada una de ellas por entrada, proceso y salida. Si se usan herramientas modernas de diseo para el desarrollo del software, y esas herramientas permiten identificar fcilmente las transacciones lgicas, resulta apropiado el uso de este mtodo. 3-D Function Point: entre los aos 1989 y 1992, Scott Whitmire [Whitmire, 1992] desarroll un mtodo para la empresa internacional de aeronavegacin Boing. El objetivo fue ampliar su espectro a sistemas con elevada complejidad como los sistemas en tiempo real. El trmino 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 mtodo, para aquel tipo de software, pero presenta el inconveniente de la necesidad de disponer de mayor cantidad de informacin acerca del sistema, sobre todo de la complejidad de los algoritmos a implementarse; esta informacin no siempre est disponible en las primeras etapas del desarrollo. Full Function Points (Puntos de Funcin Completos): esta tcnica ha sido desarrollada por un equipo de la Universidad de Qubec en Montreal (Canad) [Abran A., et al., 1998], siendo muy eficiente en la medicin de puntos de funcin en sistemas de control, tiempo real y embebido. Particularmente, los sistemas en tiempo real presentan dos factores crticos: primero, el tiempo de respuesta y en segundo lugar, su interaccin con entidades externas. Los puntos de funcin de Albrecht tienen limitaciones para medir sistemas software en tiempo real. Estos ltimos trabajan con dos tipos de estructura de datos de control: grupo lgico de ocurrencia mltiple, que puede tener ms de una instancia por cada tipo de registro y el grupo lgico 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 variacin importante en la cantidad de subprocesos por proceso; es decir, el mtodo debera contemplar que unos procesos contaran con unos pocos subprocesos y otros en cambio, con un nmero significativo de ellos. Los puntos de funcin se basan ms en el nmero de procesos que en el de subprocesos. Para paliar este inconveniente, Full Function Points introduce en el clculo no solamente a los procesos, sino que tambin incluye a los subprocesos. COSMIC FFP: a finales de 1998, un grupo de expertos en mtricas de software, establecieron el Common Software Measurement International Consortium (COSMIC FFP). La iniciativa de COSMIC, ha sido bsicamente la de dar respuesta a proveedores y a clientes de servicios de desarrollo de software, principalmente en aquellos contratos de terceros donde no haba 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 tamao del software como un paso clave en la estimacin de los costos del proyecto, como a los clientes que quieren conocer ese tamao recibido como un

componente importante para la medicin del rendimiento del proveedor. El mtodo se puede aplicar a dominios de software de gestin, tiempo real e hbridos.

Fig 1. Evolucin de los mtodos de estimacin basados en FP Existen herramientas automticas de estimacin que implementan tcnicas de descomposicin o modelos empricos y estn provistas de entornos grficos, interfaz interactiva y uso estandarizado que hacen de ellas una buena opcin. Adems permiten describir caractersticas de la organizacin (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 automticas de estimacin La tcnica de medicin del tamao en punto-funcin consiste en asignar una cantidad de "puntos" a una aplicacin informtica segn 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 funcin se calculan completando la tabla de la Figura 3. Se determinan cinco caractersticas de dominios de informacin y se proporcionan las cuentas en la posicin apropiada de la tabla. Los valores de los dominios de informacin se definen de la forma siguiente:

Nmero de entradas de usuario. Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicacin. Las entradas se deberan diferenciar de las peticiones, las cuales se cuentan de forma separada. Nmero de salidas de usuario. Se cuenta cada salida que proporciona al usuario informacin orientada a la aplicacin. 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. Nmero de peticiones de usuario. Una peticin se define como una entrada interactiva que produce la generacin de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada peticin por separado. Nmero de archivos. Se cuenta cada archivo maestro lgico (esto es, un grupo lgico de datos que puede ser una parte de una gran base de datos o un archivo independiente). Nmero de interfaces externas. Se cuentan todas las interfaces legibles por la mquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir informacin 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 mtodos de puntos de funcin desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. No obstante la determinacin de la complejidad es algo subjetiva.

Fig 3. Clculo de puntos de funcin. Para calcular puntos de funcin, se utiliza la relacin 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 recuperacin fiables? 2. Se requiere comunicacin de datos? 3. Existen funciones de procesamiento distribuido? 4. Es crtico el rendimiento? 5. Se ejecutara 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 mltiples 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 diseado el cdigo para ser reutilizable? 12. Estn incluidas en el diseo la conversi6n y la instalaci6n? 13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? 14. Se ha diseado la aplicaci6n para facilitar los cambios y para ser fcilmente 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 ecuacin (1) y los factores de peso que se aplican a las cuentas de los dominios de informacin se determinan empricamente. Una vez que se han calculado los puntos de funcin, se utilizan de forma anloga a las lneas de cdigo como forma de normalizar las medidas de productividad, calidad y otros atributos del software. Una vez calculado los puntos de funcin se usan de forma analgica a las lneas de cdigo como medida de la productividad, calidad y otros productos del software. Productividad = PF / persona-mes Calidad = Errores / PF Costo = Dlares / PF Documentacin = Pags. Doc / PF El proceso de clculo y obtencin de puntos de funcin y su posible transformacin a lneas de cdigo se esquematiza en la figura:

Fig. 2 Proceso de clculo de puntos de funcin y transformacin a lneas de cdigo Hay muchos usos de los puntos funcin ms all de los programas de estimacin, esfuerzo y costo. Entre ellos tenemos: El uso de puntos funcin para estimar casos de prueba. El uso de puntos funcin para ayudar a entender rangos de productividad amplios. El uso de puntos funcin para ayudar a entender el crecimiento de Proyectos. El uso de puntos funcin para ayudar a calcular el costo real del software. El uso de puntos funcin para ayudar a estimar el costo de proyectos, la programacin y el esfuerzo. El uso de puntos funcin para ayudar a entender los costos de mantenimiento. El uso de puntos funcin para ayudar con las negociaciones de contrato.

El uso de puntos funcin para desarrollar un estndar de establecimiento de mtricas.

El uso de puntos funcin para estimar casos de prueba

Muchos intentos se han realizado para tratar de establecer una relacin entre puntos funcin y los esfuerzos asociados con el desarrollo de software. La dificultad de establecer esta relacin estriba en el hecho de que solo la relacin entre puntos funcin y el ciclo de vida completo del software son examinados. Esta seccin examina la relacin entre puntos funcin y las pruebas -- en particular la relacin entre los casos de prueba y los puntos funcin. La relacin entre puntos funcin y el nmero de casos de prueba es muy fuerte. Capers Jones estima que el nmero de casos de prueba aproximadamente ser igual al nmero de puntos funcin elevado a la potencia 1.2 (FP 1.2). Esto es, los casos de prueba crecen en una proporcin mayor que los puntos funcin. Esto es intuitivo porque cuando una aplicacin crece, el nmero de interrelaciones dentro de la aplicacin se vuelven ms complejas. Por ejemplo, si una aplicacin de desarrollo tiene 1,000 puntos funcin, 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 cdigo ha sido completado, posiblemente slo lograrn crear menos de 4,000 casos de prueba.

El uso de puntos funcin para ayudar a entender rangos de productividad amplios

Las medidas de productividad inconsistentes entre proyectos pueden ser un indicador de que un proceso estndar no se est siguiendo. Productividad se define como la razn 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 funcin). 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 funcin correctamente y capturado los tiempos consistentemente. Las organizaciones se quejan de anlisis de productividad sin valor. En la mayora 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 tambin resultan inconsistentes. Lo mismo puede ser cierto para cualquier proceso de produccin. Los cambios bruscos en las medidas de productividad entre proyectos son una indicacin de que no se est siguiendo un proceso estndar. En la medida que los equipos de trabajo se adhieren a un proceso estndar de desarrollo, los rangos de productividad se deben estabilizar y ser ms consistentes.

El uso de puntos funcin para ayudar a entender el crecimiento de proyectos

El anlisis de puntos funcin provee un mecanismo para monitorizar el crecimiento de proyectos. El conteo de puntos funcin al final de las fases de obtencin de requisitos, anlisis, diseo e implementacin se pueden comparar. El conteo de puntos funcin al final de los requisitos y/o diseo se puede comparar a los puntos funcin al final del proyecto. Si el nmero de puntos funcin 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 indicacin 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 travs del tiempo, se asume de manera natural que la comunicacin con el usuario ha mejorado.

El uso de puntos funcin para ayudar a calcular el costo real del software
La mayora 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 clculo real debera ser el valor presente de todos los desarrollos, mejoras, y costos de mantenimiento esperados durante la vida del proyecto. Este tipo de

anlisis demuestra la recompensa de invertir en un diseo y anlisis de primera. Cuanto ms se invierta en un buen diseo, ms se va a ahorrar en futuros costos de mantenimiento y mejoras. Es importante tener un costo unitario para evaluar la inversin inicial y comparar sta con los gastos posteriores. El costo unitario puede ser horas/PF o $/PF. Los incrementos en la inversin inicial deben reducir el costo unitario de actividades de mejora y mantenimiento futuras.

El uso de puntos funcin para ayudar a estimar el costo de proyectos, la programacin y el esfuerzo
La estimacin exitosa usando puntos funcin se basa en varias tcnicas de estimacin: Top-Down, Analoga y Consejo de Expertos. La estimacin Top-Down es una tcnica de estimacin que calcula el programa entero, costo y esfuerzo usando parmetros amplios. Los parmetros amplios y las comparaciones estn basados en datos histricos usando tcnicas estimativas de Analoga. El Consejo de Expertos se obtiene de expertos con experiencia en proyectos similares o experiencia en el uso de puntos funcin. La comparacin de proyectos con otros similares es una actividad crtica para lograr una estimacin exitosa. Cuando se evalan 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 aplicacin Tipo de sistema operativo: MVS, Windows, Unix Una vez que los proyectos han sido determinados, obtener los siguientes datos: Medida histrica de entrega (horas por punto funcin) de proyectos similares Programas histricos (duracin de programas por punto funcin) de proyectos similares Costos histricos (dlares por punto funcin) Una vez que el tamao del proyecto se ha determinado en puntos funcin, el estimado de horas, costo y programa se puede calcular. Los clculos se deben hacer con datos de proyectos similares como se describi anteriormente. Por ejemplo, si se determina que el tamao del proyecto actual es de 500 puntos funcin y la medida de entrega de un proyecto similar es $10 por punto funcin, entonces el costo total esperado para el proyecto sera $10 ($/punto funcin) x 500 PFs = $5,000 dlares. Pueden hacerse clculos similares para programas, duracin y horas.

El uso de puntos funcin para ayudar a entender los costos de mantenimiento

Muchos presupuestos de mantenimiento se establecen basados en ejecuciones de aos pasados. Muchas organizaciones tratan de reducir los costos de mantenimiento y no planean incrementarlos ao por ao para cualquier aplicacin particular. Si la nueva funcionalidad es encontrada y aadida 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 funcin, el crecimiento de los costos de mantenimiento en realidad disminuye. Por ejemplo, si una organizacin gasta $100,000 para mantener 10,000 puntos funcin o $10 por punto funcin, pero el nmero de puntos funcin crece 10% a 11,000 y los dlares de mantenimiento permanecen constantes, entonces los costos de mantenimiento por punto funcin disminuye a $9. Muchos ejecutivos de sistemas no entienden ni asimilan este concepto.

El uso de puntos funcin para ayudar con las negociaciones de contrato

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

Los puntos funcin 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 ms 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 representacin precisa del esfuerzo. La estimacin de este esfuerzo (en el ciclo de vida completo) puede ocurrir slo cuando una mtrica normalizada, tal como la provista por los puntos funcin, se aplica. Resumiendo, el anlisis de puntos funcin provee el mejor mtodo objetivo para medir los proyectos de software, y para manejar el tamao de los proyectos de software durante su desarrollo. Es el mejor mtodo de manejar el riesgo en dos vertientes. Primero, el cliente (usuario/especificador) puede aceptar ms fcilmente el riesgo para un determinado tamao de proyecto de software (en puntos funcin). Segundo, el desarrollador puede ms fcilmente aceptar los riesgos para el costo de produccin (el costo por punto funcin). Adherirse a un conteo consistente de puntos funcin optimiza esta relacin y facilita el desarrollo en lnea y bajo presupuesto. La asignacin de precios de "software externo" (p.ej. el diseado para uso fuera de la organizacin) puede ser encauzado directamente al esfuerzo de produccin cuando se requieren mtricas funcionales. Si un desarrollador de software sabe exactamente cul va a ser su costo interno de desarrollo de un punto funcin, se puede incorporar a los algoritmos de costeo usados para determinar los precios externos. Sin un entendimiento claro del tiempo y esfuerzo por punto funcin, la asignacin de precios a los paquetes de software continuar siendo difcil.

El uso de puntos funcin para desarrollar un estndar de establecimiento de mtricas

Por supuesto, los puntos funcin necesitan usarse en asociacin con las otras medidas. De hecho, los puntos funcin por s mismos proveen poco o nada de beneficio. Muchas mtricas necesitan ser reportadas al nivel organizativo. Por ejemplo, tanto la mtrica de productividad/costo como la mtrica de calidad necesitan ser reportadas al nivel organizativo. Las mtricas de productividad/costo son usadas para demostrar la medida y el costo de la funcionalidad que se est entregando. Las mtricas 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 mtricas deben ser monitorizadas y estudiadas en sus tendencias.

Resultados de una Experiencia en la Determinacin del Tamao de un Software.

La experiencia se desarroll dentro de la asignatura Gestin de Proyectos de Ingeniera de Software, un electivo de quinto ao de la carrera de Ingeniera Informtica en la Universidad de Concepcin. Esta experiencia consisti en un simulacro de llamado a licitacin para el desarrollo de un producto software para una organizacin ficticia. La experiencia se realiz sobre la base de una especificacin 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 tamao del producto, estimar costos y plazos. La mayora de ellos escogi la mtrica puntos de funcin por sobre otras (puntos de caracterstica, lneas de cdigo) por las ventajas que esta mtrica tiene. Todos los alumnos manejaban la tcnica de conteo de puntos de funcin, y utilizaron el mismo mtodo (gua) 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 aplicacin del mtodo para el caso de la estimacin del tamao del software a desarrollar. A continuacin, se presentan los resultados obtenidos en la experiencia descrita anteriormente y una hiptesis explicativa de los resultados. Para presentar una respuesta a un llamado a licitacin, 13 alumnos de quinto ao debieron determinar una buena estimacin del tamao del producto a desarrollar, eligiendo 10 de ellos la mtrica puntos de funcin. Los resultados obtenidos se muestran en la tabla y grficos siguientes. En ellos se muestra la medida en puntos de funcin obtenida por cada alumno, en un rango de 181 a 759.

La desviacin estndar de estos datos es de aproximadamente 211 PF (Puntos de Funcin) sobre el promedio, lo que es sin duda muy alto. Esta gran diferencia condujo a estimaciones de esfuerzo y plazos drsticamente distintas. Esto influy directamente en la cantidad de personal que cada alumno asign al proyecto y a la organizacin del mismo (provocando impacto tambin en la funcin de staffing), adems de la influencia directa en los costos y plazos. Durante el desarrollo del proyecto, las diferencias en estas estimaciones provocaran grandes diferencias tambin en la direccin, por lo que estara efectivamente afectando al proyecto en su conjunto, y por lo tanto al xito o fracaso del mismo. Algo interesante e inesperado result este clculo dispar entre candidatos a ingenieros civiles informticos sobre la base de una misma especificacin de requisitos y un mismo mtodo de clculo de puntos de funcin. La asignacin de complejidad que el mtodo exige para cada tem (entrada, salida, consulta, archivo lgico, archivo de interfaz), es un tanto subjetiva y normalmente difiere de un desarrollador a otro, pero esto no explicara una desviacin de tal magnitud (211 puntos de funcin). La causa de estas diferencias de tamao estimado est en el entendimiento de qu constituye efectivamente una salida externa, una entrada externa, un archivo lgico interno y una consulta. La especificacin del software que fue objeto de medicin, est organizada por tipo de informacin. Los reportes y consultas estn claramente especificados, mediante un diseo de formularios, pero no as las entradas. Slo se especifican los datos que se deben ingresar. De lo anterior, se puede deducir que el nmero de salidas y consultas estaba ms bien claro, y que la causa de las grandes diferencias estuvo en las entradas y archivos lgicos internos. Para el caso de las entradas, dado que no se especificaba cul conjunto de datos sera ingresado simultneamente, algunos alumnos los agruparon segn su criterio, obteniendo un nmero de entradas cercano al nmero de consultas y salidas, pero otros consideraron que cada dato a ingresar constitua una entrada, por lo que el nmero de entradas aument en gran medida. A pesar de que la complejidad de las entradas que involucran a ms 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 lgicos internos, algunos alumnos agruparon grandes conjuntos de informacin en un archivo lgico interno, mientras que otros modelaron la informacin en un esquema entidad relacin, obteniendo una aproximacin mucho ms cercana a la cantidad de tablas que efectivamente implementaran. Evidentemente, el nmero de archivos lgicos internos fue mucho mayor en el segundo caso. Otro factor de dificultad para realizar el clculo del tamao del software fue la existencia del requisito "se debe posibilitar la capacidad de realizar consultas no estructuradas". Este requisito fue tratado de maneras dismiles: fue dejado fuera, considerado al equivalente de 15 o ms consultas complejas, o se decidi que se utilizara una interfaz a alguna herramienta que proveyera dicha funcionalidad. Este punto tambin provoc diferencias. Otro factor importante, que se da tambin en los casos reales (esta experiencia fue acadmica), fue la presin a la que estaban sujetos los participantes. Deban entregar una propuesta de calidad dentro de los plazos, o su castigo sera equivalente a no ganarse el proyecto: una baja calificacin, o peor an,

reprobar la asignatura. Por otro lado, al tener el conocimiento de que el ganador del proyecto no tendra que desarrollarlo, podan arriesgarse a hacer ofrecimientos interesantes y convenientes, pues no ponan 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 ms bien conservadoras.

Combinacin de las alternativas para la estimacin de Proyectos de Software.

Cocomo y la tcnica de estimacin de puntos de funcin El mtodo 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, tamao de la base de datos, complejidad del producto, limitaciones en el tiempo de ejecucin, limitaciones de memoria principal, volatilidad de la mquina virtual, frecuencia de cambio en el modelo de explotacin del ordenador, capacitacin de los analistas, experiencia en aplicaciones, capacitacin de los programadores, experiencia en la mquina virtual, experiencia en el lenguaje de programacin, prcticas modernas de programacin, uso de herramientas para el desarrollo del software y limitaciones en la planificacin). Esta tcnica requiere de un dato elemental determinado por la cantidad de sentencias de cdigo del proyecto a la que posteriormente se aplican diferentes algoritmos que varan de acuerdo al modelo de desarrollo elegido (Orgnico, Semilibre o Libre) para entallarlo finalmente de acuerdo a factores de ajuste seleccionados a partir de las caractersticas especficas del proyecto. Esta informacin se convierte en el aspecto crtico del mtodo ya que ese valor es un parmetro difcil de determinar con exactitud y puede variar considerablemente segn las metodologas de desarrollo utilizadas. El camino para resolver este aspecto crtico es mediante la aplicacin de otra tcnica, la de Puntos de Funcin.

Figura 4: Estimacin de Proyectos por el mtodo de Puntos de Funcin En opinin de varios autores el mtodo de Puntos de Funcin presenta un aspecto crtico en lo referido a la reutilizacin de mdulos preexistentes (por ejemplo varias salidas similares que poseen una misma estructura con variaciones propias de cada una de ellas). En este caso el mtodo las considera a todas diferentes y se miden de la forma descrita anteriormente con lo que se considera que la cantidad de puntos de funcin dara una cifra superior a la real deformando el nmero final con la consabida incidencia (nmero de sentencias de cdigo del software) en la aplicacin del mtodo Cocomo. En resumen, la utilizacin combinada de dos mtodos (Puntos de Funcin y Cocomo) tienden a proporcionar una estimacin ms precisa tratndolos de la siguiente forma: Primero la aplicacin del mtodo de Puntos de Funcin para determinar las sentencias de cdigo del proyecto software, la cual mantiene una distorsin, producida por no considerar esta tcnica la reutilizacin de mdulos preexistentes.

En segundo lugar la aplicacin del mtodo Cocomo partiendo de la informacin producida por el anterior (sentencias de cdigo) para llegar a una estimacin precisa de las horas hombre a aplicar y fundamentalmente a la estimacin de la duracin total del proyecto. Finalmente y basndonos en que el paradigma de objetos considera la reusabilidad como un factor bsico y entendiendo que el mtodo descripto (Puntos de Funcin) pareciera no tomar en cuenta estas caractersticas, queda planteado a partir del presente trabajo, una lnea de investigacin tendiente a analizar la incidencia de las metodologas orientadas a objetos en esta tcnica de estimacin a fin de elaborar los factores de ajuste necesarios para reducir la distorsin provocada. Los casos de uso y la tcnica de estimacin de puntos de funcin Los casos de uso fueron introducidos en 1987 como una herramienta de la tcnica Objetory. Su utilizacin en los procesos de Ingeniera de Software fue propuesta por Ivar Jacobson y publicada en su libro Object Oriented Software Engineering. Actualmente, su empleo se ha extendido an ms, debido a su inclusin 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 artculos, seala que el anlisis de puntos de funcin 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 estimacin del proyecto de software. El aplicar la tcnica de puntos de funcin permite verificar y validar el contenido de un documento de especificacin de Requisitos de software. Lo interesante de la aplicacin de ambas tcnicas es que se puede actualizar el conteo de los puntos de funcin cada vez que los casos de uso cambien y, de esta manera, determinar el impacto que un caso de uso especfico puede producir en la estimacin del desarrollo de todo el proyecto.

Conclusiones
Puede concluirse, entonces, que el tiempo total de duracin de un proyecto est relacionado con las caractersticas propias del mismo y no depende directamente del lenguaje de implementacin del diseo 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 mtodo. Para realizar la planificacin de un proyecto software, es necesario poseer una estimacin certera del esfuerzo necesario para el desarrollo lo ms temprano posible, idealmente, con slo la etapa de especificacin de requisitos cubierta. De ms est decir que sin la especificacin de requisitos cualquier estimacin ser en la ms completa incertidumbre, pues cmo estimar el costo de realizar algo que desconocemos? A esta altura del desarrollo del software, difcilmente se puede realizar una estimacin certera de la cantidad de lneas de cdigo que tendr la aplicacin, ya que en este nivel no tiene por qu estar decidida la herramienta de desarrollo y la cantidad de lneas de cdigo que sern necesarias para implementar una funcin del software dependen fuertemente del programador y la herramienta de desarrollo. Por otra parte, los puntos de funcin pueden ser estimados con mayor certeza a partir de una buena especificacin 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 tcnica de estimacin de proyectos Puntos de Funcin es muy til pero se deben tener en cuenta varios aspectos antes de ponerla en prctica con el objetivo de lograr un resultado lo ms cercano posible a la realidad. El Punto Funcin es una medida del tamao 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 kilmetro para medir la distancia. El Anlisis de Punto Funcin se basa en la teora de que las funciones de una aplicacin son la mejor medida del tamao de un sistema. El Punto Funcin mide el software mediante la cuantificacin de la funcionalidad que el sistema le brinda al usuario basado fundamentalmente en el diseo lgico. Es independiente del lenguaje de computacin, de la metodologa de desarrollo, de la tecnologa utilizada y de la capacidad del equipo de trabajo para desarrollar la aplicacin. El Anlisis del Punto Funcin es un mtodo estndar de medicin de desarrollo de software desde el punto de vista del usuario. La cuenta de Punto Funcin para proyectos de desarrollo mide las funcionalidades que se le proporcionan al usuario conjuntamente con la primera instalacin del software producido cuando el proyecto es terminado. El mtodo de clculo por puntos de funcin es subjetivo y puede arrojar resultados diversos dependiendo de quin ejecute el mtodo. Para realizar el clculo de los puntos de funcin debe existir un consenso dentro de la organizacin para el tratamiento de los requisitos que no se ajustan al mtodo, adems de realizar un pre diseo para que este tamao sea una buena estimacin del tamao real de la aplicacin. Por otra parte, se deben manejar aspectos como la re estimacin del tamao cada vez que se va teniendo mayor conocimiento del producto, esto es, una vez que se va avanzando dentro del desarrollo.

Requiere una dedicacin adicional en los proyectos de desarrollo de software, que suelen desenvolverse con presupuestos ajustados. Su implantacin en una organizacin no acostumbrada a su uso suele resultar penosa y requerir un fuerte compromiso de la direccin. Suele ser vista por los desarrolladores como un mecanismo de control de su trabajo. Otros aspectos negativos seran: Resulta arduo formar al personal en su utilizacin y ms todava mantener unos criterios homogneos de recuento. Carece de precisin cuando se trata de proyectos pequeos. Por debajo de unos 100 pf resulta demasiado poco fiable. Para resultar realmente til, una organizacin 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 caractersticas generales del sistema resulta de dudosa utilidad. Si bien el mismo es criticado por no ser aplicable a todos los sistemas, el tamao de la gran mayora de los sistemas del mercado puede ser estimado utilizando esta tcnica. En general, la mayora de las soluciones alternativas que se proponen se basan en esta tcnica de Albrecht, modificando ligeramente algunos aspectos o incorporndole algn nuevo elemento a estos cinco identificados.

Bibliografa
[Albrecht, 1979] Albrecht, Allan J. 1979. Measuring Aplication Development Productivity. Proc Of IBM applications. Development Joint SHARE/GUIDE Symposium, Monterrey, Pginas 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. Pginas 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 Qubec a Montreal, Canada. [Pressman, 1998]. Pressman, Roger S 1998. Ingeniera del Software. Un Enfoque Prctico. Cuarta Edicin. 581 pginas. Editorial Mc Graw-Hill. ISBN 84-481-1186-9. Pressman R.S, Ingeniera del Software. Un enfoque prctico. Mc Grow Hill. 1994 Symons, Charles R. 1998. Function Point Anlisis 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 Lpez Guerra. Estudiante de cuarto ao de Universidad de las Ciencias Informticas. Ciudad de la Habana, Cuba. Yulia Fustiel Alvarez. Estudiante de cuarto ao de Universidad de las Ciencias Informticas. Ciudad de la Habana, Cuba. Abdiel Matos Nieto. Estudiante de cuarto ao de Universidad de las Ciencias Informticas. Ciudad de la Habana, Cuba. Abdel Prez Lpez. Estudiante de cuarto ao de Universidad de las Ciencias Informticas. Ciudad de la Habana, Cuba. Cuba, Ciudad de la Habana, diciembre de 2007. Elsydania Lopez Guerra

Leer ms: http://www.monografias.com/trabajos55/estimacion-por-puntos-de-funcion/estimacion-porpuntos-de-funcion2.shtml#ixzz2W4jAscIw