Medición de la Productividad de Proyectos de Software Desarrollados en Dos Empresas Ecuatorianas. Lohana Lema Moreta, Manuel Overa, Mónica Villavicencio 1 1 Centro de Investigación, Desarrollo e Innovación de Sistemas Computacionales CIDIS, Facultad de Ingeniería en Electricidad y Computación FIEC, Escuela Superior Politécnica del Litoral (ESPOL), Campus Gustavo Galindo, Km 30.5 vía Perimetral Apartado 09-01-5863. Guayaquil, Ecuador, {lmlema, molvera}@fiec.espol.edu.ec, mvillavi@espol.edu.ec Resumen. Este artículo presenta los resultados de la medición de la productividad durante el desarrollo de productos de software en dos empresas ecuatorianas pequeñas. El modelo de estimación utilizado para el cálculo de la productividad fue COCOMOII. Aplicando este modelo se extrajo información del ambiente de desarrollo de cada empresa permitiendo conocer factores positivos y negativos que influían en la productividad. Para facilitar la recolección de datos, varias Hojas de ayuda fueron diseñadas. Adicionalmente, sesiones de capacitación fueron requeridas para asegurar que los programadores de cada empresa obtuvieran correctamente los datos necesarios para el cálculo de la productividad. Los dos proyectos analizados requirieron menor esfuerzo al estimado por el modelo COCOMO II. Lecciones aprendidas, discusiones e implicaciones son presentadas en este artículo. Palabras Claves: mediciones, software, modelos de estimación, pequeñas empresas, Ecuador, VSE 1 Introducción Las medidas que tomamos a diario, nos ayudan a entregar información o a describir los atributos de un objeto determinado. En ingeniería de software, aspectos relacionados a los productos desarrollados generalmente se consideran no medibles [1]; por ejemplo: es difícil cuantificar un buen software o a un software exitoso [3]. Para evaluar la situación de los proyectos, productos o procesos, necesitamos medir. Como Fenton [1] explica, estas mediciones nos ayudan a comprender lo que está pasando en los proyectos, controlar lo que está sucediendo y sobretodo nos anima a mejorar los procesos y productos. Basados en lo expresado por Fenton, elegimos medir la productividad en dos empresas ecuatorianas utilizando el modelo de estimación COCOMO II Post arquitectura. El término productividad, para este estudio, ha sido considerado como la cantidad de líneas de código producidas en un tiempo dado. El modelo COCOMO II define la productividad como el tamaño dividido para el Esfuerzo [7].
El objetivo principal del presente estudio es introducir un métodos de estimación en pequeñas empresas de desarrollo de software, las cuales se caracterizan por no medir [13] [14] Para cumplir este propósito, solicitamos la colaboración de 2 pequeñas empresas desarrolladoras de software ubicadas en la ciudad de Guayaquil, Ecuador. Cada empresa participó con un proyecto. Debido a que el modelo COCOMO requiere de una calibración inicial, un mini proyecto fue realizado por empresa en su respectivo ambiente de desarrollo. El presente trabajo fue planificado en 5 etapas, figura 1.1. Análisis y selección del modelo de estimación Planificación Base Pre-Prueba y Validación Medición Final Análisis de resultados Fig. 1.1. Fases del proyecto de medición. Para dar inicio al estudio, era fundamental definir que método de estimación que se utilizaría para el cálculo de la proporción del tamaño sobre el esfuerzo [4]. Debido al convenio de cooperación firmado entre ESPOL, universidad a la que pertenecemos, con un conjunto de universidades belgas (proyecto VLIR-ESPOL), decidimos utilizar el resultado del análisis comparativo entre 3 modelos de estimación [12] realizado en KuLeuven, una de las universidades belgas asociadas. Los modelos IFPUGFP [6] [9], COSMIC FP [5] [10] y COCOMO II [7] [8] fueron comparados entre sí bajo 4 criterios: medición del tamaño, puntos de vista, datos históricos y facilidad de medición; como lo muestra la figura 1.2. Este análisis mostró que COCOMO II tiene una aparente ventaja sobre los demás modelos, al basar su estimación desde el punto de vista del desarrollador y al considerar la influencia de una variedad de manejadores de costo (multiplicadores de esfuerzo y factores de escala) en el resultado del esfuerzo [7]. Como fue mencionado, para este estudio, utilizamos 2 empresas desarrolladoras de software, las cuales identificaremos como PS y CF. Ambas son consideradas como VSE - very small enterprises. VSE - por sus siglas en inglés- es definida como aquella empresa que tiene menos de 10 empleados [2]. PS, cuenta con más de 10 años de experiencia en el desarrollo de software a la medida en entorno web de tipo comercial. El 40% de sus clientes son locales y el 60% extranjeros. La empresa CF es relativamente joven, tiene aproximadamente 3 años en el mercado ecuatoriano, se especializa en el desarrollo de aplicaciones web para manejo de procesos industriales. Ambas empresas utilizan la experiencia de su personal para estimar y planificar sus procesos de desarrollo de software, por lo tanto desconocían el modelo COCOMO.
2 Configuración inicial de la medición Definido el modelo a usar para la medición del esfuerzo, continuamos con la siguiente etapa del proyecto, Planificación Base. Como ambas empresas desconocían el uso de COCOMO II, fue necesario desarrollar un esquema para la recolección del número de líneas de código, así como de los valores requeridos para las demás variables utilizadas en el proceso de estimación con COCOMO II. El esquema en mención contiene tres tablas: 1) tabla de multiplicadores de esfuerzo, 2) tabla de factores de escala y 3) tabla base. Las dos primeras están definidas en el modelo COCOMO II, mientras que la última fue construida por nuestro equipo de trabajo. Dicha tabla base, permite recolectar las líneas de código y el tiempo invertido en cada una de las tareas que constituían el proyecto. Los campos contenidos en esta tabla se muestran en la figura 1.3. El desarrollo de esta tabla nos condujo a establecer reglas que debían ser seguidas por los desarrolladores, con la finalidad de obtener líneas de código basadas en criterios similares. La Tabla de Factores de Escala fue llenada para cada proyecto. La escala de medición utilizada es la que establecida por COCOMO, es decir que empieza con VL (very low), L (low), N (nominal), H (high), VH (very high) y finalmente EH (extra high) [7]. Tomando en cuenta la escala descrita, se deben calificar los siguientes parámetros: Precedentes (PLEC): El proyecto que se analizará es similar a otros que se haya realizado antes? Flexibilidad de Desarrollo (FLEX): El proyecto es flexible respecto a sus requerimientos?
Resolución de Riesgos y Arquitectura (RESL): Se ha tomado mucha atención a la arquitectura? Se han tomado en cuenta los riesgos del proyecto? Cohesión del Equipo (TEAM): hay problemas de sincronización entre stakeholders? Maduración del Proceso (PMAT): Cuál es el nivel CMMI del equipo de desarrollo? # líneas de código en la tarea inicial # líneas de código generado automáticamente % diseño modificado # líneas nuevas del lado del servidor # líneas nuevas del lado del cliente # líneas modificadas del lado del servidor # líneas modificadas del lado del cliente Tiempo invertido en la tarea Fig. 1.3. Campos de la Tabla Base. La Tabla de Multiplicadores de esfuerzo también debe regirse bajo la escala descrita anteriormente. Los aspectos a calificar son los siguientes [7]: Fiabilidad del Software (RELY): Qué tan grave es el efecto de un fallo del software? Tamaño de la base de datos: Qué cantidad de datos de prueba se necesitarán alojar en la base de datos? Complejidad del Producto (DATA): Cuan complejo es el producto con respecto al control computacional, operaciones que dependen de dispositivos y operaciones de administración de la interfaz de usuario? Reusabilidad en el Desarrollo (RUSE): Los componentes a desarrollar son reutilizables? Documentación (DOCU): Cuántas etapas del ciclo de desarrollo están documentadas? Restricción en tiempo de ejecución (TIME): Existe alguna exigencia por parte del cliente en los tiempos de respuesta durante la ejecución? Restricción en la Base de datos principal (STOR): Existe algún tipo de restricción en cuanto al porcentaje de uso de la base de datos principal? Volatibilidad de la plataforma (PVOL): Hay grandes y frecuentes cambios en lo que a plataforma se refiere?
Capacidad de Análisis (ACAP): Cuál es la capacidad de los analistas? Capacidad del Programador (PCAP): Cuál es la capacidad de los desarrolladores? Continuidad del personal (PCON): Cuál es la frecuencia anual de rotación del personal? Experiencia en las Aplicaciones (APEX): Cuál es la experiencia del equipo de desarrollo en desarrollar este tipo de aplicaciones? Experiencia en la plataforma (PLEX): Cuál es la experiencia del equipo en la plataforma a utilizar? Experiencia en Lenguaje de Programación y Herramientas (LTEX): Cuál es la experiencia del equipo en el lenguaje y herramientas a utilizar? Uso de herramientas de Software (TOOL): Se utilizó una herramienta de software existente para desarrollar el producto? Desarrollo Multisite (SITE): Existe un soporte de comunicación disponible? Planificación del desarrollo (SCED): Existe un calendario de restricciones impuesto sobre el equipo del proyecto? 2.1 Contando las líneas de código Para contar las líneas de código (LOC) a lo largo de todo el proceso de toma de datos, era necesario definir cómo hacerlo para disminuir la incertidumbre de los resultados obtenidos. En nuestro caso, las LOC representan el tamaño de los proyecto. Para llegar a un consenso en la forma de contar, nos reunimos con los jefes de desarrollo de cada empresa para darles a conocer las principales paradojas relacionadas al conteo de líneas de código. Dichas paradojas y su respectiva regla para resolverla fueron adaptadas de [8] (ver tabla 1.1). Adicionalmente, también consideramos otros aspectos, que a nuestro criterio, son importantes, tales como: 1) tomar de forma paralela la información de las líneas de código y el registro del tiempo; 2) determinar cuál es el momento oportuno de contar; y 3) establecer un inventario de todos los módulos que fueron creados y modificados durante el proyecto. Al finalizar esta etapa obtuvimos un conjunto de tablas y reglas, las mismas que fueron explicadas a todos los participantes capacitación mediante una inducción de 1 hora y 30 minutos. Posteriormente, para asegurar que el esquema de tablas creado era válido, es decir, que nos serviría para capturar los datos necesarios para realizar los cálculos de productividad, se decidió realizar una pre-prueba. 3 Pre-Prueba: Puesta en práctica, lecciones aprendidas y medidas tomadas Para la etapa de pre-prueba fueron requeridos 2 proyectos de corta duración, 1 por empresa. Dichos proyectos no excedieron las 2 semanas duración. A todos los participantes de la pre-prueba se les proveyó de todo el material necesario realizar las mediciones. El material incluía todas las tablas a utilizar en formato digital, así como un instructivo con los detalles del uso de las tablas y del proceso de medición en ge-
neral. Una vez transcurridas las 2 semanas de pre-prueba, se procedió a recibir los datos mediante vía electrónica y a realizar los cálculos respectivos. Tabla 1.1. Resolución de Paradojas de código. Los campos marcados con (*) se refiere a las paradojas de código adaptadas del [8] Paradoja *Contar líneas de código de diferentes lenguajes de programación. *Contar líneas de código nuevas frente a las líneas de código modificadas Entregas múltiples de la misma pieza de código *Diferentes estilos de programación Reutilización de código frente a nuevo código Paradojas de código. Solución Usar un factor de conversión que iguale el esfuerzo de ambos lenguajes Se utiliza la Tabla Base para registrar las líneas modificadas Se llegó a un acuerdo con las empresas de manera que solo las entregas finales se contarán A juicio del Jefe de Desarrollo. Si el módulo A reusa el módulo B y el módulo B reusa el módulo C, solo se cuenta normal A y B reusado y C NO SERA CONTABILIZADO, Lecciones aprendidas Luego de concluida la etapa de pre prueba, notamos la existencia de valores inesperados que nos obligaron a tomar acciones correctivas y a aprender de los errores cometidos. Entre las anomalías detectadas podemos mencionar las siguientes: 1) La calificación otorgada por los desarrolladores para ciertos campos de las tablas de multiplicadores de esfuerzo y factores de escala no estaban dentro del rango de valores permitidos por COCOMO II; 2) algunas variables de la fórmula de COCOMO II habían sido calificadas de forma incorrecta, según el criterio del Jefe de Proyectos; 3) algunas columnas de las tablas no fueron interpretadas correctamente,, lo que complicaba el cálculo de las variables DM (% Modelo Modificado) y CM (% Código Modificado), requeridas en el modelo COCOMO. Debido a esas anomalías fue necesario tomar las siguientes acciones correctivas: 1) Diseñar la tabla Control de Módulos Reusados. 2) Mejorar el instructivo, específicamente las secciones de Breve explicación y Explicación detallada de los campos de cada una de las tablas. 3) Realizar una re-inducción a los participantes para afianzar lo aprendido y mostrar los cambios al proceso de medición y el uso de la nueva tabla diseñada.
4 Casos de estudio: medición y resultados La presente sección detalla las experiencias vividas en el desarrollo de los casos de estudio CF002 y PS002. Para ambos casos, cada una de las empresas participantes, desarrolló un proyecto de complejidad baja durante un periodo de 16 semanas aproximadamente. A continuación se muestran los resultados obtenidos para cada empresa. 4.1 Caso de Estudio CF002 Para este caso en particular, el entorno de desarrollo fue de relativa estabilidad. sin embargo, es válido acotar que este proyecto tenía una cuota considerable de participación administrativa. Debido a ello, consideramos que el esfuerzo registrado en las tablas puede diferir de la realidad ya que los programadores repartían su tiempo en actividades administrativas y de programación. Los resultados obtenidos de este ejercicio no son absolutos, si no que a nuestro criterio, representan una primera medición que indicará las áreas que necesitan mayor atención dentro de la empresa. Como se indica en la tabla 4.1, el tamaño de CF002 fue de 3,05 KSLOC, con un esfuerzo estimado por COCOMO II de 7,1 PM, considerando un valor de calibración de A=2,94 y B=0,91. Con estos mismos datos se procedió a hacer la estimación del esfuerzo usando la fórmula calibrada de COCOMO II obtenida a través de proyectos analizados en KuLeuven[11]. El resultado que se obtuvo de dicha estimación fue de 19,32 PM. Dados estos resultados y teniendo un valor de esfuerzo real de 3,2PM podemos deducir que el proyecto CF002 se realizó con un esfuerzo mucho menor al estimado con el modelo COCOMOII. Los datos de este caso de estudio se presentan en las tablas 4.1, 4.2.1 y 4.2.2. Algunas de las razones que podrían explicar la gran diferencia en los valores de esfuerzo estimado son las siguientes: 1) La poca cantidad de proyectos (2 en total, 1 por empresa) no es suficiente para garantizar un resultado confiable, puesto que cada proyecto tiene una influencia considerable en el cálculo de los parámetros. 2) Errores al calcular, registrar el tiempo y contar las líneas de código. Esto generalmente ocurre cuando existe una sobrecarga de trabajo y los programadores olvidan u omiten el conteo de líneas de código. 3) La arquitectura cliente servidor del proyecto impactó la medición, ya que la programación del lado del cliente es diferente a la del servidor. Para efectos prácticos fueron considerados como 2 proyectos diferentes, lo que implicó el uso de factores de conversión para de esta forma poder tener las líneas de código en una sola unidad medible. La determinación de este factor de conversión fue realizada en base a criterios de los expertos que trabajaban con los dos lenguajes de programación involucrados en los proyectos (JavaScript y Php). Esta consideración se convierte en una evidente causa de distorsión en los resultados; 4) otros factores de entorno, como por ejemplo: un desarrollador puede ser asignado a múltiples proyectos pequeños aumentando la probabilidad de cometer errores en los registros de los datos solicitados. Tabla 4.1. Resultado Caso de Estudio CF002 Esfuerzo Actual (PM) Ksloc PLEC FLEX RESL TEAM PMAT CF002 3,2 3,05 L N N H VL
Tabla 4.2.1. Caso de Estudio CF002 Multiplicadores de esfuerzo RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP CF002 VL N VH H L N N N H Tabla 4.2.2. Caso de Estudio CF002 Multiplicadores de esfuerzo PCAP PCON APEX PLEX LTEX TOOL SITE SCED CF002 VH H H N L H N N 4.1 Caso de Estudio PS002 En la toma de datos para el caso PS002, se evidenciaron diferencias en el ambiente de desarrollo. Los dos equipos asignados para participar en el caso de estudio PS002 tenían formas diferentes de administrar las tareas encomendadas. Adicionalmente, uno de los equipos se vio afectado por el cambio de sus integrantes durante tiempo de desarrollo. Debido a estos motivos, los resultados de las mediciones probablemente presentan errores. El tamaño del proyecto de este caso de estudio fue de 2,03 KSLOC y la estimación por medio del modelo COCOMO II fue de 5,97 PM. KuLeuven estimó un esfuerzo de 20,35 PM usando sus fórmulas calibradas. El esfuerzo real obtenido fue de 4,5 PM. Podemos nuevamente notar que los valores estimados con los reales difieren enormemente. Los resultados de PS002 pueden ser observados en las tablas 4.3, 4.4.1 y 4.4.2. Posibles motivos que pudieran justificar la diferencia entre el esfuerzo real y el estimado son similares a los expresados en el caso CF002, sumados a los siguientes: 1) El nivel de organización del Jefe de Proyecto. El debía atender constantemente solicitudes de mantenimiento de sistemas, por lo cual se veía obligado a cambiar las prioridades de las tareas de los desarrolladores a su cargo (baja, urgente, inmediata) Esto ocasionaba trabajos pendientes y pérdida de consistencia de la información recabada. 2) Falta de coordinación al momento de tomar los datos. Es decir, que el desarrollador registraba la información después de un tiempo prolongado de haber terminado una o más tareas, por lo que presumimos que los tiempos son inexactos. Tabla 4.3. Resultado Caso de Estudio PS002 Esfuerzo Actual (PM) Ksloc PLEC FLEX RESL TEAM PMAT PS002 ~4,5 2,03 N L L N VL Tabla 4.4.1. Caso de Estudio PS0002 Multiplicadores de esfuerzo RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP CF002 VL H N L N N H L H Tabla 4.4.2. Caso de Estudio CF0002 Multiplicadores de esfuerzo PCAP PCON APEX PLEX LTEX TOOL SITE SCED CF002 L L N H H N VL N
Discusión Proporcionar una herramienta que ayude a evaluar la productividad alcanzada durante el desarrollo de un producto de software es una tarea difícil, más aún si se trata de empresas muy pequeñas. Sin embargo, los resultados obtenidos en este tipo de estudios, nos dan una idea de que se puede mejorar en el proceso de desarrollo para obtener datos confiables de las mediciones realizadas y qué otros reportes pudieran obtenerse. Algunas de las mejoras con respecto al presente trabajo son las siguientes: 1) elaborar una tabla de frecuencia de los multiplicadores de esfuerzo y factores de escala por cada proyecto participante para conocer las calificaciones más comunes otorgadas a los manejadores de costo; 2) incrementar el número de proyectos dentro de una misma empresa para mejorar el proceso de estimación, detectando valores atípicos en los manejadores de costo y cambios de calificación en algún manejador específico; 3) crear otros reportes que permitan hacer mejores conclusiones, como por ejemplo: a) carga de trabajo por persona en relación con el número de líneas de código b) la productividad en función del número de equipos que registran su carga de trabajo y c) la productividad en función de diferentes intervalos de tiempo. 5 Implicaciones A lo largo del desarrollo del proyecto se pudo observar que el conteo de líneas de código es complejo. A pesar de contar con una tabla de paradojas y su solución, no fue fácil para los programadores seguirla. Una forma alternativa es medir el tamaño funcional usando IFPUGFP o Cosmic. Este último, a nuestro criterio, es relativamente sencillo de aplicar una vez conocida la metodología de conteo. Sin embargo, consideramos que: La tabla denominada: Tabla básica para el cálculo de la productividad creada por los autores de este artículo puede ser utilizada en empresas que no cuentan con ningún método automático para realizar este procedimiento de conteo. Durante el proceso de obtención de datos de medición de tiempo y de tamaño, pudimos observar que el nivel de conocimiento de los participantes de ambas empresas sobre temas relacionados a estimación y a mediciones de software era muy bajo. Su personal, entre los que se encontraban estudiantes y egresados de la carrera Computación y una minoría con título de 3er nivel en Ingeniería en Computación, tuvieron que recibir dos inducciones sobre el modelo de estimación y del proceso de medición de la productividad en general. Esto se debe, probablemente, a que estos temas no son tratados en profundidad en la universidad, sino que son vistos de forma ligera en un número reducido de horas. El personal de ambas empresas manifestó preferir el uso de su experiencia para hacer estimaciones. Sin embargo, éste hábito los lleva a cometer errores y ven luego un aumento en el esfuerzo y una disminución de la productividad esperada. Los resultados obtenidos pueden ser desalentadores para las pequeñas empresas de software ya que el modelo de estimación utilizado no se aproxima a los datos reales recopilados para obtener el esfuerzo. En el caso de la estimación proporcionada por KuLeuven, ésta estuvo muy por arriba de lo real. Esto se puede explicar porque los
proyectos con los cuales ellos calibraron las fórmulas de COCOMO corresponden al sector bancario, el cual es muy diferente al de los proyectos realizados en los 2 casos de estudio ecuatorianos. Estas diferencias encontradas pueden sugerir que COCOMO II no es apropiado para empresas pequeñas debido a que los coeficientes de las fórmulas no se adaptan a su realidad. Adicionalmente, tratar de dar un valor de una escala a una gran cantidad de multiplicadores de esfuerzo en un entorno cambiante, como lo es el de las empresas pequeñas, no convence a los miembros de los equipos de desarrollo. Sin embargo, más investigación es requerida para afirmar este hallazgo. Una implicación importante es que los programas de estudio en las universidades ecuatorianas, y quizás en otros países, deben ser revisados para que sus contenidos faciliten la adopción de programas de mediciones de software en las empresas. References 1. N. Fenton and S. Pfleeger, Software metrics: a rigorous and practical approach. Boston, MA, USA : PWS Publishing Co, Junio 2009. 2. Laporte, C.Y. Alexandre, S. Renault, A. Ecole de Technol. Developing International Standards for Very Small Enterprises. ISBN: 0018-9162. 3. S.D. Conte, H.E. Dunsmore, and V.Y. Shen, Software Engineering Metrics and Models. Menlo Park, Calif.: Benjamin/ Cummings,1986. 4. A. MacCormack, C. Kemerer, M. Cusumano, and B. Crandall, Trade-Offs between Productivity and Quality in Selecting Soft-ware Development Practices, IEEE Software, pp. 78-79, Sept./Oct.2003. 5. Cosmic FFP. http://www.cosmicon.com. 6. IFPUG. http://www.ifpug.org. 7. B. Boehm, B. Steece, and R. Madachy. Software Cost Estimation with Cocomo II with Cdrom. Prentice Hall PTR Upper Saddle River, N.J, USA, 2000. 8. B. Clark, S. Devnani-Chulani, and B. Boehm. Calibrating the COCOMO II postarchitecture model. Proceedings of the 20th international conference on Software engineering, 1998. pp. 477-480. 9. ISO/IEC. Software engineering-ifpug 4.1 Unadjusted functional size measurement method - Counting practices manual. 2003. 10. ISO/IEC. Software engineering - COSMIC-FFP - A functional size measurement method. 2003. 11. De Rore, L., Snoeck, M., Dcdene, G. (2006). COCOMO II applied in a banking and insurance environment: experience report. Proceedings of the 3rd Software Measurement European Forum (SMEF 2006). Rome (Italy), May 2006 (pp. 247-257). 12. De Rore, L., Snoeck, M., Dcdene, G. (2006). COCOMO II applied in a banking and insurance environment: experience report. Proceedings of the 3rd Software Measurement European Forum (SMEF 2006). Rome (Italy), May 2006 (pp. 247-257). 13. Gresse von Wangenheim, C., T. Punter, A. Anacleto (2003). Software Measurement for Small and Medium Enterprises - A Brazilian-German view on extending the GQM method. 7th International conference on Empirical Assessment in Software Engineering (EASE), Keele. 14. Mazón J., Villavicencio M., Alvear J., B. G. (2005). Aspectos de la Calidad y Dificultades en la Gestión de Proyectos de Software: Estudio exploratorio. II Jornadas de Ingeniería de Software, Guayaquil, ESPOL, Componente 8 Proyecto VLIR.