Indicadores económicos del desarrollo software 1 y 2

Transcripción

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 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. 1

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: 2

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): Pr oductividadsoftware = TamañodelPrograma EsfuerzoDirectamenteRelacionado O desde una visión más general: FuncionalidadEntregadaAlCliente Pr oductivida dtotal = CosteDeDesarrollo 3

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: TamañodeEquipo*ProductividadMediadelEquipo ProductividaddelEquipoEfectiva = ProductividadCuandoTamañodelEquipo = 1 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: Pr oductivida ddelequipoefectiva= TamañodelEquipo α 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), 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, Brooks, F. P. (1987). No Silver Bullet: Essence and Accidents of Software Engineering. Computer, 20(4), 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), Grable, R., Jernigan, J., Pogue, C., & Divis, D. (1999). Metrics for Small Projects: Experiences at the SED. IEEE Software,

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 ) Institute of Electrical and Electronics Engineers. Kitchenham, B. (2004). Software Productivity Measurement Using Multiple Size Measures. IEEE Transactions on Software Engineering, 30(12), Little, T. (2006). Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. IEEE Software, 23(3), MAP. (2001). Ministerio de Administraciones Públicas. Métrica 3: guía de referencia. Tecnos: Madrid, Madrid: Tecnos. Van Solingen, R. (2004). Measuring the ROI of Software Process Improvement. IEEE Software, Yu, W. D. (1990). A modelling approach to software cost estimation IEEE journal on selected areas in communications, 8(2), Yu, W. D., Smith, P., & Huang, S. T. (1990). Software Productivity Measurements. AT&T Technical Journal, 69(3),