MODELO DE PRODUCTIVIDAD BASADO EN COMPONENTES PARA LA FÁBRICA DE SOFTWARE

Transcripción

1 MODELO DE PRODUCTIVIDAD BASADO EN COMPONENTES PARA LA FÁBRICA DE SOFTWARE Pedro S. Castañeda Vargas 1, Luis A. Guevara Sandoval 2 Sinopsis: Todo proyecto de desarrollo de software consume tiempo y esfuerzo en cada una de las etapas que lo conforman. Es clara entonces, la necesidad de contar con buenos estimadores para estas variables, lo cual implica establecer cuáles son los factores que influyen directa e indirectamente en ellas. En muchas organizaciones orientadas a objetivos y de ellas las que están especializadas en la construcción de software bajo diferentes plataformas, la gestión se preocupa por ser eficaz y no necesariamente eficiente, lo cual conlleva a que no se preocupen por la productividad de los recursos asignados y por su homologación, de manera que se pueda comparar distintas líneas de producción de tecnologías y plataformas distintas. Es a partir del ingreso a un mundo globalizado que las organizaciones ven que para poder desarrollarse y competir no sólo necesitan ser eficaces sino también eficientes, empiezan a cuestionar su actual forma de trabajo, con preguntas como Estamos utilizando adecuadamente la capacidad del equipo de trabajo? Estamos utilizando las habilidades y capacidades de todos nuestros colaboradores? Nos estamos midiendo con el mercado o sólo de manera interna? Cuánto es el potencial que nuestros recursos podrían generar en valor a la organización? Y todo ello confluye en un sólo término que llamamos PRODUCTIVIDAD, factor que permitirá medir cuánta es la brecha entre el potencial de valor que pueden generar nuestros recursos y lo que actualmente están generando de manera que el personal esté pensando en la innovación constante y por ende que la organización sea trascendental en el tiempo. Este trabajo busca encontrar un modelo que permita establecer los lineamientos para la medición de la productividad y que posteriormente sirva como un factor de estimación de tiempos. Palabras Clave: Productividad, Métricas, Eficiencia, Fábrica de Software, Componentes Introducción Todo proyecto de desarrollo de software consume tiempo y esfuerzo en cada una de las etapas que lo conforman. Es clara entonces, la necesidad de contar con buenos estimadores para estas variables, lo cual implica establecer cuáles son los factores que influyen directa e indirectamente en ellas. GMD brinda servicios de fábrica de software 3 en organizaciones públicas y privadas, generando productos de software personalizados de acuerdo a las necesidades del cliente. Este mercado ha sido durante años el factor de éxito de la organización, sin embargo ante la internacionalización y el ingreso de nuevos competidores al mercado peruano, es necesario plantearnos una serie de preguntas como: Estamos aprovechando las capacidades y habilidades de nuestros colaboradores para desarrollar un producto de calidad? Tenemos indicadores que permitan comparar la productividad de los diferentes proyectos? Cuánto valor generan nuestros recursos y cuánta es la brecha del potencial que podrían generar? Ante esta pregunta, nos encontramos en un dilema que aún no se ha podido resolver en la industria del 1 Ingeniero de Sistemas Universidad Tecnológica del Perú pcastanedav@gmd.com.pe 2 Bachiller en Ingeniería de Sistemas Universidad Nacional de Ingeniería lguevarasa@gmd.com.pe 3 Fábrica de Software: Denominación dada al conjunto de actividades que se ejecutan en el proceso de desarrollo de software

2 software, como es el uso de una técnica o metodología que permita medir la productividad de las personas y por ende de la organización en casuísticas tan diversas y bajo diversos enfoques tecnológicos y metodológicos. Hasta la fecha, en la industria del software se han utilizado diversos métodos que permiten medir la cantidad de software producido, siendo los más conocidos los métodos basados en casos de uso [1] y puntos de función [2], pero en muchos casos que se han aplicado estos métodos, han devenido en mostrar resultados que no son coherentes con la realidad, lo cual genera algunos problemas, tales como: No se puede conocer la capacidad de producción de los colaboradores de una organización. No se tiene una unidad de medida del software que permita establecer la eficiencia de un proyecto ni la comparación entre proyectos que involucren diferentes plataformas tecnológicas. No existen indicadores de productividad. No existe una base para la estimación de tiempos para un nuevo desarrollo. En el siguiente trabajo de investigación se busca encontrar una metodología que permita establecer un estándar de medición entre los diferentes proyectos que interactúan en la fábrica de software de GMD, que por la diversidad de plataformas tecnológicas que abarca cada uno, permitirá tener un amplio espectro de información que nos conlleve a la obtención de un modelo inicialmente destinado al uso en GMD y posteriormente escalable a cualquier tipo de organización dedicada al desarrollo de productos de software. Es por ello que analizando la información existente, se ha realizado un esfuerzo para determinar una metodología que permita medir la productividad y facilite la estimación de tiempos, estableciéndose como unidad mínima de medida el Componente 4 de Software. Según Szyperski [3] un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio Para la elaboración de la presente investigación se ha tomado en consideración información de proyectos de software del área de Soluciones de Negocio (Outsourcing de Aplicaciones) de GMD como son: Sistema Integrado de la Administración Financiera del Sector Público (SIAF SP II) Ministerio de Economía y Finanzas. Fábrica de Software SUNAT Desarrollo y Mantenimiento de Software (DYM) Oficina de Normalización Previsional Desarrollo y Mantenimiento de Software AFP INTEGRA Desarrollo y Mantenimiento de Software La Positiva Meta4 Es por ello, que en el inicio del trabajo se ha destinado esfuerzo horas hombre en recuperar información de los proyectos pasados, como son el tamaño (en puntos de función) y el esfuerzo (horas). Actualmente se viene trabajando con alumnos y docentes del MBA del McDonough School of Business de Georgetown University a fin de recopilar información de fábricas de software de EEUU y Europa que permitan extrapolar el alcance de la metodología desarrollada en GMD. Marco Teórico La metodología Rational Unified Process (RUP) [4], considera que el porcentaje de duración de las fases del desarrollo del software de un proyecto están distribuidos de acuerdo a lo mostrado en la Figura N Componente: Lista de objetos medibles y cuantificables que facilitan la labor de asignación de tareas al equipo de programadores

3 Entradas Herramientas y Técnicas Salidas Figura N 1: Esfuerzo por fases del Rational Unified Process Tal como se muestra en la Figura N 1, el mayor esfuerzo en el desarrollo de software se produce en la disciplina de programación, siendo justificable por ello el hecho de dar inicio a este trabajo en el hecho de capturar la información en un primer momento sobre este componente, para luego poder ir extrapolando a las demás disciplinas (Modelamiento de Negocio, Análisis, etc.). Proceso General El proceso de medición de la productividad cumple dos objetivos específicos: Determinar el nivel de productividad de la persona, proyecto y área. Calibrar los tiempos de programación reales, a fin de mejorar la estimación de tiempos de la fábrica. Es por ello que se ha establecido un proceso que facilite la interacción de actividades necesarias para la obtención de los objetivos indicados anteriormente. El proceso considera lo siguiente: Orden de Trabajo (OT) Factores de impacto en el tiempo de desarrollo de componentes Catálogo de Componentes de Software Límites de Control Figura N 2: Proceso propuesto Orden de Trabajo (OT) Finalizada Lista de Incidencias A continuación, describiremos el modelo operativo: Figura N 3: Modelo operativo de fábrica El cliente determina requisitos funcionales para un producto de software, siendo éste luego transformado a requisitos de sistema en la fábrica de software. La fábrica de software genera una Orden de Trabajo 5 (OT), que contiene un conjunto de requisitos de sistema. La OT previamente priorizada ingresa al Componente de Programación, a fin de que inicie la atención. El Coordinador de Fábrica en base al Catálogo de Componentes de Software realizará la descomposición de los requisitos del sistema en componentes de software y la asignación de los mismos en tareas a los diferentes participantes de la OT. El Coordinador de Fábrica al culminar todas las tareas encomendadas en la OT, procederá a verificar la integración del producto (labor también asignada como un componente ficticio a un recurso integrador de los componentes) y dará finalizada la atención de la OT. Los roles participantes en este proceso son: Coordinador de Fábrica: Arquitecto de Soluciones o experto en programación que tenga la capacidad de asignar requerimientos de sistemas en componentes de software, en base al diseño entregado en la OT, así como habilidades de gestión de recursos. Programador: Rol encargado de realizar las tareas asignadas. El proceso propuesto utiliza como herramienta de trabajo para la asignación de tareas un documento denominado Catálogo de Componentes de Software, para cuya elaboración se ha realizado un trabajo exhaustivo de búsqueda y recolección de 5 Orden de Trabajo (OT): Conjunto de requisitos de sistema

4 información que permita estandarizar los diferentes componentes de software utilizados en los diferentes proyectos que se ejecutan en la Fábrica de Software de GMD 6, la cual ha conllevado a que se establezca un trabajo de calibración de tres (03) elementos principales: 03 Negocio 04 Pantalla con lógica Componente que contiene las operaciones de negocio de una aplicación Este componente corresponde a una pantalla que tiene código embebido o tiene código para manejo de eventos (Code behind) a través de un controlador para manejar los eventos de la pantalla. Lenguaje Alto Nivel Lenguaje Alto Nivel de de En lenguaje estructurado: Figura N 4: Elementos del modelo de productividad 1. Expertos. Se realizó una recolección de información de ochenta (80) programadores y diez (10) arquitectos de soluciones, a fin de estandarizar tiempos de programación basado en las siguientes características: Experiencia en desarrollo (meses) Conocimiento del negocio (meses) Lenguaje de programación base Dominio del lenguaje de programación (meses) Herramienta base Dominio de la herramienta (meses) 2. Distribución de Trabajo. Esta distribución se realiza en base a una lista de componentes estandarizada que ha sido recolectada de la experiencia de los proyectos de software con una antigüedad mayor a dos (02) años, a fin de que la data a considerar en esta lista ya esté validada y permita tener una conocimiento más certero del desglose del software en componentes. Para la elaboración de la lista se ha considerado lo siguiente: Componentes Unidad mínima de desglose del software, cuya característica principal es ser medible y cuantificable. Ejemplos de componentes: En lenguaje de programación orientada a objetos: ID COMPONENTE DESCRIPCIÓN CATEGORÍA 01 Integración Componente artificial que corresponde a la integración de los demás componentes Artificial en un flujo de programación. 02 Servicio Componente que contiene las Lenguaje de operaciones transaccionales Alto Nivel de una aplicación. ID COMPONENTE DESCRIPCIÓN CATEGORÍA 01 Interactivo Data Componente programado Entry para AS400 Cobol/CLP/RPG 02 Online Componente programado Actualizadores para OS390 Cobol/Cics Componente que contiene 03 Online Consultas las operaciones de negocio de una aplicación Cobol/Cics COMPONENTE Pantalla con lógica Factores Son elementos externos que afectan los tiempos de desarrollo de los componentes, habiéndose identificado los siguientes: - Complejidad (simple, medio, complejo). - Lenguajes de Programación. - Framework/Tecnología. - Estándares de Programación. - Tipo de Proceso (mantenimiento, desarrollo). - Tipo de Tarea (creación, modificación). - Herramienta Base. - Retrabajo. Ejemplo de factores. En el siguiente cuadro se considera que el lenguaje de programación es JAVA y los criterios para definir la complejidad están definidas en base a los datos de entrada y las validaciones en cada una de ellas. FACTOR: COMPLEJIDAD Simple (S) Medio (M) Complejo (C) De 6-10 De 1-5 De 11 a más datos datos de datos de de entrada. entrada. Validaciones Una tabla cruzadas de para campos de mostrar como resultado de hasta 10 campos de salida. entrada. Validacion es cruzadas de campos de formulario con validación Java. Paginación formulario. Paginación. Uso de taglibs. Uso de Layers. Uso de Frames, iframes. 3. Métricas. Indicadores que permiten medir la productividad por persona, proyecto y área. Se han establecido las siguientes métricas: INDICADOR PERSONA FÁBRICA 6 Información recopilada de los proyectos del área de Soluciones de Negocio (AO)

5 Productividad Eficiencia Nro Componentes Estándar Construídos Período de Tiempo Tiempo construcción componente(estad. ) Tiempo real de construcción componente Nro OT Construídos Período de Tiempo Tiempo atención OT s(estad. ) Tiempo real de atención OT s El proceso de calibración considera la recolección de información de manera permanente, de tal manera de permitir que este modelo sea usado como una herramienta de estimación de tiempos. Implementación y Resultados del Modelo Para la elaboración del modelo se ha contemplado dos etapas: a. Etapa 1 Diseño del modelo. En esta etapa se ha realizado la recolección de data histórica de proyectos de software con una antigüedad mayor a dos (02) años. El objetivo en esta etapa ha sido la obtención de un modelo estadístico inicial. La técnica utilizada ha sido regresión lineal múltiple. Al utilizar la técnica de regresión lineal múltiple, se han determinado los factores que eran estadísticamente significativos sobre una muestra de 1799 observaciones y logrando determinar un modelo predictivo apropiado que se muestra a continuación: T = (0,44 C) + (0,35 EP) (0,39 ED) (0,23 CN) (0,45 DLP) (0,043 DT) + (0,13 CH ) + 5,83 Donde: T: Tiempo de construcción de componente (en horas) C: Complejidad (1: Simple, 2: Media, 3: Complejo) EP: Estándares de Programación (1: Tiene, 0: No tiene) ED: Experiencia en Desarrollo (en meses) CN: Conocimiento del Negocio (en meses) DLP: Dominio del lenguaje de programación (en meses) DT: Dominio de la Tecnología (en meses) CH: Conocimiento de la herramienta de desarrollo (en meses) b. Etapa 2 Validación y calibración del modelo. En esta etapa se ha considerado la validación del modelo en un proyecto en ejecución, y con los resultados reales, realizar un proceso de calibración, a fin de ir ajustando las variables del modelo inicial. En esta etapa se ha tenido como objetivo que el modelo pueda brindar una estimación de tiempos con un margen de error de ± 12%. Para la validación del modelo estadístico inicial se eligió al Proyecto SIAF SP II MEF, por reunir características comunes a todos los proyectos y por tener una estructura organizacional que garantizaba la fiabilidad de la data obtenida. Algunas de las características del proyecto se mencionan a continuación: Poco conocimiento del negocio, debido a que la organización no había gestionado proyectos anteriores orientados a la formulación del presupuesto público. Tecnología nueva, ya que la implementación implicaba el desarrollo de un producto de software basado en tecnologías SOA-BPM. Herramientas de desarrollo nuevas, ya que las herramientas a utilizar deberían estar basadas en la suite de desarrollo IBM WebSphere. La información obtenida de este proyecto ha sido durante un período de 18 meses, lo cual ha permitido realizar los ajustes en el modelo inicial, aplicando la técnica de regresión lineal múltiple en diferentes momentos. Los resultados obtenidos se muestran a continuación: Para la estimación de tiempos: Módulo Casos de Uso (días) Puntos de Función (días) Componentes (días) Real (días) Administración de Clasificadores Marco Lógico Anual Plurianual Seguridad Del cuadro anterior, se ha podido obtener las desviaciones que han tenido cada una de las metodologías utilizadas en la evaluación: Módulo Casos de Uso (%) Puntos de Función (%) Componentes (%) Administración de Clasificadores 43% 30% 11% Marco Lógico 36% 15% -9% Anual -14% 19% 11% Plurianual 24% 11% -7% Seguridad 29% 57% 20%

6 Conclusiones Figura N 5: Desviaciones por metodología aplicada Tal como se puede visualizar en la Figura N 5, las estimaciones generadas por el modelo propuesto han tenido menos desviación, notándose que los datos estimados se están centrando en un rango de ± 11%, valor que cumple los objetivos trazados en el proyecto. En el caso de las estimaciones que han pasado el objetivo de ± 12%, se ha realizado un análisis de esta información, a fin de conocer los factores que han generado este tipo de valores, habiéndose encontrado algunas consideraciones como: Cambios que no han sido gestionados adecuadamente, y por lo tanto no se realizó una reestimación. Los tiempos reales han considerado no sólo tiempos de desarrollo, sino de análisis u otra actividad que no era parte del objetivo del estudio. Para la medición de la productividad En el siguiente cuadro se presenta una muestra de la data obtenida (producción real) por los diferentes proyectos, que ha permitido establecer la cantidad de componentes que puede desarrollar un programador por hora (1.95 componentes de software), pudiéndose extrapolar para diferentes períodos de tiempo. Productividad Proyectos de Software Real Período DYM Horizonte MasterCard MEF Meta4 Total Semana Semana Semana Semana Semana Semana Semana Total general Si extrapolamos esta información para un día, se puede concluir que un programador estaría en la capacidad de producir aproximadamente 16 componentes de software. El modelo permite determinar la productividad de manera objetiva en base a un modelo estadístico autoregulable en el tiempo. El modelo ha permitido establecer límites de control, que son los valores mínimos y máximos sobre los cuales se debería medir la productividad de la fábrica. El modelo permitirá realizar de manera fiable la estimación de tiempos de la fábrica. Recomendaciones Introducir en el modelo propuesto, la información de otras fábricas de software, a fin de hacer escalable el modelo hacía otras organizaciones. Incorporar en el modelo, las actividades de las demás disciplinas de desarrollo de software que no han sido consideradas en esta fase inicial. Automatizar el proceso establecido en el modelo, a fin de facilitar la recolección de datos. Formar un equipo encargado de monitorear el proceso, de tal manera que realice la calibración de la información generada en los proyectos. Utilizar otras técnicas matemáticas que permitan incrementar el nivel de precisión en la estimación de tiempos, de tal manera que se reduzca el margen de error plasmado en los objetivos del proyecto (± 12%) Bibliografía [1] Roy K. Clemmons. (2006). Project estimation with Use Case Points. EEUU, Crosstalk: The Journal of Defense Software Engineering. [2] Jones, C A Short History of Function Points and Feature Points. Software Productivity Research Inc. USA. [3] Karlsruhe, Germany, October Michael R.V. Chaudron, Clemens Szyperski, Ralf Reussner, Component-Based Software Engineering Proceedings, 11th International Symposium (CBSE 2008), (Eds.) Springer, LNCS 5282, ISBN , October 2008 [4] Philippe Kruchten (2003). The Rational Unified Process: An Introduction, Third Edition.