Muchas veces en la literatura para desarrollo de software se ha hecho la analogía acerca de una construcción de una casa con la construcción de un software. En esta analogía, normalmente los distintos planos de la casa son los distintos modelos de diseño empleados para la construcción del software.
¿Qué pasaría si en los planos no vinieran medidas? Es muy probable que la construcción de la casa fuera un caos, por que las ventanas no serían del tamaño correcto, o la loza, o las puertas etc. Es fácil ver que no se podría construir una casa sin conocer las medidas del tamaño de cada uno de sus elementos. Más aún, en función de estas medidas se puede estimar la duración de la obra, el costo, se puede tener un control de las dimensiones de la casa, comparar contra otras construcciones, etc.
¿Se puede desarrollar el software sin tener medidas de tamaño? La respuesta es sí, en la mayoría de los casos así se hace, sin embargo, esto fomenta que el desarrollo de software sea un arte, y no un proceso ingenieril, con resultados nada prometedores (The Standish Group International, 2011)( Emam, 2008).
“According to testimony by the Government Accountability Office last September, if were established more realistic baselines of requirements, cost, schedule and risk during project’s planning phases, nearly half of canceled or over budget IT programs could be avoided. That would save $5.5 billion annually, according to a study made by Price Systems LLC, a software and consulting company in Mount Laurel, N.J., USA. The study consider 104 Government IT executives” (PMI, 2007)
Muchas personas involucradas en la industria del software tienen una idea errónea acerca de la medición del software, consideran que no se puede medir ya que es algo intangible, que es algo intelectual por lo que medirlo sería muy complejo, etc. Esto no es cierto, por ejemplo la velocidad de la luz la medimos, y no precisamente de manera física, se mide con un modelo adecuado y generalmente aceptado.
Entonces ¿Se puede medir el software? Sí, de hecho hoy en día la única medición estándar del software es el tamaño funcional (Functional Size Measurement, FSM, ISO/IEC 14143). Si cada organización midiera el software de manera distinta (por módulos, LOC, CU, etc.) no se podrían hacer comparaciones. Esto sería el equivalente a que las medidas utilizadas en cada plano fueran diferentes ¿Serviría?, por supuesto que no.
El FSM entonces, es muy importante, ya que es el único estándar de medición de software existente, es generalmente aceptado y nos habilita para realizar la parte ingenieril del desarrollo de software. A continuación vamos a mencionar algunos de los usos más importantes que se le pueden dar a una medición de tamaño funcional adecuada.
Estimación de proyectos
La estimación de proyectos es my importante para poder tener una buena administración de recursos a lo largo del proyecto.
Hay que recordar que en cualquier proceso de producción de algo (en este caso el software) existe una relación entre la cantidad producida y el costo/esfuerzo requerido para hacerlo.
Si se tiene una buena medición de tamaño funcional es posible generar modelos de estimación algorítmicos que permitan hacer estimaciones del esfuerzo o costo de los proyectos. Si las mediciones funcionales NO son confiables, los modelos de estimación NO son confiables.
Medición del desempeño del proyecto
En cualquier industria la habilidad para medir desempeño es crítica para poder mejorarlo. Por ejemplo cuántas veces hemos escuchado en el software temas relacionados a la productividad.
La productividad en el software cómo en cualquier otra industria es muy importante, todos quisiéramos que las organizaciones fueran más productivas, que las áreas de software fueran más productivas, es más que los programadores o desarrolladores fueran más productivos. Pero ¿qué significa esto?, bueno la productividad está definida por la cantidad de producto terminado dividida entre el esfuerzo necesitado para producirla (o algún otro recurso). El elemento clave es el tamaño, que para el software es tamaño funcional.
Hay otras mediciones que se pueden obtener de un proyecto como son velocidad de entrega que se puede medir dividiendo el tamaño del software en un tiempo determinado. La densidad de defectos que se obtiene de dividir el número de defectos entre el tamaño de software.
Un tema importante es que teniendo un estándar de medición confiable, el desempeño de las organizaciones y/o áreas puede ser comparado gracias a la estandarización de las mediciones de tamaño funcional, que como hemos visto para el desempeño del desarrollo de software son una parte fundamental.
Control del alcance de los proyectos
El alcance de los proyectos muchas veces es definido de manera subjetiva, si se mide el alcance del proyecto utilizando un método de medición de tamaño funcional cada modificación o cambio puede ser medido de igual manera lo que permite determinar la diferencia entre el alcance original o tamaño original y el nuevo tamaño, “scope creep”.
Se pueden definir umbrales de modificación de alcance por ejemplo 20%, lo que implicaría dividir el tamaño funcional del nuevo requerimiento o modificación entre el tamaño original, si excede el umbral no se aceptaría porque podría repercutir en el tiempo de entrega o en costos.
Con estos elementos se puede ayudar a determinar si procede un cambio o requerimiento nuevo, pero también ayuda a saber al final del proyecto cuánto creció en alcance de manera cuantitativa y no solamente de forma subjetiva. Actualmente esto es muy complicado de saber.
Control de contratos de software
Actualmente para la definición de contratos de desarrollo de software se hace un requerimiento, el proveedor del desarrollo pone el precio en base a su experiencia, con una negociación se determina el precio final.
Si se tuviera una medición del tamaño de software solamente basta con multiplicar el número de unidades de tamaño a desarrollar por su costo y ya está. Esto podría apoyar a la industria ya que se debería tender a una estabilización de los costos por unidad de tamaño de software.
Si se requiriera un cambio de alcance o modificación del software, ya se sabe el costo por unidad de tamaño funcional, no se reuinicia una negociación para determinar el costo del cambio que muchas veces suele sobrestimarse.
Conclusión
La medición de tamaño funcional del software es muy importante, al ser hoy en día el único estándar cuantitativo para determinar el valor de una característica del software, y si se utiliza adecuadamente puede ser el habilitador para que los proyectos de desarrollo de software sean exitosos, ya que ayuda entre otras cosas a : la estimación de proyectos, medición del desempeño del proyectos, control del alcance de los proyectos, y control de contratos de software.
Special Interest Group on COSMIC / México