Estimaciones de Software con COSMIC

Este articulo esta basado en el contenido del Curso de Estimación de Software con Puntos de función suministrado por FATTO.

Hacer una estimación de Software de abajo hacia arriba (Bottom-Up) es inviable cuando no está disponible la estructura de proyecto y hacer una estimación solamente basada en una analogía es muy subjetivo. Además, no se puede aprender de los errores cometidos.

El objetivo de este artículo es introducir el método de medición de COSMIC y presentar una propuesta para derivar unidades de producto a partir de los requerimientos funcionales del usuario en diferentes representaciones.

La problemática de la estimación de software

Estimar pequeños elementos es fácil

Cuando se solicita una medición a un desarrollador para entregar un programa y él provee una estimación de 12 horas, lo más probable es que esté correcto porque se trata de una pieza cuya dificultad o probabilidad de error es pequeña.

Estimar la realización de una actividad de 12 horas.

Un gran elemento como la suma de pequeñas partes

Por lo tanto, la solución para todos los problemas de estimación es descomponer un proyecto en sus partes constituyentes y hacer sus respectivas estimaciones. Con esto, los escenarios en los que la estimación es difícil y su probabilidad de error es alta, ya no serán más un problema.

Estimar la entrega de un producto final a lo largo de dos años.

La falla en esta lógica

La falla en esta lógica es que al inicio no se conocen todos los programas y algunos trabajos no están en función de esta cantidad, como por ejemplo, la ingeniería de requerimientos y el diseño de arquitectura, cuyos productos son los insumos para la programación. 

En otras palabras, el nivel de información disponible no permite usar la lógica de la estimación de abajo hacia arriba como solución para los desafíos de la estimación.

No se pueden identificar cuales son estas actividades de 12 horas durante las fases iniciales del desarrollo.

El dilema de las estimaciones

En estos escenarios, el dilema asociado con la generación de estimaciones se hace más evidente. Mientras que en las actividades menores la complejidad de la estimación es baja y sus errores en cuanto a exactitud tienen impacto negativos pequeños, en los proyectos más grandes existe una dificultad inherente para realizar estimaciones con la precisión necesaria.

#NoEstimates

¿Por qué estimar si al final del trabajo ya tengo certeza de la información de interés? Al final, son apenas entre 15 o 30 días en un ambiente donde se usan enfoques ágiles de desarrollo. Se puede esperar por ese momento para “saber” en lugar de simplemente creer.

Prolongación: Mayor concentración en proyectos pequeños.

¿Se puede decir lo mismo de las decisiones acerca de los cambios que deben ser priorizados en el 20% de las demandas que consumen el 80% de los recursos? La estimación permite gestionar los cambios innherentes a la orquestación del desarrollo de nuevos sistemas, la mejora de varios
sistemas existentes y las variaciones que implican una evaluación preliminar de los costos y beneficios para apoyar decisiones ejecutivas de inversiones que deben ser justificadas para quien mantiene el gobierno de la organización. 

Incluso facilita que los equipos sean auto-administrados y que su desempeño sea planeado y monitoreado de acuerdo con las exigencias de transparencia y eficiencia del gobierno corporativo del mundo actual.

Pocos proyectos y sin embargo mucho esfuerzo.

Curso de Fundamentos del Análisis de Puntos de Función

¿Estás elaborando estimaciones de tiempo y costos en desarrollo de software, pero no son exactas, realistas ni se logran cumplir?

Inscríbete en el curso Fundamentos de análisis de puntos de función.

Cómo realizar estimaciones de software exactas que se ajusten al presupuesto, garantizando el logro de objetivos de proyecto y valor para el cliente.

Inscríbeme

Unidad de producto en Software

La unidad de producto en la construcción civil

Algunos argumentan que el proceso de software es único y está más allá de cualquier medición. Sin embargo, existen similitudes de éste con la construcción civil en escala industrial. Cada edificio es único a pesar de que pueda compartir los elementos arquitectónicos comunes en mayor o menor medida. El proceso de entrega de un inmueble involucra desde la concepción de un proyecto arquitectónico, pasando por varios proyectos de ingeniería, construcción y pruebas específicas, hasta la aceptación final por parte del propietario y la garantía por un periodo de transición.

Cuando se construye un edificio es necesario tener un presupuesto disponible para su construcción y definir parámetros para establecer los requerimientos en cuanto a su diseño arquitectónico. Una información clave en ese momento es el valor del costo unitario medio de construcción por metro cuadrado.

Costo unitario medio de construcción por metro cuadrado.

Con esa información, es posible llegar a la conclusión de una estimación para el área que podría pagar y a partir de eso tomar varias decisiones. Desde luego no se puede usar esa información en un nivel alto de detalle. Después de todo, es mucho más costoso (proporcionalmente) construir un baño que una habitación, ya que el baño tiene un costo mayor de mano de obra y materiales, tales como la instalación hidrosanitaria. Sin embargo, como se comentó anteriormente, cuando fue necesario estimar el costo específicamente del baño, ya se tenían elementos para realizar estimaciones de abajo hacia arriba. Lo importante es que en ese momento de la evolución de la obra, la suma total de estas estimaciones no exceda la estimación inicial basada en la cantidad de metros cuadrados y en la productividad media.

Productividad

En este punto surge un importante concepto: Productividad, que puede ser definida como la razón entre la cantidad de bienes o servicios producidos y las unidades de tiempo o costo para su entrega.

En el caso citado del edificio y en función a sus objetivos, se eligió la cantidad de metros cuadrados construidos en representación del producto y la inversión de dinero en representación de los costos. La planificación de la productividad en la construcción – que a´un no tenía planta – fue realizada en términos de dólares (USD$) por metro cuadrado.

En esa cantidad de USD$/M2 estaban incluidos gastos como el salario del arquitecto, ingenieros, maestro de obras, albañiles, ayudantes, impuestos, tasas, aprobaciones, registros y materiales, que pasan a ser evaluados por medio de una apropiación indirecta de costos.

Apropiación directa e indirecta de costos.

Unidad de Producto

La unidad de producto que cumple el papel de factor de costo primario es el área construida expresada en la unidad de metros cuadrados. ¿Cuál es la métrica que cumple el papel de unidad de producto en la planificación y seguimiento del desarrollo de software?

Antes de establecer esta unidad de producto, es posible definir algunos de sus requerimientos:

• Permitir aproximar el tamaño del software a partir de sus requerimientos.

• Apoyar en la estimación del esfuerzo del proyecto o en la cuantificación del desempeño a partir de la perspectiva del usuario o dueño para fines del análisis de productividad.

• Ser independiente del desarrollo técnico y decisiones de implementación.

• Permitir comparar la productividad entre las diferentes técnicas y tecnologías disponibles.

Este tipo de unidad no elimina la necesidad de otras métricas que permitan cuantificar el desempeño técnico de productos y servicios a partir de su implementación, como por ejemplo:

• Análisis de eficiencia del diseño.

• Mejora en el rendimiento del diseño.

• Apoyo a la ingeniería de requerimientos.

• Apoyo a la verificación y validación.

Un ejemplo de métricas como éstas hacen parte de la familia. ISO/IEC 25.000 o Software product Quality Requirements and Evaluation (SQuaRE).

Tipos de requerimientos

Considerando las características deseadas para esta unidad de producto, se deben tener como objetivo de medición los requerimientos funcionales del usuario, ya que están específicamente asociados a una tarea o servicio del usuario y describen lo que el software debe hacer independientemente de cómo sea desarrollado. Esta información no se tiene cuándo se desea estimar en el nivel táctico y estratégico como se argumenta aquí.

A pesar de que estos requerimientos describen la manipulación y movimiento de datos por medio de la transferencia, transformación, almacenamiento y recuperación de datos, no son los únicos. Existen los requerimientos no funcionales que cubren cualquier otro tipo de restricción de orden general para el producto en cuanto:

• Al ambiente como la interoperabilidad, privacidad y la protección contra da˜nos incidentales o accidentales.

• La organización como los equipos de destino, la adhesión a las normas y los lugares para la operación.

• La implementación como las tecnologías de desarrollo, mantenimiento, soporte y ejecución como, por ejemplo, la herramienta de programación y pruebas, sistemas operativos, sistemas de gestión de bases de datos, sistemas de gestión de la interfaz gráfica con el usuario, etc.

• Requerimientos de calidad o nivel de servicio como las cuestiones relacionadas al desempeño, compatibilidad, usabilidad, confiabilidad, seguridad, facilidad de mantenimiento y portabilidad.

¿Dónde se encuentran los requerimientos funcionales?

Los requerimientos funcionales del usuario se encuentran tanto en los artefactos generados antes de la implementación del software como en aquellos generados después de su implementación. En el primer caso, son elementos como especificaciones de requerimientos, modelos de datos o estructuras que los organizan en una estructura de descomposición funcional. En el segundo caso, son programas físicos, procedimientos y manuales operacionales del software y artefactos de almacenamiento físico de los datos.

Fuentes de información de los requerimientos.

La relación entre los requerimientos funcionales y no funcionales a lo largo del desarrollo

Los requerimientos no funcionales desde la perspectiva de un usuario pueden ser tratados como requerimientos funcionales en la perspectiva de otro. Muchos productos de software que proporcionan servicios compartidos existen con el objetivo de atender requerimientos no funcionales de otros productos de software: sus usuarios. Por ejemplo, los servicios de control de acceso proporcionados por un sistema de single sign-on proveen una funcionalidad de autenticación y autorización compartida por todas las aplicaciones de negocio de una organización.

En otras palabras, conforme avanza el desarrollo debe ser posible medir, usando una métrica unificada, aquellos requerimientos que atienden originalmente los requerimientos no funcionales y que evolucionar ´an en requerimientos funcionales en otra perspectiva.

La evolución de los requerimientos.

Se debe tener en cuenta que siempre habría requerimientos verdaderamente no funcionales y que deben ser registrados por influir en una productividad más alta o más baja. Por ejemplo, se debe considerar si se trata de una construcción unifamiliar o de estándar normal.

Algunos ejemplos de esta evolución:

• El tiempo de respuesta medio en horarios pico no debe exceder 10 segundos. Este requerimiento no funcional evolucionó en el desarrollo de software con el objetivo de proporcionar datos externos en tiempo real y para el seguimiento y reporte del tiempo medio de respuesta; mientras se mantuviera como requerimientos no funcionales la utilización de un equipamiento apropiado y su programación en un lenguaje de bajo nivel.

• La disponibilidad del software debe aumentar en 5% en relación a la media anual pasada. Este requerimiento no funcional evolucionó para el intercambio rápido de procesamiento a un procesador alternativo sin interrupción en el servicio; manteniendo como un requerimiento no funcional que existiera un procesador alternativo operado en ’hot stand by’.

Para fines de medición – y estimación – debe ser posible adoptar una unidad de producto que permita esa flexibilidad conforme a los propósitos de la medición.

Derivación de unidad de producto de los requerimientos funcionales

Contar los requerimientos funcionales parece ser una buena alternativa para representar las unidades de producto del software. Sin embargo, no todos los requerimientos son iguales y se corre el riesgo de no diferenciarlos.

Para eso, la ISO/IEC definió un estándar para ese tipo de medición, denominado Medición del Tamaño Funcional, y cuyo método más moderno es supervisado por el Consorcio Internacional de Medición de Software en General o COSMIC.

El método de medición de tamaño funcional de COSMIC

El método de Medición de COSMIC es la segunda generación de métodos de medición de tamaño funcional. Este ofrece un nivel de confiabilidad compatible con todos los tipos de software. Es de dominio público y el acceso a su documentación no tiene costo. El método tiene reconocimiento total de la ISO/IEC. Posee una base conceptual compatible con la ingeniería de software moderna.

Los métodos anteriores no siempre tienen una aplicación amplia o suficiente para atender las necesidades del mercado ni funcionan apenas con acceso restringido. La planeación y medición del desempeño tiene mayor exactitud y además tiene la habilidad de capturar el tamaño a partir de
múltiples perspectivas.

Visión general del método de medición

Objetivo de la medición

Toda medición depende de los objetivos que la motivaron. Por ejemplo, la medición del área de una edificación en metros cuadrados es hecha de cierta forma si el objetivo es poner el piso y de otra si se pretende calcular cuanto hierro es necesario para la elaboración de la losa de concreto. Por o anterior, el primer insumo en la medición del tamaño funcional usando el método de COSMIC es su objetivo.

Visión general de COSMIC.

Requerimientos funcionales

El objetivo de la medición son los requerimientos funcionales. Cuando se trata de una función, se debe considerar su usuario, ya que los requerimientos funcionales describen lo que el software debe hacer para sus usuarios. Ellos son los destinatarios y remitentes de los datos del software que está siendo medido. Teniendo el usuario como referencia, la medición debe desconsiderar aspectos técnicos o de calidad que influyen en cómo se mide el software. Por esto, la función es relativa al proceso de información que el software debe ejecutar para sus usuarios.

La medición

El método de medición consiste en un conjunto de modelos, principios, reglas y procedimientos que se aplican a los dos insumos mencionados anteriormente. Todo esto, con el propósito de generar el valor de una magnitud para la funcionalidad entregada por el software expresado en puntos de función COSMIC. Tamaño funcional

El resultado de la medición

El resultado de la medición es el valor de una cantidad de funcionalidad entregada por el software en puntos de función COSMIC.

El proceso de medición

La medición es muy simple. En la fase de la estrategia se describe el contexto en el cual el software es adicionado de acuerdo al objetivo de la medición. Además, delimita el software a ser medido y el usuario externo, que no es necesariamente una persona. La siguiente fase, el mapeo de medición, identifica los procesos en aquel contexto. En cada proceso, son identificados movimientos de datos. Finalmente, la fase de medición tiene por objetivo consolidar los movimientos identificados considerando el equivalente a un punto de función COSMIC para cada movimiento de datos identificado.

Proceso de medición COSMIC.

La medición requiere que se establezca una frontera conceptual entre el software y el usuario. La frontera no debe ser confundida con cualquier línea diseñada en un diagrama para delimitar o alcance de una parte del software o camada. La frontera permite hacer distinción clara entre cualquier parte del software medido (dentro) y cualquier parte del ambiente de los usuarios funcionales (fuera).

Fronteras.

Los usuarios funcionales interactúan con el software a través de la frontera vía dos tipos de movimientos de datos (entries y exits). El software también intercambia datos con el dispositivo de almacenamiento persistente vía dos tipos de movimientos de datos (reads y writes). El dispositivo de almacenamiento no es considerado como un usuario del software y, por tanto, está dentro de la frontera del software.

Movimiento de datos.

Cada movimiento contribuye con el equivalente a un punto de función COSMIC.

Un movimiento de datos.

Medición Vs Aproximación del tamaño

En este punto, surge una pregunta: Si el objetivo es estimar cuando todavía no conocen los detalles de la solución, ¿Cómo se pueden identificar estas transferencias de datos en los movimientos iniciales? La respuesta es que no se puede estimar. Antes de estimar el esfuerzo o el plazo, se debe aproximarse al tamaño. Para esto, se debe reconocer cuál es el factor de escala más apropiado.

La diferencia entre aproximar el tamaño y hacer una medición.

Por ejemplo, hay conceptos de negocio pre-existentes y sobre los cuales existe una necesidad de mantener y recuperar a pesar de que se tenga sólo información sobre el dominio del problema. El alcance estará definido en términos de macro procesos de negocio y áreas funcionales. Estos elementos pueden ser contados y comparados con su correlación con el software entregado y medido en puntos de función COSMIC.

En los momentos posteriores en el ciclo de vida, cuando ya existe un alcance definido en términos de cuáles tareas el usuario deben ser parcialmente o totalmente transferidos para el software, es posible identificar procesos y aplicar la misma lógica en la extrapolación de la cantidad de puntos de función COSMIC a partir de la cantidad de procesos. 

Al final del proyecto, la medición se realiza con el objetivo de:

• Evaluar el desempeño mediante la relación entre la cantidad de horas invertidas y la cantidad de puntos función COSMIC medidos.

• Re-evaluar los indicadores de productividad para que pasen a incluir el desempeño del proyecto que acaba de terminar.

• Re-evaluar la cantidad de puntos función COSMIC que corresponden en promedio a los procesos y a los conceptos de negocio conforme al nivel de información disponible en los diferentes puntos que se desea estimar.

Estimaciones como una probabilidad

Existe una confusión sobre el concepto de estimación. Algunos confunden este asunto con una profecía. Cuando a partir de la información incompleta, alguien manifiesta una cantidad de horas-hombre o un plazo que no está asociado a un intervalo o a una probabilidad, no está generando
una estimación, está dando una profecía. Mientras que las profecías requieren un toque divino, las estimaciones sólo necesitan datos y técnicas.

Las estimaciones y los datos de Benchmarking

Hay datos de benchmarking que permiten calcular donde se posiciona la estimación en relación al desempeño de los proyectos presentes en aquella base de datos. Por ejemplo, se estimó un proyecto para el desarrollo en Java como si tuviera 150 puntos de función COSMIC y un esfuerzo 1.000 horas-hombre de entrega. Esto equivale a una tasa de entrega correspondiente a 07 HH/CFP. Esto indica que hay una probabilidad de 8% de que el esfuerzo no sea subestimado.

Evaluar estimaciones con datos de Benchmarking.

La figura indica la distribución de probabilidad derivada de la serie de proyectos presentes en la base de datos ISBSG - Grupo internacional de Estándares de Benchmarking de software. En la línea horizontal, se muestran los rangos con intervalos de productividad expresados en HH/CFP. En la línea vertical, se presentan los porcentajes de probabilidad asociados. El área señalada indica la probabilidad acumulada de no subestimar.

Algunas probabilidades son destacadas por su valor de referencia: El punto donde hay un 50% de probabilidad de subestimar o sobreestimar (la mediana) y el rango de 25% por encima y por debajo de este nivel (el primer y el tercer cuartíl) .

Conócete a ti mismo

Además de las referencias externas promovidas por organizaciones que proporcionan datos de benchmarking, existen los datos internos que tienen aún más valor en las estimaciones de producción, ya que reflejan con mayor precisión las condiciones locales. Por ejemplo, la línea horizontal en el gráfico indica la medición en puntos de función COSMIC. 

Cada punto, entonces, indica la cantidad CFP y el esfuerzo correspondiente. A partir de estos datos, es posible derivar una tendencia general que describa esa relación y pueda ser utilizada en la producción de estimaciones. En el gráfico son presentadas algunas líneas. Cada una de ellas describe la proyección de la productividad y los intervalos de confianza y predicción, considerando el 95% de confianza.

Evaluar estimaciones con datos de Benchmarking.

Conclusión

Existe una gran diferencia entre las respuestas para la siguiente pregunta ”¿Por qué se solicitan 5.000 horas hombre (HH) para el proyecto y no 2.000 HH?”:

Existen dos respuestas:

• Porque yo lo sé.

• Porque sólo hay un 2% de probabilidad de entregar el proyecto de este tamaño con 2.000 HH de acuerdo a datos históricos. Además, hay un proyecto de la base de datos internacional de evaluación comparativa que lo respalda.

¿Te gustaría certificarte profesionalmente como experto en medición de requerimientos de Software. Curso de Estimación de Software con Puntos de función.

¿Y qué opinas tú?

¿Cuál método de estimación y medición de software utilizas en tu organización? ¿Realizas estimaciones basadas en la opinión de expertos o en el análisis funcional?

¿Buscas más información de gerencia informática?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

También puedes seguirnos vía Twitter, Facebook o Linkedin:

  

Referencias

Alain Abran, Software Metrics and Software Metrology, IEEE Computer Society Publications (Wiley), 2010.

Barry W. Boehm, Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, Bert Steece, Software Cost Estimation with COCOMOII, Prentice Hall, 2000.

The Common Software Measurement International Consortium (COSMIC), The COSMIC Functional Size Measurement Method, Version 4.0.1.

Capers Jones, Estimating Software Costs: Bringing Realism to Estimating, Osborne (McGraw HIll), 2nd. Edition, 2007.

Carlos Vazquez, Guilherme Simoes, Renato Albert, Análise de Pontos de Funcao, Medicao, Estimativas e Gerenciamento de Projetos de Software, Sao Paulo, Editora Érica, 2013.

Artículos relacionados