En el número anterior hablamos sobre la importancia de contar con una métrica funcional estándar para determinar el tamaño de un sistema de software. Los Puntos Función o Function Points (FPs) son una excelente herramienta para este propósito.
La Métrica de Puntos Función
Esta métrica se define como una métrica funcional, dado que se enfoca a la funcionalidad que un producto de software proporciona a sus usuarios.
“Es una métrica para establecer el tamaño y complejidad de los sistemas informáticos basada en la cantidad de funcionalidad requerida y entregada a los usuarios”.
Partamos de esta definición para entender las características de la métrica: Tamaño.– Es una métrica de tamaño, no de la calidad con la que se hizo ese SW, o del valor de ese producto, o del esfuerzo requerido para desarrollarlo, etc. Aplicaciones.– Mide las aplicaciones de SW, no considera el HW que utilizará, ni la administración del proyecto, ni la documentación, etc. Funcionalidad.– Se refiere a la capacidad del SW para que un usuario pueda realizar transacciones (lectura, escritura, etc.) y 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 Función es “el metro” para medir tamaño de una aplicación de software.
Estándar Internacional ISO
La medición de la funcionalidad con la que cuenta un sistema informático ha sido desde hace años una preocupación de la industria. No es suficiente contar con una métrica, sino que sea estándar, para así poderla usar a nivel industria. Poder comparar la productividad (Puntos Función por Persona Mes) de una empresa con los datos de la industria, es fundamental en los planes de mejora. Es por eso que a través de la International Organization for Standardization (ISO) se ha desarrollado un estándar internacional: ISO/IEC 14143 – Information Technology – Software Measurement – Functional Size Measurement. Este estándar define los conceptos de una métrica de tamaño basada en la funcionalidad y las características que debe cumplir un método para estar homologado al estándar y ser considerado una medida del tamaño de la funcionalidad.
Existen varios métodos de conteo para establecer la cantidad de Puntos Función que tiene una aplicación. En general, todos establecen un conteo basado en la identificación del tipo de funciones que tiene la aplicación, y a cada una le asocia un número de puntos tomando en cuenta su complejidad. Las variantes surgen al buscar conteos más precisos en Puntos Función conforme al tipo de aplicación. Por ejemplo, un sistema en tiempo real tiene una complejidad muy distinta a un sistema tradicional de negocio o a un sistema operativo o a una aplicación científica que realiza muchos cálculos pero el resultado puede ser un solo dato. Estos son algunos de los métodos homologados con el ISO 14143:
ISO/IEC 20926:2003 - Software engineering - IFPUG 4.1 Unadjusted functional size measurement method. Este método ha sido definido por el International Function Point Users Group (IFPUG) y evolucionado a partir de la propuesta original de Allan Albrecht en IBM, por lo que es el más conocido y más utilizado. Esto es muy importante porque se está convirtiendo en el estándar de facto en la industria.
ISO/IEC 20968:2002 - Software engineering - Mk II Function Point Analysis. Este método ha sido desarrollado por la United Kingdom Software Metrics Association, simplificando el método y haciéndolo compatible con ideas de análisis y diseño estructurado.
ISO/IEC 19761:2003 - Software engineering - COSMIC-FFP - A functional size measurement method. Este método ha sido definido por el Common Software Measurement International Consortium, integrado por expertos de Australia, Canadá, Finlandia, Alemania, Irlanda, Italia, Japón, Holanda y el Reino Unido. La idea principal es adecuarse mejor a la medición de sistemas en tiempo real.
El Método de Análisis de Puntos Función
La versión actual de éste metodo es la 4.1.1, cuyo manual de prácticas de conteo se puede encontrar tanto en inglés como en español. El método de conteo se basa principalmente en la identificación de los componentes del sistema informático en términos de transacciones y grupos de datos lógicos que son relevantes para el usuario en su negocio. A cada uno de estos componentes les asigna un número de puntos por función basándose en el tipo de componente y su complejidad; y la sumatoria de esto nos da los puntos de función sin ajustar. El ajuste es un paso final basándose en las características generales de todo el sistema informático que se está contando. Veamos un poco más a detalle el procedimiento, para entender mejor los conceptos mencionados y conocer su simplicidad.
Procedimiento
Paso 1. Determinar el tipo de conteo. Este paso consiste en definir el tipo de conteo entre desarrollo, mantenimiento o de una aplicación ya instalada. Esta es una forma de determinar el objetivo del conteo.
Paso 2. Identificar los alcances de la medición y los límites de la aplicación. El propósito de una medición consiste en dar una respuesta a un problema de negocio. El alcance de la medición define la funcionalidad que va a ser incluida en una medición específica y puede abarcar más de una aplicación.
Paso 3. Contar las funciones de datos. Este paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Se distinguen dos tipos de funciones de datos:
Archivo Lógico Interno.- Es un grupo de datos relacionados que el usuario identifica, cuyo propósito principal es almacenar datos mantenidos a través de alguna transacción que se está considerando en el conteo.
Archivo de Interfaz Externo.- Es un grupo de datos relacionados y referenciados pero no mantenido por alguna transacción dentro del conteo. A cada componente identificado se le asigna una complejidad (baja, media o alta) considerando principalmente el número de datos.
Paso 4. Contar las funciones transaccionales. Este paso consiste en identificar y contar la capacidad de realizar operaciones. Se distinguen tres tipos de funciones transaccionales: Entrada Externa.– Es un proceso cuyo propósito principal es mantener uno o más archivos lógicos internos. Salida Externa.– Es un proceso cuyo propósito principal es presentar información al usuario mediante un proceso lógico diferente al de sólo recuperar los datos. Consulta Externa.– Es un proceso cuyo propósito principal es presentar información al usuario leída de uno o más grupos de datos.
A cada componente identificado se le asigna una complejidad (baja, media o alta) considerando el número de datos utilizado en el proceso y los archivos referenciados.
Paso 5. Determinar los puntos de función no ajustados. Este paso consiste en sumar el número de componentes de cada tipo conforme a la complejidad asignada, y multiplicarlo por el factor indicado en la siguiente tabla para obtener el total.
Paso 6. Determinar el valor del factor de ajuste. El factor de ajuste se obtiene sumando 0.65 a la sumatoria de los grados de influencia de las 14 características generales del sistema, multiplicado por 0.01. Dentro de las características hay criterios como: complejidad del proceso, facilidad de instalación, entrada de datos en línea, etc.
Paso 7. Determinar los puntos función ajustados. Para determinar los puntos función ajustados se consideran los puntos función no ajustados por el factor de ajuste.
Cualquier Métrica tiene un Alcance Definido
Cualquier métrica tiene un ámbito de acción y alcance definido que hay que entender para usarla correctamente. Así, por ejemplo, el metro lineal no es lo mejor para medir grandes distancias en el mar.
En nuestro caso, Puntos Función está enfocado a medir sistemas informáticos completos, no programas. En este sentido no tiene un nivel de precisión suficiente para medir el tamaño de programas individuales. El nivel de granularidad que puede medir la métrica no es muy pequeño. Adicionalmente el término programa depende de la tecnología, y eso va en contra del criterio de que esta métrica es independiente de la tecnología que se use.
Otro punto que se le ha criticado a las métricas funcionales es que requieren que alguien “identifique” la funcionalidad y “evalúe” la complejidad basándose en los criterios y reglas establecidas; no puedo hacer un programa que cuente automáticamente. Debido a esto, distintas personas podrían llegar a un conteo diferente. Para resolver esto, se han venido depurando las reglas de conteo para eliminar posibles ambigüedades y cada vez hay más material de apoyo con ejemplos. Aunado a lo anterior, hay esquemas de certificación como el del IFPUG, donde hay una evaluación formal de la teoría y casos prácticos. Estos elementos buscan reducir las posibles variaciones en un conteo hecho por diferentes personas. Si tomamos en cuenta que la métrica está pensada para contar proyectos o aplicaciones completas, entonces las pequeñas variaciones en un conteo, no van a ser significativas para los indicadores o datos relacionados que obtengamos.
Comprar SW por Puntos Función
Las compras de SW son en muchos casos desarrollos a la medida. Pero ¿cómo comprar si todavía no se tiene el diseño? Una opción que habilita una métrica como Puntos Función es comprar por “metro” de SW a una empresa que tenga una productividad mínima establecida, conforme al tamaño de las aplicaciones que requiero. Ya durante el proyecto puedo ir solicitando esos Puntos Función que compré, en las aplicaciones que requiero. Por ejemplo, en el caso de Gobierno, la ley de adquisiciones permite hacer compras basadas en estándares internacionales, que como vimos, ya existen en este terreno. Adicionalmente, en el Programa para el Desarrollo de la Industria del Software de la Secretaría de Economía (ProSoft), hay un punto específico que ayudará en este tema: “Promover que se elaboren las normas necesarias para que se cumpla el Reglamento de la Ley de Adquisiciones, Arrendamientos y Servicios del Sector Público en lo que se refiere a la existencia de normas nacionales o internacionales en las adquisiciones de software”.
En mi opinión, el uso de métricas en los proyectos de SW va a empezar a cambiar en la medida que los compradores lo exijan. Es por eso muy importante que los compradores analicen que sólo comprar por precio sin distinguir tamaño de las aplicaciones para escoger a un proveedor que tenga experiencia con esa complejidad o indicadores como productividad o calidad, nos va a seguir llevando a las historias que hemos oído de grandes proyectos que no terminan a tiempo o que exceden por mucho el presupuesto o, en el peor de los casos, nunca llegan a operación.
Se requiere un modelo que permita identificar capacidades de los proveedores, para entonces poder comparar propuestas de proveedores de capacidad similar. “Los proyectos nacionales en informática requieren de empresas con capacidades reales y funcionarios/ejecutivos competentes y exigentes”.
Ya empieza a haber proyectos que, como parte de sus bases para invitar a proveedores, solicitan contar con métricas y con registros históricos que fundamenten los estimados en esfuerzo y tiempo, para tener mejor certeza en que el proyecto que están comprando va a llegar a buen término, a tiempo y en presupuesto. Próximamente empezaremos a ver los primeros resultados y alguno de estos casos de éxito será motivo de un siguiente artículo.
Referencias
• IFPUG. “Manual para la Medición de Puntos Función”. Versión 4.1.1. 1999
• Alberto Balderas, Arnoldo Díaz. “Fábrica de software. Un modelo de negocio certificable basado en Estructura y Capacidades”.
Soluciones Avanzadas. No. 59
Acerca del autor Sergio Eduardo Durán Rubio se desempeña como Director de Proyectos en certum. En 1996 se convirtió en el primer especialista de América Latina certificado por el International Function Point Users Group en Conteo de Puntos Función, y en miembro representante de México ante la ISO/IEC JTC1/SC7. Sergio es Ingeniero en Sistemas Computacionales de la UDLA-P, Maestro en Tecnologías de Información y Administración del ITAM y Mastère Spécialisé en Réseaux Et Systèmes D ‘information pour Les Entreprises de la ENST de Bretagne France.
- Log in to post comments