PROPUESTA DE ETAPAS PARA PRESUPUESTAR PROYECTOS DE SOFTWARE DE GESTIÓN

Transcripción

1 PROPUESTA DE ETAPAS PARA PRESUPUESTAR PROYECTOS DE SOFTWARE DE GESTIÓN José Mª. Torralba Martínez 1, Darío M. Arango Serna, Universidad Politécnica de Valencia Victor Ruíz Molina, Clase 10 Sistemas Resumen Se propone una estructura en fases para presupuestar proyectos de software a medida de gestión, basada en la que se utiliza generalizadamente en otras ingenierías, tanto en proyectos públicos como privados. 1. INTRODUCCIÓN La estructura en fases del presupuesto de los proyectos de ingeniería de tecnologías físicas distintas de la informática, suele ser la que establece la normativa de contratación pública, y esta estructura en el año 2002 se incorpora a la norma UNE Los proyectos de software, en concreto de gestión, no suelen tener una estructura tan generalizada, lo que justifica esta comunicación en que se plantean las etapas del proceso presupuestario de proyectos de software de gestión. Actualmente se está realizando una adaptación de dicha norma UNE a los Proyectos de Sistemas de Información Informatizados, que espera estar terminada hacia finales de Objeto. Se formula una propuesta del proceso presupuestario del proyecto de software a medida de gestión, que se basa en el utilizado en los proyectos de otras ingenierías. Se refiere solo al subsistema de software, no considerando aquí otros subsistemas que formen parte del proyecto, como hardware, comunicaciones, mobiliario, etc. [Torralba, 2003]. 2. PROPUESTA DE ETAPAS PARA PRESUPUESTAR SOFTWARE DE GESTIÓN Para determinar el presupuesto para el proveedor del software a medida se deben realizar las etapas que se indican en la tabla 1. 1 Esta comunicación se realiza en el marco del Proyecto DPI C05-05 de la CICYT.

2 Conviene recordar que las tres primeras etapas, que no exigen una valoración monetaria, son estudiadas normalmente en asignaturas técnicas anteriores a las de proyectos, por lo que no se entra aquí en su consideración detallada, haciéndose únicamente una muy breve referencia, ya que son etapas previas a la de valoración monetaria del presupuesto. ETAPAS PARA PRESUPUESTAR EL PROYECTO DE SOFTWARE A MEDIDA ETAPAS SIN VALORACIÓN MONETARIA - Medición del software - Determinación de la productividad de los recursos a utilizar - Estimación del esfuerzo o estimación de los recursos necesarios ETAPAS CON VALORACIÓN MONETARIA - Determinación de costes de los recursos - Determinación del coste de las unidades de medida del proyecto - Presupuestos parciales - Presupuesto general Fuente: Basado en [Torralba, 2003]. Tabla 1. Etapas para presupuestar el proyecto de software a medida Breve referencia de las etapas sin valoración monetaria Medición del software La medición del proyecto de software, a los efectos de realizar el presupuesto del mismo, es una fase muy importante, sobre la que se está investigando mucho, y las revistas internacionales de prestigio en la ingeniería del software han adoptado esta preocupación y también podemos reseñar la existencia de una publicación (Empirical Software Engineering) y de un grupo de interés de IEEE 2 Computer Society sobre métodos cuantitativos. [Dolado y Fernández, 2001]. La medición se viene realizando, como se intuye, desde antiguo en otros proyectos de otras profesiones, y tiene un significado preciso. Sin embargo, en el software el término medición tiene varios significados que se refieren brevemente a continuación. A. La medición en proyectos informáticos se aplica en múltiples ámbitos. Aquí nos interesa el tema de la medición a los efectos de presupuestarlo, por lo que procede reseñar brevemente qué existen otros ámbitos también en que se llevan a cabo mediciones. Un tratamiento detallado del tema se realiza por Fenton y Pfleeger [1997] apareciendo un resumen en la tabla 2. En este cuadro se hace una doble división: 1) A qué se dirige la medición?, contemplándose 2 IEEE son las siglas del Instituto de Ingenieros Eléctricos y Electrónicos.

3 las siguientes posibilidades: Productos, procesos y recursos; 2) Qué atributos son medidos?, considerándose la clasificación en: internos 3 y externos. La medición se dirige a PRODUCTOS La medición se dirige, más en concreto, a Las especificaciones Los diseños El código fuente Algunos de los atributos internos que se pueden medir Tamaño, Funcionalidad, Reusabilidad Tamaño, Reusabilidad, Modularidad, Acoplamiento Tamaño, Reusabilidad Tamaño, Nivel de cobertura Algunos de los atributos externos que se pueden medir Facilidad de mantenimiento Facilidad de mantenimiento Facilidad de mantenimiento Los datos de prueba Calidad, Coste De la especificación Esfuerzo, Tiempo Calidad, Coste PROCESOS Del diseño Esfuerzo, Tiempo Calidad, Coste De las pruebas Esfuerzo, Tiempo Calidad, Coste Personal Experiencia, Salario Productividad RECURSOS Equipos de personas Tamaño Productividad Software Precio Fiabilidad Hardware Precio, Velocidad Fiabilidad Fuente: Basado en [Torralba, 2003] (Reproducción adaptada de: Dolado y Fernández, 2001 y Pressman, 1993] Tabla 2. Algunos de los atributos, internos o externos, que se miden en los productos, procesos o recursos, en los proyectos informáticos y su ejecución. B. La medición del tamaño del software. La bibliografía de Proyectos de programas informáticos establece las siguientes grandes fases para realizar la planificación [McConnell, 1996; Pressman, 2001]: a) Medición del tamaño, b) Estimación del esfuerzo (medido, en lo relativo al personal, por ejemplo, en personas-mes), c) Programación temporal; que, ordinariamente, deben realizarse en dicha secuencia. En relación con la medición del tamaño hay varios métodos, que se diferencian entre sí debido a que la medición se puede dirigir hacia ámbitos y subámbitos distintos (por ejemplo, a distintos tipos de productos) y también porque los atributos que se miden pueden ser diferentes. Dolado y Fernández [2001] indican diversos tipos de medidas del tamaño, algunos de los cuales son los siguientes: a) Líneas de código, b) Puntos de función, c) Puntos objeto. Roetzheim y Beasley [1998], indican un cuarto tipo de medida que denominan GUI metrics (esto es, Métrica de Interfaz Gráfica de Usuario), propuesta por 3 Dolado y Fernández (2001) presentan las siguientes definiciones: Un atributo o propiedad es interno si se puede medir en términos de la entidad en sí (las entidades aparecen en la columna segunda de la tabla); es externo cuando sólo se puede caracterizar según la relación de la entidad con su entorno.

4 estos autores en 1993 (junto con Booz, Allen & Hamilton). También hablan de dos aproximaciones heurísticas. B.1. Medición del tamaño en líneas de código La medición del tamaño en Líneas de código (LDC) es una medida del producto código fuente, por lo que es una medida de productos de la fase de implementación o codificación, esto es, de la ejecución del proyecto; se necesita información de todas las principales fases del desarrollo del programa. B.2. La medición del tamaño en puntos de función La medición del tamaño en Puntos de Función (PF) es una medida que se puede realizar fundamentalmente con la información disponible en la fase de Especificación de Requisitos Funcionales. Puntos de Función Albrecht (así denominados por haber sido formulados por Albrecht en 1979), en el planteamiento seguido por la IFPUG 4, considera cinco elementos: entradas externas, salidas externas, consultas externas, interfaces externas, y ficheros internos; estos cinco elementos se ponderan según la complejidad se consideran tres niveles: baja, media o alta ; lo que permite calcular los Puntos de Función sin ajustar (PFSA). Además, se tienen en cuenta también catorce características que describen el entorno en el que se desarrolla la aplicación [Dolado y Fernández, 2001], lo que permite determinar los Puntos de Función Ajustados (PFA). Esta medida es clasificada por estos autores como Medición de Especificaciones de Software. E indican que existen diversas variantes: a) Mark II, b) SPQR, c) Full Function Points (FFP). Otra variante, denominada de Puntos Característica, se consideran también los algoritmos y su complejidad. B.3. La medición del tamaño en puntos objeto Dolado y Fernández [2001] indican que la medición se realiza en base a determinados elementos (principalmente de tres tipos: pantallas, informes y componentes 3GL); se ponderan según la complejidad se consideran tres niveles: baja, media o alta ; y se tiene en cuenta la reutilización. Estos autores indican Los métodos o modelos de medición/estimación propuestos pueden ayudar al ojo clínico del jefe de proyecto, que es el único que con su experiencia y conocimiento puede ajustar la estimación. En lo que sigue, supondremos que la medición del software a medida se realiza mediante Puntos de Función Ajustados Determinación de productividades físicas de los recursos necesarios. Como se conoce, la productividad de un recurso productivo se determina por el siguiente cociente: 4 IFPUG = International Function Point User Group.

5 Cantidad del producto obtenido (o a obtener) Productividad física del recurso Z = - (1) Cantidad del recurso Z utilizado (o a utilizar) En la expresión anterior hay que establecer: a) el producto, y b) el recurso. El producto sería el número de Puntos de Función Ajustados (PFA) obtenidos (si se trata de algo histórico, que ya ha ocurrido), o a obtener (si se trata de algo futuro, como es el caso de un proyecto). El recurso puede ser alguno de la relación siguiente: a) Recursos humanos, en sus distintas categorías profesionales, b) Recursos de capital, b.1) Hardware, b.2) Software, etc. En lo que sigue, nos referimos principalmente al recurso humano (personal o trabajo), ya que todavía tiene una participación muy importante en el desarrollo del software a medida. No obstante, no hay que dejar de tratar adecuadamente la utilización de otros recursos de capital, como software de ayuda al desarrollo, como pueden ser los distintos tipos de herramientas CASE 5, etc. Por lo tanto, un índice de productividad que es básico es el siguiente: Nº. de Puntos de Función Ajustados (PFA) Productividad física del personal = (2) Nº. de personas mes La unidad persona mes es, como se sabe, el equivalente del trabajo realizado por una persona durante un mes; por lo tanto, quiere decir que también se puede referir a lo siguiente: a) una persona durante un mes, b) dos personas durante medio mes, c) cuatro personas durante un cuarto de mes, etc., aunque, como se conoce, cada una de las combinaciones referidas no tienen por qué obtener el mismo resultado de trabajo. A. Se suele utilizar el inverso de la productividad física Conviene indicar que en las empresas se suelen utilizar los datos de: Utilización del recurso por unidad de producto, esto es: Nº. de horas de trabajo por PFA. Por ejemplo, en el desarrollo de software con una herramienta de 4ª generación hay referencias documentales que indican que se necesita un tiempo situado en torno al intervalo siguiente: 5-10 horas por PFA (aunque esto puede variar mucho de unas situaciones a otras). Y como se ve fácilmente, este dato es el inverso de la productividad física. En efecto, el dato anterior se obtiene mediante la expresión: Nº. de horas del recurso (personal) Utilización del recurso por unidad de producto = - (3) Nº. de PFA que es una expresión inversa a la de productividad física, ya que éste se obtiene, como ya se ha dicho, así: Nº. de PFA Productividad física = Cantidad de recurso (4) 5 CASE: Computer Aided Software Engineering.

6 Estimación del esfuerzo o estimación de los recursos necesarios. Conocidos los siguientes datos: Nº. de PFA Productividad (o su inversa) es fácil determinar el esfuerzo, o estimación de los recursos necesarios, mediante la expresión: Estimación del esfuerzo o de Nº. de PFA 1 los recursos humanos necesarios = = Nº. de PFA * (5) Productividad Productividad Por lo tanto, si se dispone del dato Utilización del recurso por unidad de producto (que como se ha indicado, no es la productividad, sino su inversa), lo que se hace es multiplicar el Nº. de PFA por la Utilización del recurso por unidad de producto. Conviene tener en cuenta los siguientes aspectos: Al pasar de tiempos en horas, a tiempos en otras medidas temporales (días, semanas, meses, años, ) se debe considerar: a) tiempos efectivos, b) festivos, c) vacaciones, etc. La programación temporal del Proyecto y de la Ejecución Las necesidades de personal para cada etapa del ciclo de vida. Aunque aquí nos referimos solo al recurso trabajo personal, hay que hacer la estimación de todos los recursos que se utilizan, como ya se ha indicado. 3. ETAPAS CON VALORACIÓN MONETARIA Determinación de los costes de los recursos. El cálculo de costes es objeto de otras asignaturas previas a la de proyectos. Se suele considerar la siguiente clasificación: costes directos costes indirectos A. Costes directos Los costes directos del proyecto pueden ser los siguientes: Personal de distintos perfiles profesionales o Analistas

7 o Analistas programadores o Programadores, o Etc. Otros recursos directos Desplazamientos Etc. En el caso de los costes del personal debe considerar todos los conceptos de coste como: salarios seguridad social a cargo de la empresa otros conceptos etc. En otras tecnologías físicas, al hacer el presupuesto de los proyectos, se confecciona lo que se denomina Cuadro de Precios nº. i, que contiene los salarios (costes de mano de obra) (se ha indicado nº. i ya que en la bibliografía unas veces es el nº.1 [Gomez-Senent, 1999] pero en otros casos se denomina cuadro nº. 2 [ITEC, 1995] B. Costes indirectos. Pueden distinguirse dentro de los costes indirectos dos tipos: Costes indirectos del proyecto Costes (indirectos) generales de la empresa B.1. Costes indirectos del proyecto. Conocido es que en el desarrollo de software se necesitan, además del personal, otros recursos como: sistemas informáticos (con su hardware, software y comunicaciones) software de ayuda al desarrollo herramientas CASE dirección de proyecto, etc. que generan costes indirectos del proyecto. B.2. Costes generales de la empresa. La empresa de desarrollo de software (o el proyectista en su despacho profesional) tiene unos gastos de creación, mantenimiento y desarrollo de la empresa Por ello, hay que considerar los costes correspondientes a los siguientes elementos: Personal administrativo Dirección Edificio Instalaciones generales

8 Servicios generales Etc. que generan, como se conoce, costes de diversos tipos: costes generales de desarrollo costes comerciales costes administrativos costes de financiación costes de dirección costes generales (impuestos, etc.) todos los cuales se deben considerar adecuadamente en la parte que corresponda imputar al proyecto. B.3. Los costes indirectos en la práctica Es frecuente que los costes indirectos se calculen partiendo de los costes directos como una proporción de estos; aplicando pues un coeficiente al importe de los costes directos. Entonces: Costes directos = CD Costes indirectos = CI CI = CD * TCI (6) siendo TCI = tasa unitaria de costes indirectos. Esto es, si en una empresa de desarrollo de software se tiene calculada la TCI (o diversas TCI según tipo de proyectos), el proyectista, para calcular el coste total (CT) sólo necesita determinar el importe de los CD, ya que a continuación calcula el CT así: CT = CD + CI = CD + CD*TCI = CD*(1+TCI) (7) El cálculo de los costes indirectos puede ser realizado por otro personal de la empresa, sin que tenga que entrar directamente a hacerlo el proyectista, el cual se limita a tener en cuenta la tasa unitaria TCI Presupuesto parcial del software a medida. Llegados aquí, ya se ha determinado: Esfuerzo de cada uno de los recursos (ERi) Coste por unidad de cada uno de los recursos, que se representa por PRi, ya que es usual la terminología de precio en vez de coste. En otras profesiones se le denomina Precio Básico 6. 6 En el pasado se le denominaba Precio Simple.

9 Por lo que el presupuesto parcial se obtendrá así: Presupuesto Parcialj = PTOj = ERi*PRi (8) Se indica el subíndice j para el caso de que se consideren presupuestos separados de diversos módulos, aplicaciones, etc. (se denominan presupuestos parciales del software a medida) 3.3. Presupuesto general del software a medida. Siendo los correspondientes Presupuestos parciales (PTOj), se obtendrá el Presupuesto General (PG): PG = PTOj (9) 4. PRECIO DE LAS UNIDADES DE MEDIDA DE SOFTWARE. EL PRECIO O COSTE POR PUNTO DE FUNCIÓN AJUSTADO. Conocido el esfuerzo de recursos necesario (ER) y los costes del proyecto, se pueden calcular los siguientes valores: Costes directos del Proyecto (CD) Coste directo por PFA= Nº. de PFA (10) Costes indirectos del Proyecto (CI) Coste indirecto por PFA= Nº. de PFA (11) CT (CD+CI) Coste total por PFA = Nº. de PFA (12) Interesa que este dato se incorpore al presupuesto ya que servirá de referencia para el caso de que se modifique o reforme el proyecto, lo cual ocurre con frecuencia como bien se conoce. A modo de conclusión Los procedimientos para presupuestar proyectos en España están muy ligados a la normativa pública, aunque esta solo obliga a los proyectos públicos. En esta comunicación se ha adaptado el proceso presupuestario de otras

10 tecnologías físicas al caso del software a medida, que al ser una tecnología más reciente, no tiene unos procedimientos generalizados que estén adaptados a ella. Reconocimientos Se quiere dejar constancia de la colaboración de D. José Manuel Santaúrsula Sala, D. Salvador Pons Alberola y D. Jesús Marqués Parada. Se quiere reconocer la ayuda para asistencia a Congresos facilitada por la Facultad de Informática de la UPV. REFERENCIAS [1] AENOR. Norma UNE Madrid, [2] Dolado, J. y Fernández, L. Medición para la Gestión de Proyectos Software. Ra-Ma, Madrid, [3] Fenton, N. E., Pfleeger, L. S. Software Metrics: A Rigorous and Practical Approach 1997 [4] Gómez-Senent, E. Las Fases del Proyecto y su Metodología. Universidad Politécnica de Valencia, [5] McDonnell. Desarrollo y Gestión de Proyectos Informáticos. McGraw-Hill, [6] Pressman, R. Ingeniería de Software. McGraw-Hill, [7] Serra, V. Contabilidad de Costes. Cálculo, análisis y control. Tirant lo Blanch, Valencia, 2003 [8] Torralba, J. Mª. Introducción al Presupuesto del Proyecto Informático y Telemático. Universidad Politécnica de Valencia, [9] Torralba, J. Mª. Introducción a los costes para Informáticos [10]Torralba, J. Mª., Chiner, M. y Ferrer, R. Del presupuesto al precio de oferta en proyectos de software [11] Torralba, J. Mª. Economía y Gestión de Proyectos. Apuntes, Universidad Politécnica de Valencia, 2004.