¿Qué es el punto de función COSMIC y en qué se diferencia de la estimación en horas?

Mesterséges Intelligencia Központ Kft., empresa de desarrollo de software con sede en Budapest, mide el software en puntos de función COSMIC: así el tamaño es una propiedad del software, no la impresión del estimador, y por eso es verificable, puede volver a medirse y permite comparar dos ofertas.

En resumen: COSMIC (ISO/IEC 19761) mide el tamaño funcional del software: cada movimiento de datos, ya sea Entry (entrada), Exit (salida), Read (lectura) o Write (escritura), vale 1 punto de función COSMIC (CFP). La estimación en horas indica cuánto trabajo espera quien estima; el tamaño medido, lo grande que es la tarea. Por eso es verificable, puede volver a medirse y permite comparar dos ofertas; y el esfuerzo puede derivarse del tamaño y de la productividad empírica.

¿Qué es la medición del tamaño funcional?

El tamaño del software puede expresarse de muchas maneras: en líneas de código, en horas, en puntos. La medición del tamaño funcional (en inglés, functional size measurement, FSM) mide lo que el software tiene que hacer desde el punto de vista de sus usuarios, no cómo se implementa. Sus conceptos básicos los establece la norma ISO/IEC 14143-1:2007; según la descripción de la norma, el objetivo es precisamente que la medición se centre en las funciones que requiere el usuario, en lugar de en la forma de implementarlas.

La base de la medición es el conjunto de los requisitos funcionales de usuario (functional user requirements, FUR): la parte de los requisitos de usuario que describe qué tareas y servicios debe realizar el software. El rendimiento, la seguridad o la tecnología elegida no forman parte de ellos; de eso hablamos más abajo, en los límites.

Existen varios métodos normalizados de medición del tamaño funcional. Los más conocidos son COSMIC (ISO/IEC 19761:2011) y el método IFPUG (ISO/IEC 20926:2009); la ISO ha normalizado también otros métodos (NESMA, FiSMA, Mk II). Todos trabajan a partir de los requisitos, pero con reglas distintas y con unidades de medida distintas, por lo que las cifras medidas con métodos diferentes no pueden compararse directamente.

¿Qué es COSMIC?

COSMIC es la sigla de Common Software Measurement International Consortium: una organización sin ánimo de lucro que mantiene el método y organiza la certificación de los medidores. El método surgió a finales de los años noventa como evolución de los métodos de puntos de función anteriores, se convirtió en norma ISO en 2003, y la edición vigente es la ISO/IEC 19761:2011. La descripción detallada del método, la versión 5.0 del COSMIC Measurement Manual, puede descargarse gratuitamente; su primera parte es de 2021 y la segunda, de 2024.

Según la norma, el método sirve para medir software de aplicación (por ejemplo, sistemas empresariales), software en tiempo real y combinaciones de ambos; es decir, con él puede medirse tanto un sistema ERP, CRM o de tienda online como un software de control.

Los conceptos del modelo COSMIC

COSMIC describe el software con un modelo sencillo: el software intercambia datos con sus usuarios funcionales a través de su frontera y, dentro de la frontera, lee del almacenamiento persistente y escribe en él.

Concepto	Qué significa	Ejemplo
Usuario funcional	quien o lo que envía datos al software o espera datos de él: una persona, otro software o un dispositivo	el administrativo, el sistema de facturación
Frontera	una interfaz conceptual entre el software medido y sus usuarios funcionales	la interfaz web y la interfaz abierta hacia los demás sistemas
Evento desencadenante	un evento ante el cual el usuario funcional inicia un proceso	se presenta un cliente nuevo
Proceso funcional	una unidad elemental de los requisitos, ejecutable de forma independiente: una secuencia coherente de movimientos de datos	«registrar un cliente nuevo»
Grupo de datos	un conjunto de atributos de datos que se refieren a una sola cosa sobre la que el software debe gestionar datos	el Cliente: nombre, dirección, NIF, correo electrónico
Movimiento de datos	el movimiento de un único grupo de datos; hay cuatro tipos	véase más abajo

Los cuatro movimientos de datos:

• Entry (entrada): un grupo de datos llega desde el usuario funcional, a través de la frontera, al proceso.
• Exit (salida): un grupo de datos sale del proceso, a través de la frontera, hacia el usuario funcional.
• Read (lectura): el proceso lee un grupo de datos del almacenamiento persistente.
• Write (escritura): el proceso escribe un grupo de datos en el almacenamiento persistente; la eliminación también cuenta como escritura.

Algunas de las reglas de medición que determinan el recuento:

• Cada movimiento de datos es 1 CFP. El tamaño de un proceso funcional es la suma de sus movimientos de datos, y el del software, la suma de los tamaños de sus procesos.
• Todo proceso funcional consta de al menos dos movimientos de datos: una entrada desencadenante y al menos una salida o una escritura.
• Dentro de un proceso, un mismo tipo de movimiento del mismo grupo de datos solo cuenta una vez, tenga los campos que tenga.
• Todos los mensajes de error y de confirmación de un proceso cuentan juntos como una única salida.
• El tamaño depende de los tipos, no de las ocurrencias: que se registren diez o diez mil clientes al día no cambia el tamaño.
• El método no mide por separado el procesamiento de los datos (cálculo, validación): forma parte del movimiento de datos correspondiente.

El resultado se expresa en una escala de razón, es decir, los tamaños pueden sumarse y compararse: dos partes de 40 CFP suman juntas 80 CFP, y el subtotal también puede mostrarse por grupo de funciones.

Ejemplo resuelto: «registrar un cliente nuevo»

Tomemos un requisito sencillo: «El administrativo registra los datos del cliente nuevo (nombre, dirección, NIF, correo electrónico). El sistema comprueba que el cliente no esté ya registrado, lo guarda e informa del éxito o del error». Los pasos de la medición:

1. El usuario funcional es el administrativo, y el evento desencadenante, que se presenta un cliente nuevo.
2. El grupo de datos es el Cliente; los cuatro atributos se refieren a la misma cosa, por lo que forman un solo grupo.
3. Los movimientos de datos se identifican a partir de las frases del requisito, y se cuenta cada uno de ellos.

Paso	Movimiento de datos	Grupo de datos	Tamaño
El administrativo envía el formulario	Entry (entrada)	Cliente	1 CFP
El sistema comprueba si el cliente ya existe	Read (lectura)	Cliente	1 CFP
El sistema guarda el cliente nuevo	Write (escritura)	Cliente	1 CFP
Aviso del éxito o de cualquier error	Exit (salida)	mensaje de error y de confirmación	1 CFP
Total	cuatro movimientos de datos	un grupo de datos	4 CFP

El ejemplo «registrar un nuevo empleado» de la guía publicada en el sitio web de COSMIC se construye del mismo modo. Así se reflejan en el tamaño los cambios del requisito:

• Si el sistema también tiene que transmitir el cliente nuevo al sistema de facturación, eso es una salida más hacia otro usuario funcional: 5 CFP.
• Si el código postal debe comprobarse en una tabla de localidades, eso es una lectura más, porque se refiere a otro grupo de datos: 1 CFP más.
• Si el formulario pide doce campos sobre el cliente en lugar de cuatro, el tamaño no cambia, porque el grupo de datos es el mismo.
• Si hay que modificar un proceso existente, el tamaño del cambio es la suma de los movimientos de datos añadidos, modificados y eliminados.

El ejemplo también muestra por qué la medición es verificable: detrás de cada CFP hay un requisito identificado, un grupo de datos y una regla. Si alguien lo discute, puede señalarse exactamente de qué fila se trata.

Medir pronto, afinar después

Una medición COSMIC empieza por fijar el propósito y el alcance de la medición: qué medimos, qué incluye y para qué se utilizará el resultado. Una medición exacta requiere unos requisitos lo bastante detallados como para identificar los procesos funcionales y sus movimientos de datos. Al comienzo de un proyecto, a menudo todavía no existen; para este caso, COSMIC publica métodos de aproximación para la estimación temprana del tamaño, y una vez elaborados los requisitos, puede seguir la medición exacta.

La guía del método advierte también de que muchas necesidades que al principio parecen no funcionales (por ejemplo, el tiempo de respuesta o la facilidad de uso) se convierten en funciones del software a lo largo del proyecto, y por eso el tamaño parece crecer. No es un fallo de la medición, sino una muestra de que el requisito se ha vuelto más preciso. Por eso, en la práctica conviene redactar la especificación de forma detallada, punto por punto, volver a medir los cambios con el mismo método y mostrar por separado el tamaño de cada cambio. Así, el crecimiento del alcance no se produce en silencio, sino que se ve en cifras.

Comparación: horas, story points, IFPUG, COSMIC

Criterio	Estimación en horas	Story points	Punto de función IFPUG	Punto de función COSMIC
Qué expresa	el trabajo que espera quien estima	la estimación relativa del equipo; no siempre está claro si de tamaño, de esfuerzo o de tiempo	el tamaño funcional	el tamaño funcional
Si está normalizado	no	no	sí, ISO/IEC 20926:2009	sí, ISO/IEC 19761:2011
De qué depende	de la experiencia, la prudencia y el equipo de quien estima	del equipo concreto; significa algo distinto en cada equipo	de los requisitos	de los requisitos
Si puede verificarse desde fuera	solo a partir de las explicaciones de quien estima	apenas, fuera del equipo	sí, según reglas públicas	sí, según reglas públicas y de acceso gratuito
Unidad	hora	el punto propio del equipo	punto de función IFPUG	CFP, 1 CFP = 1 movimiento de datos
Para qué sirve mejor	para planificar tareas breves y bien conocidas	para la planificación de los sprints del propio equipo	para medir el tamaño y comparar	para medir el tamaño, comparar y servir de base a la oferta y al calendario

La estimación en horas no es una mala herramienta; simplemente mide otra cosa: el trabajo previsto, que además del tamaño de la tarea depende de los conocimientos, las herramientas y la prudencia del equipo. Los story points (puntos de historia) son útiles para la planificación dentro del equipo, pero, según la guía publicada en el sitio web de COSMIC, son subjetivos y su significado varía de un equipo a otro. IFPUG y COSMIC son ambos tamaños funcionales normalizados, pero con reglas distintas, por lo que las cifras de los dos métodos no son intercambiables.

¿Por qué el tamaño medido es una base más fiable?

Respondiendo con precisión a la pregunta del título: COSMIC no estima las horas con más precisión, sino que mide el tamaño de la tarea, y eso es lo que hace más fiable la estimación del esfuerzo. Los motivos:

• Mide el requisito, no la implementación. El tamaño funcional se deriva únicamente de los requisitos, por lo que es independiente de la tecnología, del proceso y de quién desarrolle el software.
• Puede volver a medirse con reglas públicas. Las reglas son públicas y el resultado de la medición debe documentarse, de modo que otro medidor puede verificarlo a partir de la misma especificación.
• El tamaño y la productividad se separan. La estimación del esfuerzo se obtiene del tamaño y de una productividad empírica (esfuerzo = tamaño / productividad). Así se ve qué factor cambia y por qué.
• La medición mejora los requisitos. Según la guía de COSMIC, la medición temprana ayuda a detectar requisitos ambiguos, contradictorios o incompletos.
• Es comparable. Dos ofertas para la misma especificación obtienen el mismo tamaño, por lo que los precios se refieren al mismo alcance.

La guía de COSMIC cita varios estudios en los que el tamaño medido en CFP evolucionaba de forma más estrechamente ligada al esfuerzo real que la estimación expresada en story points. La misma guía advierte también de que el esfuerzo estimado a partir del tamaño es fiable cuando el proceso de desarrollo es suficientemente repetible y el esfuerzo depende principalmente del tamaño. Por tanto, el tamaño medido es un mejor punto de partida, pero para una buena estimación también hay que conocer la productividad.

¿Qué no mide COSMIC?

El tamaño COSMIC mide las funciones, y la descripción del método lo dice abiertamente. Lo que no expresa:

• Algoritmos complejos. Según la norma, el método no se diseñó para medir software caracterizado por algoritmos matemáticos complejos o por conjuntos de reglas especiales (por ejemplo, sistemas expertos, simulación, software que aprende por sí mismo, predicción meteorológica).
• Procesamiento de señales continuas. El procesamiento de audio y de imagen y, por ejemplo, las partes de este tipo de los videojuegos también quedan fuera del ámbito de la norma.
• Requisitos verdaderamente no funcionales. Según el método, las restricciones tecnológicas, de rendimiento y del proyecto deben documentarse, pero no se miden en CFP.
• Trabajo creativo. Según la guía de COSMIC, las tareas puramente creativas, como la creación artística, no son objeto del método; por eso el tamaño no expresa el trabajo de los gráficos y del diseño visual a medida.
• Implantación de un paquete estándar. Si los requisitos se cubren en gran parte con la configuración de un producto estándar, conviene estimar el esfuerzo de la forma propia de ese paquete.

Por eso, una buena oferta muestra por separado, junto al tamaño medido, lo que el tamaño no expresa: las integraciones, los requisitos no funcionales, la interfaz y los gráficos personalizados, las varias plataformas, la migración de datos, los cálculos complejos y el funcionamiento en tiempo real. En nuestras ofertas, estas partidas figuran así; lo explicamos en la página Precios.

¿Cómo lo utilizamos en nuestro propio trabajo?

Medimos el tamaño funcional del desarrollo en puntos de función COSMIC. Para la medición hemos construido un flujo de trabajo propio asistido por inteligencia artificial, y una persona comprueba el resultado en una ronda de revisión. Los pasos:

1. Especificación detallada: dividimos el desarrollo en grupos de funciones y describimos cada uno con la misma plantilla: objetivo, actores, datos, funciones, funciones de IA y lo que no forma parte de él (véase Cómo trabajamos).
2. Varios recuentos independientes: varios modelos de lenguaje cuentan cada grupo de funciones varias veces; la dispersión de los recuentos muestra la incertidumbre.
3. Ronda de conciliación: garantiza que cada proceso funcional cuente exactamente una vez, aunque aparezca en varias descripciones.
4. Revisión: revisamos la medición, aclaramos los puntos dudosos y, si es necesario, corregimos a mano las fusiones automáticas.
5. Fijación: la medición terminada puede fijarse como una versión inmutable, que se convierte en la base del contrato.

Al ampliar un sistema existente, describimos por separado la parte existente, de modo que en el tamaño solo cuenta la parte nueva. La medición también señala lo que el tamaño funcional no expresa.

¿Cómo se convierte el tamaño en oferta y calendario?

El precio de la oferta se deriva del tamaño medido, complementado con las partidas que el tamaño no expresa. Como vemos el tamaño también por grupo de funciones, construimos sobre él también el calendario: el orden de las etapas, el contenido de las demostraciones y los plazos. Si sobre la marcha surge una nueva necesidad, la medimos de la misma manera, y se ve cuánto cambia el alcance y qué supone eso para el precio y el calendario. Por eso solo damos un precio y un plazo concretos después de la medición, y no a partir de una primera conversación.

Comparar dos ofertas por su tamaño

Si pide ofertas a varios desarrolladores, el tamaño ayuda a decidir si se refieren a la misma tarea. Conviene proceder así:

1. La misma especificación: todos los ofertantes reciben la misma descripción detallada.
2. El tamaño y la lista de procesos: pregunte para qué tamaño y para qué procesos funcionales han dado el precio.
3. Los motivos de las diferencias: si dos ofertas difieren, compruebe si la diferencia está en el tamaño, en las partidas que el tamaño no expresa o en el precio por unidad de tamaño.
4. Las partidas aparte: pregunte qué figura en una línea aparte (integración, migración de datos, operación) y qué no incluye el precio.
5. La gestión de los cambios: pregunte cómo se miden y se valoran los cambios que surjan sobre la marcha.

Si un ofertante no mide el tamaño funcional, su oferta sigue siendo comparable si ha calculado el precio sobre la misma lista detallada de procesos. Sobre los demás criterios para elegir un desarrollador escribimos en el artículo ¿Cómo elegir una empresa de desarrollo de software?; y si hace falta o no un desarrollo a medida, ayuda a decidirlo el artículo ¿Software a medida o solución estándar?.

Preguntas frecuentes

¿Qué es el punto de función COSMIC?

El punto de función COSMIC (CFP) es la unidad de medida del tamaño funcional del software según la norma ISO/IEC 19761. Un CFP es un movimiento de datos: la entrada, la salida, la lectura o la escritura de un grupo de datos en un proceso funcional. El tamaño del software es la suma de los movimientos de datos de sus procesos.

¿En qué se diferencia de la estimación en horas?

La estimación en horas indica el trabajo previsto, y depende de quien estima y del equipo. COSMIC mide el tamaño de la tarea a partir de los requisitos, con reglas públicas, por lo que otra persona puede llegar al mismo resultado a partir de la misma especificación. Después, las horas pueden derivarse del tamaño y de la productividad empírica.

¿Qué no mide COSMIC?

Según la norma, no se creó para medir algoritmos matemáticos complejos ni el procesamiento de señales continuas (audio, imagen), y tampoco expresa en CFP los requisitos verdaderamente no funcionales, como las restricciones de rendimiento o tecnológicas. Una buena oferta los muestra como partidas aparte.

¿Quién lo mide y puede verificarse la medición?

La medición la realiza un medidor que conoce el método; en nuestro caso, el recuento lo hace un flujo de trabajo asistido por IA, y una persona revisa el resultado. Las reglas son públicas y la medición está documentada proceso por proceso, por lo que otro especialista que conozca el método puede verificarla a partir de la misma especificación.

¿Cómo se convierte el tamaño en una oferta?

El precio se deriva del tamaño medido, complementado con lo que el tamaño no expresa: integraciones, requisitos no funcionales, gráficos personalizados, varias plataformas, migración de datos. El calendario se basa en el tamaño por grupo de funciones, y los cambios los medimos de la misma manera. Encontrará los detalles en la página Precios.

¿Cómo podemos ayudarle?

Si está planeando un software a medida, redactamos juntos la especificación detallada, medimos su tamaño en puntos de función COSMIC y, a partir de él, le presentamos la oferta y el calendario. Si lo solicita, firmamos un acuerdo de confidencialidad (NDA) y, tras la entrega, también nos encargamos de la operación y el mantenimiento. El código fuente y los derechos de uso se rigen por el contrato. La primera consulta es gratuita: escríbanos a través de los datos de contacto que figuran en la página Contacto.

Fuentes

• COSMIC Measurement Manual v5.0, Part 1: Principles, Definitions and Rules (PDF)
• COSMIC Measurement Manual v5.0, Part 2: Guidelines (PDF)
• COSMIC: A Guide to Software Size Measurement (PDF)
• COSMIC Measurement Manual: descargas
• ISO: ISO/IEC 19761:2011, COSMIC: a functional size measurement method
• ISO: ISO/IEC 14143-1:2007, Functional size measurement, Part 1: Definition of concepts
• ISO: ISO/IEC 20926:2009, IFPUG functional size measurement method