1

Indicadores económicos del desarrollo

software 1 y 2

Javier Garzás, Daniel Cabrero

1 EL RETORNO DE LA INVERSIÓN El retorno de la inversión, conocido por sus siglas ROI, si bien es un indicador esencial

en el área económica, no se utiliza eficientemente en el campo de los proyectos software, ya que los ingenieros de software se sienten más cómodos con las métricas más cercanas al código que con las métricas económicas. (Erdogmus, Favaro, & Strigel, 2004) y (Boehm, Huang, Jain, & Madachy, 2004) recuerdan la falta de buenos modelos de ROI para software, lo que hace difícil la valoración de las inversiones. Incluso el sistema educativo no pone especial énfasis en enseñar a los ingenieros temas económicos (Harrison, 2005), si bien analizar el coste de la mejora es esencial (Van Solingen, 2004) para, entre otros:

� Convencer de la inversión, � Convencer de la mejora, � Estimar el esfuerzo, � Seleccionar los procesos de mejora a implementar, � Continuar mejorando. Y también para sobrevivir, ya que en una organización toda inversión debería ser

valorada junto con su retorno. La definición más conocida para el ROI es (Beneficio – Coste) / Coste, pero esta no

contempla dos componentes esenciales en cualquier análisis económico: el tiempo y el riesgo. En (MAP, 2001) se expone una ecuación más completa para calcular el ROI, considerándolo como el rendimiento de la inversión expresada en términos porcentuales:

ROI = 100 x (Beneficio Neto Anual - Coste Desarrollo Anualizado) / Inversión

Promedio Siendo: � Beneficio Neto Anual: la ganancia que aporta el sistema como consecuencia de su

uso, es decir los beneficios obtenidos más los gastos no incurridos. Deben restársele los gastos operacionales anuales y los de mantenimiento del sistema.

1 Esta obra está bajo una licencia de Creative Commons: Reconocimiento-No comercial-Compartir bajo la misma licencia 2.5 España (ver http://creativecommons.org/licenses/by-nc-sa/2.5/es/) 2 Este artículo es un extracto y resumen de Garzás, J., & Cabrero, D. (2007). El valor y el retorno de la inversión de las TSI. In El Gobierno de las TSI. Madrid: Ra-ma.

2

� Coste Desarrollo Anualizado: el total del gasto inicial de desarrollo del sistema, dividido por los años que se supone que va a ser operativo.

� Inversión Promedio: el total de la inversión realizada (costes de desarrollo, hardware, software, etc.) dividido por el total de conceptos en los que se invierte.

Aunque como comentan (Díaz & Trujillo, 2007), el verdadero retorno de la inversión

aparece cuando los proyectos no se retrasan, permitiendo aplicar más recursos de ingeniería a la adquisición y desarrollo de negocio.

2 ANÁLISIS COSTE-BENEFICIO La técnica del análisis coste/beneficio tiene como objetivo fundamental proporcionar

una medida de los costes en que se incurre en la realización de un proyecto y comparar dicha previsión de costes con los beneficios esperados de la realización de dicho proyecto.

En general los costes suelen ser cuantificables y estimables en unidades económicas,

no así los beneficios, los cuales pueden ser tangibles o intangibles. En un análisis coste/beneficio se debe considerar aquellos aspectos tangibles, es decir, cuantificables en valores como dinero, tiempo, etc., e intangibles, es decir, no ponderables de una forma objetiva. Aunque los beneficios intangibles sean difíciles de cuantificar no hay razón para no tenerlos en cuenta, debiendo involucrar para ello a las diferentes partes implicadas (stakeholders) (marketing, finanzas, etc.). Como ejemplo (Bendix & Borracci, 2005) al efectuar cálculos sobre el coste - beneficio en áreas de ingeniería como la gestión de la configuración software comentan como en algún momento encuentran elementos que son subjetivos de medir, pero que igualmente los consideran en las estimaciones coste – beneficio.

A la hora de realizar una estimación de los costes se debieran considera, entre otros,

elementos como los siguientes (MAP, 2001): � Adquisición y mantenimiento de hardware y software. � Gastos de comunicaciones (líneas, teléfono, correo, etc.) � Gastos de instalación (cableado, acondicionamiento de sala, recursos humanos y

materiales, gastos de viaje, etc.) � Coste de desarrollo del sistema. � Gastos (coste anual) del mantenimiento del sistema � Gastos de consultoría: En caso de requerirse algún consultor externo en cualquier

etapa del proyecto. � Gastos de formación: de todo tipo de personal (desarrolladores, operadores,

implantadores, usuarios finales, etc.). � Gastos de material: Papel, toner, etc. � Costes derivados de la curva de aprendizaje del personal involucrado � Costes financieros, de publicidad, etc. Y para la estimación de beneficios se deben considerar cuestiones como las

siguientes:

3

� Incremento de la productividad: Ahorro o mejor utilización de recursos humanos. � Ahorro de gastos de mantenimiento del sistema actual. � Ahorros de adquisición y mantenimiento de hardware y software, o reutilización de

plataformas sustituidas. � Incremento de ventas o resultados, y disminución de costes producidos por una

mejora de la gestión (rotación de stock, "just in time", gestión de relaciones con clientes, etc.).

� Ahorro de material de todo tipo: Sustituido por datos electrónicos que proporciona el sistema, como por ejemplo: papel, correo, etc.

� Beneficios financieros. � Otros beneficios tangibles: Ahorro de recursos externos, consultoría, formación,

etc. � Beneficios intangibles: Incremento de la calidad del producto o servicio, mejora de

la imagen de la compañía, mejora en la atención al cliente, mejora en la explotación, etc.

3 PRODUCTIVIDAD La productividad es otro de los indicadores más fuertemente relacionadas con los

aspectos económicos de la fabricación de software. No obstante, y a pesar de su importancia -incluso hay estándares con dedicación exclusiva a está medida (IEEE, 1992) - es también una de las más polémicas e imprecisas.

Autores como (Anselmo & Ledgard, 2003) resaltan cómo los argumentos asociados a

productividad no tienen base científica. Otros como Tom DeMarco plantean que si no se puede controlar lo que no se puede medir, entonces para mejorar la productividad tenemos que medirla, pero no hay medidas aceptables para medir la productividad. (Kitchenham, 2004).

No obstante, lo que no puede negarse es que mejoras en la productividad deben tener

reflejo en mejoras en el ROI del proyecto, y que la productividad es la principal métrica para medir la eficiencia en el proceso de desarrollo.

De una manera más precisa la productividad puede expresarse como la cantidad de

salida (lo producido) por unidad de entrada utilizada (Kitchenham, 2004). De donde la formula de la métrica sería (Yu, 1990):

lacionadorectamenteEsfuerzoDi

ogramaTamañodeldSoftwareoductivida

Re

PrPr =

O desde una visión más general:

arrolloCosteDeDes

edaAlClientdadEntregaFuncionalidTotaloductivida =Pr

4

La funcionalidad incluye documentación, software, formación, etc., donde el problema

que surge es cómo medir estos entregables. Por ello para medir la productividad se debe definir previamente dos medidas (Yu, Smith, & Huang, 1990): la salida y la entrada al proceso de desarrollo software; la primera se suele medir en Líneas de Código (LOC, Lines of Code), documentos y requisitos entregados. Desde el punto de vista del código tenemos, por un lado, código de producción (lo que se entrega al cliente) y código de soporte (código de pruebas, etc.); y, por otro, código base (el desarrollado en una versión previa), modificado, nuevo, de depuración (el que se usa para solucionar un error), portado (de otros proyectos), etc. Para la entrada se utilizan esfuerzo en personas/año y recursos económicos.

Pero aparte de las anteriores métricas, tan aparentemente simples como clásicas,

diferentes autores han ido definiendo modelos más complejos y sofisticados. Así (Little, 2006) presenta:

1Pr

Pr*Pr

==

poañodelEquidCuandoTamoductivida

quipodMediadelEoductividauipoTamañodeEqEfectivaddelEquipooductivida

Además (Little, 2006) recupera la relación entre la productividad y el tamaño del

equipo (Brooks, 1987) (Conte, Dunsmore, & Shen, 1986) y la reformula en:

αquipoTamañodelEEfectivadDelEquipooductivida =Pr Donde proponen que se tome un alfa de 0.5, si bien, como comenta (Grable, Jernigan,

Pogue, & Divis, 1999), los coeficientes de COCOMO nos son válidos para todas las compañías, y habría que calibrarlos.

4 REFERENCIAS Anselmo, D., & Ledgard, H. (2003). Measuring Productivity in the Software Industry.

Communications of the ACM, 46(11), 121-125. Bendix, L., & Borracci, L. (2005, September). Towards a Suite of Software

Configuration Management Metrics. Paper presented at the SCM, Lisbon, Portugal. Boehm, B., Huang, L., Jain, A., & Madachy, R. (2004). The ROI of Software

Dependability: The iDAVE Model. IEEE Software, 54-61. Brooks, F. P. (1987). No Silver Bullet: Essence and Accidents of Software

Engineering. Computer, 20(4), 10-19. Conte, S. D., Dunsmore, H., & Shen, V. Y. (1986). Software Enfgineering Metrics and

Models: Benjamin Cummings. Díaz, Ó., & Trujillo, S. (2007). Líneas de producto software. In J. Garzás & M. Piattini

(Eds.), Fábricas de software: Experiencias, tecnologías y organización: Ra-ma. Erdogmus, H., Favaro, J., & Strigel, W. (2004). Return on Investment. IEEE Software,

21(3), 18-22. Grable, R., Jernigan, J., Pogue, C., & Divis, D. (1999). Metrics for Small Projects:

Experiences at the SED. IEEE Software, 21-29.

5

Harrison, W. (2005). What Do Software Developers Need to Know about Business? IEEE Software, 22(5), 5-7.

IEEE. (1992). IEEE Standard for Software Productivity Metrics (IEEE 1045-1992) Institute of Electrical and Electronics Engineers.

Kitchenham, B. (2004). Software Productivity Measurement Using Multiple Size Measures. IEEE Transactions on Software Engineering, 30(12), 1023-1035.

Little, T. (2006). Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. IEEE Software, 23(3), 48-54.

MAP. (2001). Ministerio de Administraciones Públicas. Métrica 3: guía de referencia. Tecnos: Madrid, 2001. Madrid: Tecnos.

Van Solingen, R. (2004). Measuring the ROI of Software Process Improvement. IEEE Software, 32-38.

Yu, W. D. (1990). A modelling approach to software cost estimation IEEE journal on selected areas in communications, 8(2), 309-314.

Yu, W. D., Smith, P., & Huang, S. T. (1990). Software Productivity Measurements. AT&T Technical Journal, 69(3), 110-120.