Barra Superior

PMOinformatica.com
La oficina de proyectos de informática
La web sobre gerencia de proyectos de informática, software y tecnología.
Síguenos en:     

lunes, 13 de mayo de 2019

Estimaciones de Software con COSMIC

Este articulo esta basado en el contenido del Curso de Estimación de Software con COSMIC suministrado por FATTO. ¿Te gustaría certificarte como experto en el método COSMIC para medición de software? Visita la pagina del curso. Disponible en modalidad presencial y e-learning.

Estimaciones de Software con COSMIC

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.

Estimaciones de Software con COSMIC Estimar actividad 12 horas
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.

Estimaciones de Software con COSMIC Estimar entrega producto final
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.

Estimaciones de Software con COSMIC no se pueden identificar
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.

Estimaciones de Software con COSMIC prolongación mayor concentración proyectos pequeños
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.

Estimaciones de Software con COSMIC pocos proyectos y sin embargo mucho esfuerzo
Pocos proyectos y sin embargo mucho esfuerzo.


Formación en medición de software



Curso de estimación de software con COSMIC

¿Te gustaría aprender la técnica de vanguardia para realizar estimaciones de tiempo y costo de software realistas?

Curso de Estimación de Software con COSMIC

Presencial (Ciudad de México)        E-Learning

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.

Estimaciones de Software con COSMIC costo unitario medio de construcción
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.

Estimaciones de Software con COSMIC apropiación directa e indirecta
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.

Estimaciones de Software con COSMIC fuentes de información de los requerimientos
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.

Estimaciones de Software con COSMIC la evolución de los requerimientos
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.

Estimaciones de Software con COSMIC vision general
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.

Estimaciones de Software con COSMIC proceso de medicion
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).

Estimaciones de Software con COSMIC fronteras
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.

Estimaciones de Software con COSMIC movimiento de datos

Movimiento de datos.

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

Estimaciones de Software con COSMIC un movimiento de datos
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.

Estimaciones de Software con COSMIC diferencia entre aproximar o hacer la medicion
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.
Estimaciones de Software con COSMIC Evaluar estimaciones con datos de Benchmarking
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.

Estimaciones de Software con COSMIC Evaluar estimaciones con datos de Benchmarking
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 COSMIC.

¿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

No hay comentarios :

Publicar un comentario

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.