Tamaño funcional COSMIC, elemento básico para la contratación del software

¿Por qué se sigue contratando el desarrollo de software por esfuerzo usando normalmente la unidad Hora Hombre (HH)?  

¿Qué problemáticas trae contratar el desarrollo de software por costo de esfuerzo invertido para el desarrollo en HH?

Como todos sabemos es muy común qué tanto en la administración pública como en el sector privado, los servicios de desarrollo contratados a una Fábrica de Software (FSW) y/o áreas de desarrollo interna, los desarrollos de software sean costeados definiendo un precio unitario para la HH y posteriormente costeando el proyecto multiplicando ese costo unitario por el esfuerzo en HH que estiman requiere el desarrollo de software, llegando de esta manera a un costo para el proyecto.

La forma descrita anteriormente tiene dos grandes problemáticas que han causado severos problemas en los sectores por las incongruencias a las que pueden llegar.

  1. Primera problemática: Lo que se está vendiendo en este tipo de desarrollos es el esfuerzo HH requerido para el desarrollo; en consecuencia, la problemática a tras de esto es que se está incentivando el tardarse más porque en función de eso sube el costo del proyecto. A manera de analogía observemos la siguiente figura:

El mismo producto y tipo de café, preparado en tres establecimientos de la misma cadena, sin embargo, que el costo se calcula por el tiempo que se consume en la preparación (análogo al tiempo de desarrollo en el software) y que tiene un costo unitario por minuto de preparación de $18 (análogo al costo unitario por HH de desarrollo). En consecuencia, el costo del café sería diferente en los tres lugares, uno de $54, otro de $108 y el último de $270; sin duda alguna nadie compraría su café en las dos últimas sucursales. Esa es una de las problemáticas en el software; costear por el esfuerzo consumido en el desarrollo lo cual incentiva tardarse más. Ahora miremos la siguiente figura:

Aquí la diferencia es que el costeo se hará usando una métrica estandarizada que representa la cantidad del producto no el esfuerzo en crearla; así entonces el mililitro (ml) de café, análogo al tamaño funcional del software, tendrá un precio, como el mostrado en la figura, el cual es independiente del tiempo de preparación, así entonces el costo en los tres establecimientos será de $48, no importando que se prepare más rápido en uno o en otro; de manera que en este esquema se promueva la productividad de quien prepara el café, es decir en la analogía de la FSW que construye el software.

  1. Segunda problemática: Los costos unitarios que se manejan por HH presentan comportamientos erráticos a través del tiempo; por ejemplo, si miramos la siguiente figura que es un análisis de los precios promedios unitarios manejados por HH en el desarrollo de software de la Administración Pública Federal (APF), datos obtenidos de los contratos publicados en “Compranet 2011 – 2018” para diferentes licitaciones.

Podemos ver con claridad que los costos unitarios promedio por HH de desarrollo se comportan de manera errática habiendo precios en 2018 ($226) más baratos que en 2012 ($269.26); lo cual incluso va en contra de incremento de costos por temas inflacionarios; lo cual nos indica claramente que muchos de estos costos unitarios son irreales y cuyo valor tan bajo fue colocado así para poder ganar algún tipo de licitación; sin embargo la problemática estalla cuando se tiene que cotizar el costo de un desarrollo y como el precio de la HH es tan reducido, no queda de otra para balancear el costo que incrementar el número de horas requerido para un proyecto en particular, llegando a cifras de esfuerzo irreales (muy altas) debido al precio bajo de la HH; lo cual sin duda traerá problemas con los órganos fiscalizadores.

Aún en estos casos cuando usan COSMIC para medir el tamaño funcional, necesitan forzosamente   usar factores esfuerzo requerido por cada unidad COSMIC, que en primer lugar no tienen fundamento de cómo se obtuvieron y en segundo lugar son altos para compensar el tema dicho anteriormente del precio tan bajo de la HH.

En conclusión, el desarrollo de software se sigue contratando por costo de esfuerzo unitario de HH incentivando tardarse más, porque los mecanismos y el entendimiento de cómo usar COSMIC de manera correcta aún no está maduro tanto en los contratantes como en los contratados, NO PORQUE ESTÉN CERTIFICADOS SABE CÓMO IMPLEMENTAR COSMIC!

Una situación de madurez en la contratación de software, implicaría que los desarrollos de software deberían ser contratados por un precio unitario de la CFP, el cual deberá ser obtenido de modelos formales, así entonces al contratar un desarrollo no habrá inconsistencias porque se está contratando por el tamaño de lo que se va a construir no por el esfuerzo invertido; es decir, por un software de unas características, por ejemplo de una tecnología específica, más pequeño se pagaría menos que por uno más grande de las mismas características, lo cual haría más productivos y competitivos a los desarrolladores de software y existirá total transparencia de lo pagado por un desarrollo.

La alta inmadurez que se tiene en la contratación genera que  por ejemplo un desarrollo de una pieza tan sencilla como un “login” más básico que mide 3CFP y usando un factor de 30 HH/CFP, lleva a la estimación diga que se requieren 90 HH para el desarrollo de esa pieza tan sencilla, es decir más de medio mes de trabajo de un recurso dedicado al 100% a esa pieza; lo cual es incongruente, cuando el esfuerzo consumido debería ser aproximadamente 30HH; pero este efecto se da porque el factor de 30 HH/CFP no tiene fundamento sino que fue estipulado así para compensar el precio bajo e irreal de la HH de esfuerzo.

Leave A Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *