FACULTAD DE CIENCIAS EXACTAS
Trabajo final de la carrera de Ingeniería de sistemas
Asistente para la planificación inteligente de
proyectos
Por
Arian Kiehr y Leandro Lezcano
Directores
Dr. Alvaro Soria y Dr. Luis Berdun
Tandil, Abril de 2016
Índice general
Capítulo 1: Introducción………..……… 6
1.1 Tesis……….. 7
1.2 Organización del trabajo………... 9
Capítulo 2: Estado del arte……….………... 11
2.1 Planificación de proyectos………..…………... 13
2.2 Métricas de Software.……….………..……….. 15
2.3 Enfoques que asisten la planificación mediante métricas.……….……… 16
2.3.1 Personal Software Process……….………….. 17
2.3.2 Constructive Cost Model……….…….……….. 18
2.3.3 Paradigma GoalQualityMetric……….………. 19
2.3.4 Software Capability Maturity Model……….………….. 20
2.3.5 Telemetría de Software………...…….…………... 22
2.4 Herramientas que asisten a la planificación mediante métricas.…….………. 24
2.4.1 Hackystat……….…………. 24
2.4.2 SonarQube………..……….………….... 27
2.4.3 CAST Application Intelligence Platform……….………..………. 32
2.4.4 SQuORE……….………..………... 33
2.4.5 Rally Editions……….…...…... 34
2.4.6 Squale (Qualixo)……….……. 35
2.5 Comparación de herramientas………..……….…... 36
2.6 Resumen………...….……….. 39
Capítulo 3: Tesys……….... 40
3.1 Caso de estudio……….. 43
3.2 Configuración de Tesys………...………….…….. 46
3.3 Captura e interpretación de métricas………....… 50
3.4 Disponibilidad de los datos………...………... 60
3.5 Asistencia para la toma de decisiones..……...………...………. 60
3.6 Visualización de la información...………...………. 65
3.7 Resumen………..……….……….. 68
4.1 Captura de métricas……….….. 73
4.1.1 Los conectores……….... 73
4.1.2 El Motor de métricas………... 76
4.1.2.1 Unificación de los datos……….. 76
4.1.2.2 Escalabilidad del sistema………... 79
4.1.2.3 Estrategia para almacenar la información……….... 80
4.2 Administrador de reglas……….. 84
4.2.1 Definición de nuevas métricas………... 84
4.2.2 Definición de habilidades……….... 86
4.3 Persistencia de datos………. 86
4.3.1 Conector de la base de datos……….…... 87
4.3.2 Motor de búsqueda de datos……….. 88
4.3.3 Base de datos……….. 88
4.4 Estimaciones para asistir decisiones.……….. 89
4.5 Visualización de la información……….. 89
4.6 Resumen..……….... 89
Capítulo 5: Resultados experimentales………... 92
5.1 Contexto………... 92
5.2 Resultados obtenidos………..……... 95
5.3 Resumen……….. 105
Capítulo 6: Conclusiones………....……... 109
6.1 Limitaciones y trabajos futuros……….. 110
Bibliografía………... 112
Índice de Figuras
Figura 1.1: Diagrama de contexto general de Tesys…………..……….…7
Figura 2.1: Secuencia de procesos seguida por la mayoría de los proyectos.…..………12
Figura 2.2: Los procesos de la planificación de proyectos.………..………14
Figura 2.3: Niveles de madurez de CMMI……….………....21
Figura 2.4: Vista general de Hackystat.……….………....25
Figura 2.5: Interfaz gráfica de Hackystat.……….………27
Figura 2.6: Vista de alto nivel de la arquitectura de SonarQube.……….………...29
Figura 2.7: Vista de métricas en el panel principal de SonarQube.………….……….…..31
Figura 2.8: Vista de las métricas proveídas por Developer Cockpit.……….………....32
Figura 2.9: Gráfico de rendimiento de proyecto en Rally Editions.……….……….….…..35
Figura 3.1: Esquema conceptual de Tesys.……….……….…....41
Figura 3.2: Ejemplo de una tarea en Jira.……….………...45
Figura 3.3: Ejemplo de una parte del diff de un commit particular.……….………46
Figura 3.4: Ejemplo de habilidades detectadas en las diferencias…....……...….………..49
Figura 3.5: Ejemplo del resultado de un análisis de SonarQube..……….….………...53
Figura 3.6: Solución propuesta para extraer los datos de las herramientas….………...54
Figura 3.7: Diagrama de flujo del funcionamiento del Motor de métricas………….………..59
Figura 3.8: Ejemplo de regresiones lineales de las métricas correlacionadas..….………..63
Figura 3.9: Ejemplo de métricas correspondientes a tareas de Jira..……….…………...66
Figura 3.10: Ejemplo de una métrica definida en base a otras existentes..………….………...67
Figura 3.11: Habilidades obtenidas de dos tares de Jira..……….…………..68
Figura 4.1: Diagrama de componentes y conectores general de Tesys..……….………72
Figura 4.2: Diagrama de componentes y conectores de los conectores del sistema….……….74
Figura 4.3: Diagrama de secuencia de los conectores……….……..75
Figura 4.4: Diagrama de módulos de los conectores del sistema...……….……….75
Figura 4.5: Diagrama de clases de estructura que agrega métricas a una tarea...……….……77
Figura 4.6: Diagrama de clases de Factory del agregador...……….….…78
Figura 4.7 Diagrama de clases de mapeo por reflexión de tipos de datos..………….………..79
Figura 4.8: Diagrama de clases de estructura Skill...……….……...81
Figura 4.10: Diagrama de clases de estructura Metric...………....……..83 Figura 4.11: Diagrama de clases de estructura Developer...………....……….84 Figura 4.12: Diagrama de clases de estructura que soporta el cálculo de métricas...….………85
Figura 4.13: Definición de una habilidad...……….….…….86 Figura 5.1: Proporción de los distintos lenguajes dentro del proyecto U3D...…………..….…….92 Figura 5.2: Herramientas utilizadas en el proceso de desarrollo de software del curso….….…94 Figura 5.3: Captura de pantalla de la herramienta Tesys en la pestaña de estimaciones…96
Figura 5.4: Resultados de la primera prueba correspondientes a estimaciones de tareas del segundo sprint utilizando una única métrica...……….….……...99 Figura 5.5: Resultados de la segunda prueba correspondientes a estimaciones de tareas del segundo sprint utilizando dos métricas...………..……….……….101
Figura 5.6: Resultados de la tercera prueba correspondientes a estimaciones de tareas del segundo sprint utilizando una métrica y filtros por habilidades...……….………..102 Figura 5.7: Resultados de la cuarta prueba correspondientes a estimaciones de tareas del tercer sprint utilizando una métrica...………..………..….……..…104
Figura 5.8: Comparación de estimaciones y aciertos entre la primera y segunda prueba....…105 Figura 5.9: Comparación de estimaciones y aciertos entre la primera y tercera prueba....106 Figura 5.10: Comparación de estimaciones y aciertos entre la primera y cuarta prueba...107
Índice de Tablas
Tabla 2.1: Niveles de madurez del CMMI y que se debe medir en cada uno………..……..24
Tabla 2.2: Comparación de las distintas herramientas analizadas.………...……..38 Tabla 3.1: Métricas que posee cada una de las herramientas del caso de estudio………...44 Tabla 3.2: Nuevas métricas generadas por el Administrador de reglas asociadas a una tarea……….…….………...…………..…....48
Tabla 3.3: Ejemplo de cómo el Administrador de reglas asigna habilidades a una tarea....50 Tabla 3.4: Ejemplo de datos obtenidos desde el conector Issue Tracker…………....…..……..56 Tabla 3.5: Ejemplo de datos obtenidos desde el conector SCM.………....…..……..56 Tabla 3.6: Ejemplo de datos obtenidos desde el conector SCA.………...……..56
Tabla 3.7: Entidad que genera el Motor de métricas para relacionar la información….………....…...…...57 Tabla 3.8: Ejemplo de datos con los que cuenta el sistema previo al análisis de estimaciones.62 Tabla 3.9: Ejemplo de correlaciones calculadas.……….………..62
Tabla 3.10: Ejemplo de estimaciones realizadas a partir de un Tiempo proporcionado.……..64 Tabla 5.1: Ejemplo de estimaciones acertadas y erradas realizadas por Tesys.………..……....97
Capítulo 1: Introducción
La correcta gestión de los recursos es crucial para el éxito de los proyectos, ya que su realización ineficaz puede desembocar en el incumplimiento de los plazos, presupuesto y/o calidad (Ireland, 2006). Los plazos dependen de los recursos disponibles y de la complejidad de cada tarea dentro del proyecto. La calidad depende de cómo los desarrolladores realicen las tareas y de los plazos. Por último, el presupuesto depende del tiempo y el esfuerzo involucrado en el desarrollo de cada tarea. Para cuantificar estas magnitudes, los administradores de proyectos llevan a cabo un proceso de planificación. En la planificación se realiza la gestión de recursos, una de las áreas clave para que la gestión de proyectos se realice de manera correcta. El principal reto es la toma de decisiones que se debe realizar para asignar recursos a tareas debido a los problemas que surgen a la hora de hacerlo (PMI, 2010).
El problema a la hora de tomar una decisión de planificación no es la falta de información, sino el difícil acceso a la misma o la incapacidad de manipularla para darle un uso adecuado (Davenport, 1994). En el contexto de desarrollo de software, la información relevante para la toma de decisiones se conoce como métricas de software (Pressman, 2005). Una métrica de software es una medida cuantitativa en que un sistema o proceso posee alguna propiedad determinada. Sin embargo, la obtención de métricas de forma manual es un proceso costoso, ya que se deben calcular a partir de mediciones que se encuentran en diferentes herramientas del proceso de desarrollo. Es común también que se cuenten con herramientas para la obtención de métricas automatizadas, pero la mayoría de estas solo muestran los resultados obtenidos y no utilizan o especifican cómo debe usarse esa información para crear valor dentro de la organización que lo utilice. Este tipo de información se conoce como conocimiento pasivo (Hiern, 2004).
informativos (Lincke, 2008). Estas métricas que se obtienen, podrían ser utilizadas no sólo para mostrar el estado de un proyecto, sino que también para medir de manera automática el rendimiento individual de los desarrolladores involucrados en el proceso de desarrollo de software, analizando sus habilidades y tendencias para poder predecir su comportamiento de cara a una nueva tarea. Llevar cuenta de las métricas de cada desarrollador por tarea ayuda a la planificación de proyectos en la asignación de desarrolladores a nuevas tareas similares a anteriores (Cohn, 2006).
1.1 Tesis
El principal objetivo de este trabajo es asistir al administrador de proyectos durante el proceso de planificación al momento de la asignación de desarrolladores para las nuevas tareas brindando información actualizada sobre el desempeño de los desarrolladores en los distintos tipos de tareas. Para lograr esto, en esta tesis se desarrolló Telemetrical System (Tesys). Tesys permite integrar las distintas herramientas utilizadas en entornos de desarrollo de software, con el fin de extraer métricas, las cuales permiten realizar un análisis del desempeño de cada desarrollador en cada tarea que realizó. De esta manera, se logra la trazabilidad entre las herramientas de forma que el administrador del proyecto sea capaz de analizar el desempeño de cada desarrollador en cada una de las tareas en base a un conjunto de métricas. En la Figura 1.1 se observa un esquema conceptual del sistema que se desarrolló.
Figura 1.1: Diagrama de contexto general de Tesys.
En la figura se observa que el sistema está compuesto de varios componentes que interactúan entre sí, y a su vez estos, interactúan con sistemas externos. La definición de nuevas métricas y criterios es un administrador de reglas que es utilizado para configurar el sistema. En el mismo se pueden definir funciones aritméticas que sirven para calcular métricas y criterios sobre el conjunto de datos que el sistema procese. Estas reglas son aplicadas por el componente de captura de métricas. El mismo es el responsable de comunicarse con todos los sistemas externos y extraer métricas de los mismos de forma no invasiva. Una vez obtenidas las métricas, este componente las estandariza para poder ser integrarlas en un mismo conjunto de datos donde se aplican las reglas previamente definidas. Este componente almacena las métricas en el componente de almacenamiento catalogadas por desarrollador y por tarea. De esta forma las métricas almacenas pueden ser utilizadas por cualquier sistema de forma sencilla debido a que el componente de almacenamiento está diseñado para trabajar de manera interoperable. A su vez, el mismo, proporciona funcionalidad adicional para realizar búsquedas de manera de poder obtener los datos que los demás sistemas requieran.
El resto del sistema funciona de forma independiente a los componentes previamente explicados ya que hacen uso del componente de almacenamiento de la misma forma que lo harían los sistema de terceros. El componente de estimaciones es el encargado de asistir en la planificación de proyectos brindando estimaciones del desempeño de los desarrolladores en tareas que deban realizarse. Las estimaciones que realiza este sistema se basan en el procesamiento y análisis de los datos mediten métodos estadísticos. Luego, cuando se define como será la tarea futura, el sistema es capaz de estimar cómo se desempeñarán cada uno de los desarrolladores realizando esta tarea. Por último el componente de gráficos es un sistema que sirve para visualizar los datos almacenados mediante diferentes tipos de gráficos para facilitar su entendimiento.
definidas métricas y criterios para los interesados del proyecto. Contar con esas métricas y criterios no solo le permite al sistema visualizarlas mediante gráficos, sino que también le permite realizar recomendaciones o sugerencias a los encargados de administrar el proyecto.
1.2 Organización del trabajo
En esta sección se detalla la estructura general del presente trabajo, brindando una breve descripción de los temas que se abordan en cada capítulo.
El capítulo 2, titulado Estado del arte, presenta los fundamentos teóricos utilizados en este trabajo. Se introducen los conceptos de administración de proyectos, donde se detallan aspectos como la gestión y la planificación de proyectos. Además, se analizan los diferentes enfoques que existen para asistir a la planificación de proyectos y las herramientas que dan soporte a estos enfoques. El capítulo finaliza con la comparación de los diferentes enfoques/herramientas identificando sus limitaciones actuales
El capítulo 3 introduce Tesys que apuntó a mejorar las limitaciones de los enfoques actuales. A lo largo de este capítulo se expone la solución planteada mediante la extracción de métricas desde las diferentes herramientas y la unificación de estas métricas para poder centralizarlas. Además se explica cómo este enfoque permite estimar el desempeño de los desarrolladores.
El capítulo 4 muestra las decisiones de diseño que se realizaron para poder realizar la herramienta que soporta el enfoque planteado en este trabajo. Además se presentan las cuestiones de implementación propias de la herramienta que sirven para poder extender la misma en orden de poder soportar más herramientas de desarrollo de software.
El capítulo 5 presenta las evaluaciones experimentales que se le realizaron a Tesys, dejando claro a través de análisis y comparaciones los beneficios de su utilización.
El capítulo 6 presenta las conclusiones obtenidas a partir de la construcción de Tesys y de su utilización en el caso de estudio. También se presentan cuáles serán los trabajos futuros que podrían desarrollarse a partir de este.
Capítulo 2: Estado del arte
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único (PMI, 2010). La naturaleza temporal de los proyectos indica que se cuenta con un principio y un final bien definido. El final se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto. Temporal no necesariamente significa de corta duración. En general, esta cualidad no se aplica al producto, servicio o resultado esperado por el cual fue creado el proyecto; la mayor parte de los proyectos se emprenden para crear un resultado duradero. Los proyectos pueden tener impactos sociales, económicos y ambientales que durarán mucho más que los propios proyectos.
La administración de proyectos es la disciplina de gestionar todos los recursos necesarios exitosamente, la cual puede y debe aplicarse durante el ciclo de vida de cualquier proyecto (Dixon, 2000). La administración de proyectos asegura que los proyectos sean entregados de acuerdo con los parámetros que se han definido cumpliendo con los objetivos, el alcance, el tiempo y el costo (PMI, 2004). Esto es posible gracias a que brinda conocimiento, habilidades, herramientas y técnicas a los administradores para ayudarlos a planear y ejecutar proyectos en tiempo y dentro del presupuesto acordado.
Los recursos y las actividades son los actores clave en cualquier organización para la realización de un proyecto. El propósito de la administración de proyectos es primero encontrar las actividades necesarias para llevar a cabo el proyecto hasta su fin y en segundo lugar el de asignar recursos a estas actividades de una manera óptima y planificada. Para poder realizar estas tareas a cabo la administración de proyectos propone cinco grupos de procesos (PMBOK Guide, 2013) como se muestra en la Figura 2.1.
Figura 2.1: Secuencia de procesos seguida por la mayoría de los proyectos.
actividades de Cierre, como confirmar la realización de lo solicitado, determinar el grado de satisfacción del cliente, si el proyecto respondió o no a sus expectativas y que se hayan liquidado las facturas correspondientes al cobro (PMBOK Guide, 2013).
El proceso de administración del proyecto representa planear el trabajo y después trabajar según el plan. Las formas y tipos de proyectos son muy diversos, algunos pueden ser pequeños y bien definidos; otros son grandes y complejos. Sin importar el tipo de proyecto que uno debe realizar, si no se aplica correctamente los conceptos de la administración de proyectos, en particular la planificación, crecerá el riesgo de no terminarlo en tiempo y forma y de rebasar el presupuesto planteado (Gido y Clements, 2003).
2.1 Planificación de proyectos
La planificación de proyectos es una de las áreas más importantes de la administración de proyectos y una de las que se debe llevar a cabo lo mejor posible para poder cumplir los objetivos del proyecto (PMBOK Guide, 2013). La planificación es una de las tareas más compleja que se debe llevar a cabo y con frecuencia es necesario realizarla varias veces, además no es una ciencia exacta ya que dos grupos diferentes de trabajadores pueden generar diferentes planes para un mismo proyecto (PMBOK Guide, 2013). En los casos en que las fechas de entrega, los recursos requeridos, los costos o incluso el alcance no sean aceptables, se debe hacer un refinamiento a la planificación.
Existen procesos que se deben llevar a cabo en forma ordenada para poder lograr la planificación de proyectos, entre ellos se distinguen diez procesos principales con dependencias bien definidas (PMBOK Guide, 2013). En la Figura 2.2 se observan los procesos de la planificación de proyectos. Cuando se realiza un refinamiento de la planificación no es necesario llevar a cabo cada uno de estos procesos si la situación lo amerita, solo se deben llevar a cabo los que afecten a los resultados de la planificación que son inaceptables.
Figura 2.2: Los procesos de la planificación de proyectos.
Actividades específicas que se deben llevar a cabo para producir los entregables del proyecto, las cuales serán posteriormente Secuenciadas en función de sus dependencias. Además de definir actividades, se hace un Planeamiento de Recursos , determinando la cantidad de personas, equipos, materiales y demás recursos que deben ser utilizados para llevar a cabo cada actividad. Posteriormente se deben Estimar los Costos de los recursos que se necesitan para completar las actividades, y Planear cuáles de ellos y en qué cantidades deben ser utilizados para llevar a cabo las actividades, además de Estimar el tiempo que será necesario para poder llevar a cabo cada una de las actividades, que junto con la Secuencia de Actividades definen el Desarrollo del Cronograma . El Cronograma analiza la secuencia entre actividades, la duración de las mismas y los requerimientos de recursos para poder crear el cronograma del proyecto. Una vez finalizado el Cronograma de Actividades y teniendo la Estimación de los Costos se puede efectuar un Presupuesto , el cual define el costo total del proyecto. Todos estos procesos deben ser documentados de forma consistente y coherente en el marco de un Plan de Proyecto.
Existen varias herramientas y enfoques de administración de proyectos para asistir a las organizaciones en visualizar el diseño preliminar del plan, reportar el estado actual del proyecto, identificar caminos críticos, proveer información de costos y la duración total del proyecto. Sin embargo, la mayoría fallan a la hora de dar soporte a los procesos de toma de decisiones y no ofrecen asistencia en cuanto a la captura de conocimiento y la planificación de proyectos. Esto último se debe a que la mayoría se dedican al seguimiento de un único proyecto y no se detienen en recopilar experiencias de proyectos anteriores, desaprovechando de esta manera todo el conocimiento previamente adquirido. Normalmente, esta experiencia es sólo adquirida por el equipo de desarrollo y cuando éste es desarmado se lo lleva consigo, perjudicando a la organización (Kransdorff, 1998).
2.2 Métricas de Software.
bien pueden derivar de una o más cantidades directamente observables, por ejemplo líneas de código por hora trabajada . El propósito principal de una métrica es proveer una valoración cuantitativa de la medida en el cual el producto, proceso o recurso cumple con ciertos atributos (CostelloLiu, 1995). Así mismo, ayudan al equipo de desarrollo a entender y monitorear el progreso del proyecto, lo cual puede servir para mejorar el rendimiento del proyecto y la calidad del producto, como también facilitar la administración, el control y la predictibilidad del producto.
La métricas involucran la medición de procesos y productos de software, brindando información de gestión significativa y oportuna, junto con el uso de técnicas para mejorar dicho proceso y su producto (Goodman, 1993). Las métricas permiten al líder de proyecto evaluar el estado actual del proyecto, tener seguimiento de riesgos potenciales, descubrir problemas antes de que se vuelvan críticos, ajustar el flujo de trabajo o las tareas, evaluar la habilidad del 1 equipo de desarrollo para controlar la calidad de los productos de software, etc. Dentro de la planificación sirven como base para la estimación de costos, la planificación de recursos, el desarrollo de cronogramas y la presupuestación. También son usadas en el monitoreo y control para conocer el estado y tener un seguimiento de las actividades de desarrollo con respecto al cumplimiento de los planes. Además son usadas como herramientas para mejorar procesos e identificar dónde debería concentrarse el esfuerzo en dichos procesos, midiendo también el efecto de dichas mejoras. Conocer qué factores medir y poder realizar la captura de métricas sobre esos factores nos brinda la ventaja de poder realizar mejoras sobre lo que se esté realizando, existen diversos enfoques los cuales tienen usan métricas para realizar mejoras.
2.3 Enfoques que asisten la planificación mediante
métricas.
Mediante la maquinaria de medición y/o metodología de procesos los enfoques asisten a la planificación. Maquinaria de medición se refiere al modo en que se recogen y analizan las métricas de software, mientras que metodología de procesos se refiere a las técnicas
específicas utilizadas para mejorar la calidad del esfuerzo del desarrollo de software (Zhang, 2006).
Entre estos enfoques se encuentran el Software Capability Maturity Model Integration (CMMI) (Paulk, et al., 1993; SEI, 1995) el cual sugiere medir cada proceso en cada nivel de madurez para poder mejorarlos y poder controlar los proyectos. El Constructive Cost Model (COCOMO) (Boehm, 1981; Boehm, et al., 2000) es una jerarquía de modelos de estimación de costes de software, el cual se basa en el historial de métricas de proyectos pasados. El Personal Software Process (PSP) (Humphrey, 1995; Humphrey, 1996; Humphrey, 2000) consiste en un conjunto de métodos, formas y guías los cuales les muestra a los ingenieros de software cómo planear, medir y administrar su trabajo. El paradigma GoalQuestionMetric (GQM) (Basili, 1992; Basili, et al., 1988) se basa en la definición de metas medibles y la utilización de métricas de software que ayuden a cumplirlas. Finalmente la Telemetría de Software (Johnson, et al., 2005) es una técnica la cual usa sensores de software que recogen métricas de forma silenciosa y automática útiles para la administración de proyectos. A continuación se describen estos enfoques de una forma más detallada.
2.3.1 Personal Software Process
El Personal Software Process (PSP) es un proceso de automejora para los desarrolladores de software, y un enfoque que se adapta a las técnicas de medición de software a nivel de organización para el análisis de individuos. El objetivo principal de PSP es formar ingenieros con métodos disciplinados para mejorar su desarrollo personal de software, ayudándolos a mejorar sus habilidades de estimación y planeación, establecer compromisos que se puedan cumplir, administrar la calidad de sus procesos y reducir la cantidad de defectos en sus productos. Como complemento a PSP se propone el uso del método PROBE (PROxyBased Estimating) para realizar estimaciones de tiempo y esfuerzo (Humphrey, 1995), las cuales pueden usarse para asistir a la planificación.
(Ferguson, et al., 1997; Hayes, et al., 1997; Khajenoori, et al., 1995) han demostrado que PSP parece ayudar a mejorar el desarrollo de software, la evidencia anecdótica sugiere que el trabajo adicional involucrado en la recolección manual de datos afecta a su adopción (Borstler, et al., 2002; Johnson, et al., 1998). El autor de PSP admite que “ sería agradable tener una herramienta que recopile los datos automáticamente ” (Humphrey, 1995) y si bien existe software para ayudar a esta tarea (Moore, 1999: Henry, 1997; Tuma, 2000) los mismos no son automáticos sino que más bien funcionan como plantillas para ser completadas manualmente. La metodología de proceso define que al final de cada proyecto, los desarrolladores evalúen la forma en que lo llevaron a cabo mediante el análisis de las métricas que recolectaron. Basado en el análisis de proyectos, los desarrolladores profundizan en su proceso de desarrollo, y lo modifican, en un intento de mejorarlo. Un nuevo ciclo comienza con el proceso de desarrollo modificado.
2.3.2 Constructive Cost Model
El Constructive Cost Model (COCOMO) es un modelo de estimación de costo/esfuerzo para proyectos de software. El estudio en el área de los procesos de predicción basados en modelos típicamente involucra recolectar un conjunto de métricas del producto y el proceso tales como tamaño, esfuerzo, complejidad y defectos para un determinado número de proyectos de software ya completados, para luego generar un modelo que se adecue a los datos obtenidos y finalmente utilizarlo para predecir las características de proyectos de software futuros. Dicho modelo utiliza una fórmula de regresión básica con los parámetros que se derivan de los datos de proyectos históricos y actuales, así como las futuras características del proyecto, por ejemplo, un modelo puede predecir que un proyecto futuro de tamaño T va a requerir E personasmes de esfuerzo; otro modelo puede predecir que la implementación futura de un módulo de complejidad C será propenso a una densidad de defectos D. La idea básica detrás de COCOMO y otros procesos de predicción basados en modelos es la comparación entre distintos proyectos ( crossproject). Esta idea trae consigo un número de dificultades a la hora de adoptarse en la práctica que se explicaran en los párrafos siguientes.
de acuerdo con una encuesta llevada a cabo por el Software Engineering Institute (SEI) sobre 542 organizaciones de desarrollo de software (Peterson, 1997), el 67% de las mismas están en el primer nivel de CMMI (el más bajo de todos), lo cual significa que los procesos de estas organizaciones son ad hoc y a veces caóticos (el proceso tiende a cambiar cuando el trabajo cambia), de manera que sólo un tercio de las organizaciones cuentan con las condiciones necesarias para realizar predicciones basadas en modelos.
Segundo, la precisión de predicción de estos modelos depende en gran parte de la calibración de los mismos. Esto puede ser pensado como un problema de consistencia del contexto, sin los proyectos usados para calibrar el modelo no son similares al proyecto que sea desea predecir, el modelo no dará resultados precisos. Si se están llevando a cabo proyectos muy diferentes entre sí de manera simultánea, cada vez que se desee hacer una predicción sobre uno de estos proyectos, el modelo debe ser recalibrado para predecir cada uno de ellos y por ende se necesita diferenciar entre los distintos proyectos históricos y la relación que guardan con los proyectos futuros para saber con cuales debe calibrarse el modelo a la hora de realizar una predicción, tarea que es muy costosa, sobre todo en almacenamiento de los modelos históricos.
Por último, los procesos de predicción basados en modelos son diseñados principalmente para ser usados en las etapas iniciales de un proyecto de software o incluso antes de que los mismos comiencen. Por ejemplo, COCOMO puede estimar que se requerirán 100 personasmes para completar un proyecto de 100.000 líneas de código, sin embargo, cuando 70 personasmes han escrito solo 40.000 líneas de código, el modelo no da ninguna indicación sobre si el proyecto aún está en condiciones de ser terminado de acuerdo a la estimación inicial o si hubo una falla de estimación. Los resultados podrán ser corroborados cuando todo el proyecto esté terminado y en dicha instancia esa información ya es irrelevante.
2.3.3 Paradigma Goal‐Quality‐Metric
que a su vez, son traducidos a metas medibles. Se usa un programa de métricas para cumplir esas metas medibles. Basado en los resultados de la medición, la organización puede generar hipótesis y tomar decisiones para llegar a cumplir con los objetivos de desarrollo de software, y finalmente, cumplir con los objetivos de negocio.
GQM es un enfoque conocido y los casos de experiencias exitosas con este enfoque abundan (Basili, et al., 1996; Fuggetta, et al., 1998; Latum, et al., 1998). El punto clave para una implementación exitosa de GQM parece ser la buena definición de metas medibles y la derivación a métricas de software que pueden ser usadas para proveer información útil para cumplir esas metas. Sin embargo, la principal crítica con respecto a GQM es la falta de un proceso guiado y la brecha entre la definición de objetivos y la selección de medidas (Basili, et al., 1994).
2.3.4 Software Capability Maturity Model
El Modelo de Capacidad y Madurez integrado (CMMI por sus siglas en inglés: Capability Maturity Model Integration) es un framework de madurez de procesos desarrollado por el Software Engineering Institute (SEI) . El objetivo de CMMI es determinar si una organización de desarrollo de software tiene una buena gestión de su infraestructura, y evaluar su nivel de competencia en el desarrollo de productos de software de alta calidad. CMMI es un modelo por niveles, el cual provee un conjunto de requerimientos que las organizaciones de desarrollo de software pueden usar para establecer procesos para controlar el desarrollo de un producto de software. El mismo clasifica la madurez de una organización de software en niveles, desde nivel 1 hasta el nivel 5 el cual es el más maduro, estos niveles se pueden apreciar en la Figura 2.3.
Figura 2.3: Niveles de madurez de CMMI
En el nivel Inicial el proceso de software en este nivel se caracteriza por ser ad hoc y depender de las habilidades individuales para el éxito de los proyectos, como resultado, los tiempos, los costos y la calidad son generalmente impredecibles. El nivel Gestionado garantiza que en los proyectos los procesos se planifiquen y ejecuten de acuerdo con las políticas, realizando un seguimiento de costos y cronograma del proyecto y pudiendo repetir éxitos logrados anteriormente en proyectos de aplicaciones similares. En el nivel Definido todos los los proyectos usan una versión adaptada y aprobada de los procesos de software estándar de la organización para desarrollar y mantener el software. En el nivel Gestionado cuantitativamente existen programas de medición detallados para evaluar los procesos de desarrollo de software y la calidad del producto en base a métricas definidas pudiendo adaptar los procesos de desarrollo a necesidades específicas con resultados predecibles. Por último en el nivel En optimización se cuenta con medios para identificar debilidades y reforzar la prevención de defectos, analizando de forma sistemática datos relativos a la eficacia de los procesos de software para analizar el coste y el beneficio de las adaptaciones y las mejoras.
proceso de medición debe ser implementado, de hecho, algunos autores parecen estar conscientes de la dificultad que requiere implementar un programa de mediciones en una organización de software y mencionan que: “ El mayor problema potencial de un proceso gestionado es el costo de obtener datos, hay una enorme cantidad de mediciones potencialmente útiles en el proceso de desarrollo de software, pero dichos datos son costosos de obtener y mantener ” (SEI, 1995). La telemetría de software puede ser complementada con CMMI proveyendo una forma discreta y automática de obtener métricas y mediciones, como también una forma de analizar dicha información para proponer un cambio del proceso con el fin de prevenir problemas e incrementar la eficiencia.
2.3.5 Telemetría de Software
La telemetría de software es un enfoque para la administración de proyectos en el cual un conjunto de sensores se adjuntan a las herramientas de un entorno de desarrollo para monitorear sin obstáculos el desarrollo de procesos y productos (Johnson et al. 2005). Estos sensores son transparentes al proceso de desarrollo y capturan métricas de forma automática y discreta. Las métricas extraídas son abstraídas en datos concretos, gráficos e informes, con el propósito de representar perspectivas de alto nivel sobre el desarrollo de software, para luego ser utilizados como indicadores en las decisiones de gestión de proyectos y mejora de procesos. La telemetría de software emplea ciclos de detección de problemas del proceso, generación de hipótesis de mejoras, implementación del cambio y validación de la hipótesis para guiar empíricamente la gestión de proyectos y mejora de los procesos de toma de decisiones. La telemetría de software se puede contrastar con otros enfoques que son utilizados para planificar proyectos, en los siguientes párrafos se realizarán dichas comparaciones.
proyecto no deja de bajar ”. Esto se debe a que la telemetría de software no hace ninguna tentativa de construir un modelo de comparación entre proyectos con el fin de hacer una estimación antes de que se comience el mismo, sino que se basa en las modificaciones que son realizadas en el proceso de desarrollo y sus tendencias para hacer estimaciones de corto plazo en el contexto del mismo proceso.
La telemetría de software y GQM se pueden complementar mutuamente. Esto se debe a que GQM define las métricas de software útiles y las relaciona con un proyecto, producto u objetivos de proceso de una organización, mientras que la telemetría de software provee una maquinaria automatizada para la recolección y el análisis de métricas. Por ejemplo, Continuous GQM (Lofi, 2005) intenta implementar GQM de una forma automatizada en el cual los datos son recolectados, analizados y presentados automáticamente con un mínimo esfuerzo humano.
Por último se puede decir que la telemetría de software está estrechamente relacionada con CMMI en dos aspectos. Por un lado, un nivel de madurez alto provee mayor visibilidad de las actividades de desarrollo, proporcionando así, un contexto conveniente para la planificación de la telemetría de software, ya que solo se pueden obtener datos de las actividades visibles del proceso, es decir, CMMI permite que la telemetría de software pueda generar y monitorear mayor cantidad de áreas del proceso. Por otro lado, la telemetría de software ofrece una metodología para la mejora de procesos basada en la retroalimentación cuantitativa de los procesos de desarrollo existentes. Es especialmente útil para que las organizaciones de software alcancen un alto grado de madurez en sus procesos donde se requiere medición cuantitativa. La Tabla 2.1 lista las diferentes medidas según el nivel de madurez CMMI de la organización que se deben recolectar según un estudio realizado por Pfleeger y McGowan sobre la relación entre la medición del software y la madurez de los procesos (Pfleeger, et al., 1990).
Nivel de madurez CMMI Que se debe medir
Nivel 1 – Inicial: ad hoc Baseline
Nivel 2 – Gestionado Proyecto
Nivel 3 – Definido Producto
Nivel 4 – Gestionado cuantitativamente Proceso y feedback para control
Nivel 5 – En optimización Proceso y feedback para cambios del proceso Tabla 2.1: Niveles de madurez del CMMI y que se debe medir en cada uno.
2.4 Herramientas que asisten a la planificación
mediante métricas.
En la actualidad existe una amplia variedad de herramientas que capturan métricas de software para asistir a la planificación de proyectos. Estas generalmente difieren en los métodos que utilizan para lograr una planificación confiable, particularmente en el tipo de métricas que son capaces de obtener y la forma en que las utilizan. Estas herramientas no trabajan todas en contraste, sino que pueden contemplar diversos aspectos del proceso de desarrollo de software. Además, algunas de estas herramientas se pueden complementar algunos de los enfoques de planificación mencionados anteriormente. En las siguientes subsecciones se describe el funcionamiento de algunos de estos trabajos.
2.4.1 Hackystat
en las distintas herramientas, como el editor de texto, el compilador y el sistema de gestión de proyecto. Una vez instalados, los sensores monitorean discretamente las actividades de desarrollo y envían los datos en bruto del proceso y del producto a un servicio web centralizado (Johnson, 2010).
Los miembros del proyecto pueden iniciar sesión en el servidor web para ver los datos recogidos y realizar análisis dirigidos que integran y resumen los datos de los sensores. Hackystat también permite a los miembros del proyecto configurar alertas que monitorean condiciones específicas de los datos procesados y envía un correo electrónico cuando se producen estas condiciones.
Figura 2.4: Vista general de Hackystat. Los sensores están directamente acoplados a las herramientas que los desarrolladores utilizan y envían información a un sistema centralizado.
Hackystat se define a sí mismo como la herramienta de referencia para el enfoque de telemetría de proyectos de software. Se destacan cuatro diferentes formas de adquirir datos para el sistema (Johnson, et al., 2005):
secuencias de herramientas o comandos invocados. Hackystat proporciona sensores para recoger telemetría de desarrollo de editores como Eclipse (Eclipse, 2015) o Emacs (Emacs, 2015), aplicaciones de escritorio como Microsoft Word (Microsoft Office, 2015), herramientas de gestión de código como Concurrent Versions System (CVS) (CVS, 2015) y de gestión de incidencias como Jira (Jira, 2015).
● Telemetría de construcción: son datos recogidos por la observación de los resultados de las herramientas invocadas para compilar, enlazar y probar el sistema. Hackystat puede reunir esos datos de herramientas de construcción como Ant (Ant, 2015), Make (Make, 2015), o CruiseControl (CruiseControl, 2015), herramientas de testing como JUnit (JUnit, 2015) o CPPUnit (CPPUnit, 2015), y el tamaño y la complejidad de herramientas como LOCC (LOCC, 2015).
● Telemetría de ejecución: son datos que Hackystat reúne observando el comportamiento del sistema conforme se ejecuta. Hackystat proporciona sensores para recoger telemetría de ejecución de las herramientas que ponen a prueba para la carga o el estrés del sistema, tales como JMeter (JMeter, 2015).
● Telemetría de uso: son datos que reúne Hackystat mediante la observación de la interacción de los usuarios con el sistema. Estos datos incluyen el comportamiento del usuario, como la frecuencia, tipos y secuencias de invocaciones de comandos durante un período de tiempo determinado en un subsistema dado.
Hackystat cuenta con varias funcionalidades que la hacen una herramienta muy útil para el monitoreo y planificación de proyectos. Además de recolectar métricas mediante los sensores, analizarlas e interpretarlas en un servidor centralizado que relaciona los datos de diferentes fuentes y de permitir definir alarmas en base a condiciones específicas de los datos inferidos, Hackystat también permite visualizar los datos obtenidos mediante gráficos y reportes que facilita la comprensión de determinados valores como así también ayuda a la toma de decisiones en el área de la administración de proyectos. La Figura 2.5 muestra un ejemplo de la interfaz de Hackystat y en particular un gráfico para analizar la cobertura de código de un determinado proyecto.
Figura 2.5: Interfaz gráfica de Hackystat.
2.4.2 SonarQube
SonarQube es una plataforma web para evaluar la calidad de un código fuente, la misma cubre siete aspectos en la calidad de software (SonarQube, 2015).
1. Estándares de Codificación: respecto a los estándares y mejores prácticas de codificación.
4. Código Duplicado: aislar y refinar las duplicaciones. Cada pieza de código debe tener una única representación en el sistema, libre de ambigüedades.
5. Complejidad: equilibrar la complejidad desproporcionada entre los distintos componentes de software, y si es posible eliminarla.
6. Test Unitarios: escribir test unitarios, especialmente para piezas complejas de código. 7. Diseño y Arquitectura: minimizar las dependencias.
El código fuente es analizado de forma estática por diversas herramientas las cuales les brindan datos a SonarQube para generar métricas, luego estas métricas pueden ser utilizadas para analizar el estado del proyecto. Estas herramientas recorren el código fuente realizando chequeos para la detección errores y posibles defectos, cada una desde su propia perspectiva. La naturaleza de estos chequeos van desde los que son de estilo (como por ejemplo, convenciones de nombres), hasta otros más complejos que fácilmente podrían significar potenciales defectos (como por ejemplo, punteros no asignados).
Aunque está pensado originalmente para analizar código Java (Java, 2015), tiene un mecanismo de extensiones ( plugins) el cual permite aceptar más de veinte lenguajes de programación (como C/C++ (Cplusplus, 2015), C# (Microsoft C#, 2015), PHP (PHP, 2015), PL/SQL (Oracle PL/SQL, 2015), entre otros). El mismo mecanismo, permite también agregar diversas herramientas de análisis de código.
SonarQube permite crear un perfil de calidad, con el cual se analizará el código. Este perfil consta en un conjunto de reglas de codificación (las cuales serán aplicadas por los diversos analizadores) junto con sus niveles de severidad, en el caso del incumplimiento de cada regla. Además este perfil permite configurar los umbrales sobre las métricas consideradas críticas y disparar alertas de forma automática. Otra característica es que permite mantener un historial de los análisis realizados para así poder observar la evolución de las métricas en un proyecto de software.
Su motor es soportado por analizadores de código adicionales, los cuales son coordinados por SonarQube para así centralizar los análisis de los mismos (Arapidis, 2014). La Figura 2.6 presenta una vista de los componentes de más alto nivel de la plataforma.
Figura 2.6: Vista de alto nivel de la arquitectura de SonarQube.
2. SonarQube recibe la petición y comienza a analizar el código fuente del proyecto. Este análisis se basa en el perfil de calidad configurado para ese proyecto el cual se encarga de activar, si es necesario, extensiones adicionales.
3. Cuando el análisis finaliza, este es almacenado en una base de datos, para ser referenciado en el futuro por el panel de Sonarqube o el historial de análisis.
4. Finalmente, se actualiza la interfaz de usuario con el nuevo análisis. Los datos se pueden acceder a través del navegador web y visualizar en el tablero de control (dashboard) de Sonarqube.
SonarQube genera un conjunto de métricas que pueden ser extendidas dependiendo de los plugins. Entre las métricas que genera SonarQube encontramos: “ líneas de código ”, “cantidad de archivos ”, “ cantidad de duplicaciones ”, “ cantidad de comentarios ”, “ cantidad de incidencias”, entre otros. Las mismas se pueden apreciar en la Figura 2.7, el cual muestra una vista del panel principal.
Figura 2.7: Vista de métricas en el panel principal de SonarQube.
Aunque esta plataforma por si sola solo permite la obtención de las métricas por proyecto, existen extensiones las cuales pueden obtener las métricas por desarrollador.
Una de esas extensiones es el SCM Activity (SonarSource, 2015), el cual integra SonarQube con los sistemas de control de versiones más populares ( Git (Git, 2015), SVN (SVN, 2015), etcétera). Luego, realiza un mapeo entre el código y los desarrolladores, de manera de tener información sobre los aportes de los desarrolladores. Entre el conjunto de métricas que calcula SCM Activity , se encuentran: “ cantidad de commits ” y “2 commits por desarrollador”, agregando así una nueva categoría de métricas a las ya existentes (uso de herramientas de control de versiones).
La otra extensión es el Developer Cockpit la cual permite identificar métricas sobre cada desarrollador utilizando información del SCM Activity (SonarSource, 2015). Entre el conjunto de métricas que se puede obtener de forma individual se encuentran: “ líneas de código ”, “ cantidad de archivos ”, “ cantidad de duplicaciones ”, “ cantidad de comentarios ”, “ cantidad de incidencias ”, entre otras. En la Figura 2.8 se puede observar una vista del panel general de un desarrollador particular gracias a los datos obtenidos mediante Developer Cockpit.
Figura 2.8: Vista de las métricas proveídas por Developer Cockpit.
2.4.3 CAST Application Intelligence Platform
CAST Application Intelligence Platform (AIP) es un software para la medición y análisis de calidad y tamaño en aplicaciones de software. Está diseñado para analizar vulnerabilidades técnicas y adherencia a los estándares de codificación y arquitectónicos (CAST, 2013). La información generada por CAST AIP tiene varios usos:
● Proveer una vista de la “ deuda técnica ” (Fowler, 2009) y brindar asesoramiento de ingeniería de software a los equipos de desarrollo involucrados en sistemas complejos.
● Visión de los riesgos asociados con la actualización de paquetes de software y capacidad para documentar automáticamente sistemas complejos.
● Proveer información en tiempo real necesaria para mejorar tanto la calidad de la aplicación, así como el rendimiento del equipo de desarrollo.
Entre los tipos de métricas calculadas por AIP se encuentran (Sappidi, 2012):
● Índices de Calidad: El análisis de código estático recorre el código fuente e identifica patrones de código (reglas) las cuales pueden significar defectos potenciales. Categorizando esas reglas en factores de calidad tales como Seguridad, Rendimiento, Robustez, Modificabilidad, etcétera. se puede agregar y asignar un valor específico a cada categoría. De esta manera se puede definir una línea base para cada factor de calidad y así monitorear la calidad total de la aplicación a través del tiempo.
● Reglas Específicas: Los índices de calidad proveen un panorama de alto nivel de la calidad estructural de la aplicación, sin embargo a menudo hay reglas las cuales se busca evitar. Por ejemplo, si la aplicación está sufriendo una degradación en el rendimiento, entonces, se debe asegurar que no se cumpla ninguna regla que degrade aún más el rendimiento. Ese conjunto de reglas se deben etiquetar como “ Reglas críticas” las cuales no son toleradas.
● Productividad: Cantidad de líneas de código, cantidad de funciones, etcétera. Las soluciones de análisis estático proveen esta información.
2.4.4 SQuORE
proveedores de datos y un tablero de control el cual presenta la información de una forma eficiente (Squoring Technologies, 2014). Las fuentes de datos pueden ser herramientas de software, tales como Checkstyle (CheckStyle, 2015), PMD (PMD, 2015), Findbugs (FindBugs, 2015), Polyspace (PolySpace, 2015), Coverity (Coverity, 2015), SonarQube , y artefactos de software tales como el código y casos de tests . Acepta varios lenguajes de entrada, tales como C/C++, Java, entre otros.
2.4.5 Rally Editions
Rally Editions es una herramienta de gestión de proyectos ágiles y colaboración entre equipos que permite planear tareas, llevar un control de las mismas y gestionar los artefactos del proceso. Similar a cualquier herramienta de administración de incidencias como Jira con la salvedad de que en su versión más avanzada ofrece servicios de métricas y análisis de las mismas (Rally, 2015).
Las métricas y análisis que ofrece en forma de reportes o gráficos se realizan siempre a nivel del proyecto y son creadas acorde al Software Development Performance Index (SDPI) un framework de medición investigado y desarrollado en cooperación con el Software Engineering Institute (SEI) en la Carnegie Mellon University (SDPI, 2015). El framework SDPI mide el rendimiento en base a cuatro dimensiones claves de calidad, productividad, predictibilidad y responsabilidad. Además cuenta con formularios y encuestas que ofrecen una guía de cómo usar dichos datos dado el contexto de los mismo para la toma de decisiones en el proyecto (Rally, 2014). La Figura 2.9 muestra un gráfico de Rally Editions sobre cómo representa el rendimiento en un proyecto mediante estas cuatro dimensiones.
Figura 2.9: Gráfico de rendimiento de proyecto en Rally Editions.
2.4.6 Squale (Qualixo)
Squale es una plataforma para medir la calidad del código extrayendo métricas del mismo. Esta plataforma permite analizar aplicaciones de software multilenguajes (incluyendo lenguajes como PHP , Java, C/C++, entre otros) de manera de mostrar un panorama general su calidad. Está inspirado por estándares ( ISO9126) y enfoques ( GQM ) existentes (Squale, 2012).
El proyecto Squale nació a partir del esfuerzo industrial para controlar la calidad del software. Sus objetivos son mejorar y perfeccionar el modelo Qualixo , un modelo de calidad basado en métricas de software usado por grandes compañías en Francia ( Air FranceKLM, PSA PeugeotCitroen ), y apoyar la estimación del retorno de inversión producido por la calidad del software. El modelo Qualixo se puede clasificar como un modelo FactorCriterioMétricas (Zhou, 2012), basado en la agregación de métricas de software en indicadores de alto nivel. La coordinación de Squale es llevada a cabo por Qualixo (Squale, 2012).