En los años recientes, el gasto en tecnologías de información ha trasladado su énfasis del hardware al software, provocando que la relación entre el segundo y el primero suba de 32.5% en 1996 a 40% en 19991. Sin embargo, a pesar de su importancia, es un bien intangible que se ha tornado difícil de medir. Ya sea que se decida comprar un paquete o que se haga un desarrollo a la medida interno o subcontratado, las organizaciones necesitan controlar esta inversión.
En ese sentido, medir el software no es un tema académico, sino un tema de valor, de inversión, de negocio. Es común que los proyectos de software fracasen al no estar a tiempo o dentro de presupuesto por una mala estimación de esfuerzo o duración, o de las capacidades requeridas de los ingenieros y de la empresa.
En este artículo veremos la importancia de contar con una métrica adecuada para el tamaño del software, así como las características que debe tener.
Lo Relevante es la Funcionalidad
Como en cualquier inversión, a las empresas lo que les interesa es la capacidad de hacer algo con lo que compran. Por ejemplo, si se compra un camión, de alguna forma se adquirió la capacidad de transportar mercancías y con un tamaño de metros cúbicos por viaje. En primera instancia lo relevante es qué tanto requiero transportar por viaje. En otro ejemplo, si se compra un edificio, entonces se adquirió la capacidad de disponer de un espacio de tantos metros cuadrados distribuido en pisos; lo relevante es cuánto espacio necesita la empresa o institución.
En SW no tiene por qué ser distinto, al adquirir un paquete o al desarrollar una aplicación lo primero que se debe evaluar es qué nuevas capacidades estoy adquiriendo. Estas capacidades o funcionalidad estarán en términos de qué transacciones puedo realizar de forma automatizada y de qué grupos de datos puedo guardar.
A pesar de esto, la mayoría de las empresas tienen una idea muy vaga sobre la funcionalidad en SW con la que cuentan y mucho menos cuánto de esa funcionalidad realmente se aprovecha. Tampoco cuentan con la productividad de sus programadores en términos de cuánta funcionalidad pueden desarrollar por unidad de tiempo. Esto les impide estimar, con fundamento, la inversión y el tiempo necesario para que su personal pueda desarrollar un proyecto de SW o para evaluar la propuesta de un externo. En consecuencia los retrasos en los proyectos, así como los excesos en presupuesto, son normales. De hecho, el problema del año 2000 fue un caso muy evidente donde las empresas no sabían cuánto gastarían para hacer las adecuaciones necesarias, ya que no había datos precisos de con cuánto software contaban.
Para evaluar una inversión en SW, normalmente se considera el costo de desarrollarlo contra el precio de comprarlo ya hecho. Pero en esta comparación el costo o precio es resultado de un esfuerzo estimado por un costo unitario. Los dos principales determinantes para estimar el esfuerzo son: el tamaño de lo que se requiere y la productividad de quien lo va a hacer. En este artículo nos concentraremos en el primero, ya que es el primer elemento de la ecuación.
Medir el Tamaño
El tamaño del software se podría medir en términos de los bytes que ocupa en el disco, el número de programas, el número de líneas de código, la funcionalidad que proporciona, o simplemente el número de pantallas o reportes que tiene. En primera instancia podríamos intuir que algunas de estas propuestas son mejores que otras si queremos medir el tamaño de una forma que tenga más correlación con el esfuerzo. Pero antes de seleccionar alguna, hagamos otras consideraciones.
Una aplicación de software es un conjunto de líneas de código que se ejecutan en una computadora, sin embargo, la codificación solamente representa entre el 20 y 25% del costo total de la producción del software. Otros elementos como la administración del proyecto, el nivel de detalle de la documentación técnica o la documentación de pruebas y las pruebas por sí mismas también deben considerarse.
Por otro lado, hoy en día hay una amplia gama de lenguajes y herramientas para producir SW. Esto provoca que se pueda generar la misma funcionalidad con lenguajes de programación distintos. Y esto con un número de líneas de código distinto y, lo que es más impactante, con un esfuerzo distinto.
Veamos un poco más a detalle las implicaciones del enunciado anterior mediante un ejemplo sencillo. Supongamos que yo requiero de cierta funcionalidad en una aplicación de SW y tengo la opción de hacerlo con dos empresas. La empresa A utiliza un lenguaje que requeriría 8,000 líneas de código. La empresa B utiliza otro lenguaje que requeriría aproximadamente 5,000 líneas de código. A simple vista parecería que con la empresa A tendría “más” trabajo, pero con la empresa B me podría salir más barato dado que tienen que hacer menos líneas de código. La comparación se complica si los programadores de ambas empresas producen a distintas velocidades. Es decir, los de la compañía A producen casi el doble de código por día que los de la compañía B. Como resultado de lo anterior, tendría que la línea de código de la empresa A podría costar mucho menos que la de la compañía B. Entonces parecería que debería comprarle a la empresa A dado que cuesta menos cada línea de código, pero también podría comprarle a la empresa B dado que tiene que producir menos líneas de código y por lo tanto el costo total sería menor o podría tener menos posibilidad de errores.
Ciertamente esta secuencia de análisis puede ser engañosa. Si retomamos los conceptos mencionados previamente, entonces una mejor métrica para establecer el tamaño es la basada en los requerimientos del usuario y no en la tecnología que se va a utilizar; una métrica basada en la funcionalidad.
Características de una Métrica Funcional
Para lograr obtener los mayores beneficios de ésta, una métrica funcional debe tener las siguientes características:
• Independiente de tecnología.– Como vimos en el ejemplo anterior, si nos basamos en líneas de código (en la tecnología), vamos a obtener resultados no comparables. Pero más que eso, tal vez lo relevante de esta característica es que una vez que se establece la funcionalidad requerida, se debe escoger la tecnología que nos haga más productivos para obtener esa funcionalidad.
• Simple.– No se debe requerir de grandes esfuerzos para obtener una medida. Una ventaja es que puedo establecer el tamaño de un SW que tal vez llegue a tener miles de líneas de código en pocas horas. Sin embargo, el costo de esta simplicidad es que la métrica no es muy sensible a consideraciones muy detalladas, como lo sería la complejidad de fórmulas matemáticas, por ejemplo.
• Enfocada en funcionalidad.– Antes de cualquier evaluación técnica, el primer criterio debe ser qué nuevas capacidades va a adquirir el negocio a través del producto de software en cuestión.
• Basada en los requerimientos del usuario.– Esta característica ayuda a que el usuario pueda entender el significado e implicaciones del tamaño del software, sin tener que ser un experto en sistemas. Otro aspecto muy importante de esta característica es que desde que se tienen los requerimientos, se puede determinar el tamaño de un software, sin tener que esperar a que éste sea terminado.
• Consistente.– Los resultados obtenidos entre diferentes personas o en proyectos distintos deben ser consistentes.
Usos de una Métrica Funcional Estándar
Una vez que se ha determinado el tamaño de un SW, se puede utilizar este dato para distintos propósitos. La lista siguiente es más enunciativa que limitativa.
• Administrar la productividad.– Al tener el tamaño de un sistema y el esfuerzo requerido para desarrollarlo e implantarlo, se pueden establecer indicadores de productividad en términos de horas por unidad. Este indicador sirve para controlar un plan de mejora y compararse con la industria2.
• Administrar la calidad.– Al contar con el tamaño y número de defectos en un producto, es posible establecer un indicador de “densidad de defectos”, y administrar la calidad en base a éste. Con una historia suficiente de proyectos, es posible hacer proyecciones para proyectos futuros.
• Comparabilidad.– Al utilizar la misma métrica en todos nuestros proyectos, podemos compararlos entre ellos. O mejor aún, si es una métrica estándar en la industria, podríamos compararnos contra proyectos de otras empresas. Esto se puede apreciar en la Tabla 1.
• Administración de proyectos.– En lugar de medir únicamente horas planeadas vs. horas consumidas, se puede administrar el proyecto en base a la funcionalidad del producto, conociendo así qué tanto del producto final ha sido diseñado, construido, probado e implantado en cualquier punto del proyecto.
• Administrar los cambios en el alcance.– Es posible estimar el tamaño de los cambios en un proyecto y a partir de ahí estimar el esfuerzo.
• Estimar la adecuación de un paquete.– Al comparar la funcionalidad disponible en un software empaquetado contra la funcionalidad requerida, es posible estimar qué tanto se debe modificar o agregar.
• Valuar el software de una organización.– Teniendo el tamaño de cada aplicación dentro de la organización, se puede evaluar este activo de manera veraz, en lugar de sólo usar el costo en que se incurrió al comprarlo o desarrollarlo.
• Estimar los recursos para un proyecto.– Con el tamaño estimado de un software es más fácil estimar el número de ingenieros que se requieren. No es el único dato que se debe considerar, pero sí el que más impacto tiene al estimar esto.
• Presupuestar el mantenimiento.– Una métrica funcional puede ayudar en el presupuesto para el mantenimiento de un portafolio de software de una organización. El tamaño de funcionalidad del portafolio, así como el costo o esfuerzo de mantenimiento comparado con el tamaño de funcionalidad, podrían ser monitoreados. Esta información podría ser usada para pronosticar presupuestos de mantenimiento.
• Administrar contratos.- El contrato con un proveedor puede ser basado en los requerimientos funcionales, tamaño de funcionalidad, una productividad esperada y un costo por unidad de tamaño de funcionalidad.
Conclusión
En la industria del software, tanto desarrolladores como compradores requieren mejores prácticas. Las métricas son un elemento fundamental de control en cualquier ingeniería y aquí no son la excepción.
El tamaño del software es un determinante fundamental en el esfuerzo de un proyecto de desarrollo de software al igual que para la adquisición de un paquete. El tamaño basado en la funcionalidad que se obtiene, centra las decisiones en obtener más funcionalidad por la inversión, una decisión de negocio. Entonces las decisiones tecnológicas se convierten en elegir la tecnología que me haga más productivo para el tipo de solución que requiero, principalmente.
En el próximo número hablaremos sobre los Puntos por Función, una métrica estándar para establecer el tamaño del SW, y explicaremos el método para determinarlo. Hasta entonces.
Referencias
1. Digital planet: The Global Information Economy. WITSA. Noviembre de 2000.
2. Datos de productividad se pueden obtener en The Software Metrics Compendium, www.isbsg.org
Acerca del autor
Sergio Eduardo Durán Rubio se desempeña como Director de Proyectos en certum. En 1996 se convirtió en el primer especialista de América Latina certificado por el International Function Point Users Group en Conteo de Puntos Función, y en miembro representante de México ante la ISO/IEC JTC1/SC7. Sergio es Ingeniero en Sistemas Computacionales de la UDLA-P, Maestro en Tecnologías de Información y Administración del ITAM y Mastère Spécialisé en Réseaux Et Systèmes D information pour Les Entreprises de la ENST de Bretagne France.
- Log in to post comments