You are on page 1of 8

DISEÑO DE LA INVESTIGACIÓN Este trabajo es un estudio de caso que se llevó a cabo para investigar la efectividad del PP en un entorno industrial

. El conjunto de datos se recogieron durante 14 meses a partir de una gran compañía de fabricación italiana. Nuestras principales fuentes de datos son: Métricas PRO ( PROM) [ 65 ] , el sistema de seguimiento de elementos de trabajo , sistema de control de código fuente y el código fuente . Utilizamos los meta - questionmetrics enfoque ( GQM ) [ 4 ] para organizar los datos empíricos análisis . El análisis se divide en dos partes: 1 ) análisis exploratorio de datos [ 74 ] para observar la relación entre PP y DD en el código , y 2 ) de análisis de datos de confirmación para confirmar la relación entre PP y DD desde un punto de vista estadístico . Para llevar a cabo este estudio de caso , se muestra a partir de variables que representan la típica situación sin tener un poder manipularlos [ 85 ] . Por lo tanto , tomamos el papel de observador. Como consecuencia , los conceptos de un grupo de control , un grupo experimental , y un período de control no se aplican a nuestro caso . 3.1 Meta - Pregunta -Metrics Definimos la meta mediante la plantilla estándar GQM de la siguiente manera : . El análisis de código fuente . . Para el propósito de la evaluación. . Con respecto a la relación entre la cantidad de uso de PP y la calidad del código . . Desde el punto de vista de los desarrolladores . . En el contexto de los proyectos de desarrollo de software industrial . En primer lugar , se describen los parámetros de la cantidad de PP y los defectos. . Porcentaje de PP ( % PP ) . Esfuerzo gastado durante PP en el acceso o la modificación de los métodos cambiaron durante el período de observación . En vez del esfuerzo real en pares , utilizamos esta relación , ya que refleja las porciones de esfuerzo en solitario . El período de observación se define de acuerdo a cada pregunta de investigación más adelante en esta sección. El por ciento de PP se define por fórmula donde EP es el esfuerzo del PP de permanencia en el método durante un período de observación y ET es el esfuerzo total gastado en el método en el mismo periodo de tiempo. Por lo tanto , el esfuerzo en solitario estado en el método en el mismo período se puede evaluar de la siguiente manera : ES = ET - ? EP . Densidad de defectos . Utilizamos la relación de defectos por líneas de código para medir la calidad del código . La ventaja de usar la DD en lugar del número absoluto de defectos es que se normaliza y DI BELLA ET AL: . PROGRAMACIÓN Y SOFTWARE PAR DEFECTOS -A GRANDE, INDUSTRIAL CASO PRÁCTICO 937 CUADRO 7 Resumen de los resultados para el PP Distribuida en

Caso 2 : Teniendo en cuenta la hora en que se encuentra un defecto en el método . Por otra parte . La métrica de calidad adoptado en nuestro estudio se basa en la asignación de los defectos de su ubicación original en el código fuente . Este caso considera los mismos métodos que el primer caso . DD por lo tanto. Hemos medido el uso de PP y los defectos en los métodos en varias situaciones . se define un algoritmo de asignación para este propósito . DD se calcula usando el número total de defectos encontrados y LOC del método al final del período de observación . Un método que contiene más de un defecto . Hemos logrado este objetivo .5 ) . % PP ahora se da por la relación entre el esfuerzo de PP y el esfuerzo total gastado antes se ha encontrado el defecto . Como se ha mencionado . con el objetivo de determinar las situaciones en las que PP podría ser más eficaz que en solitario de programación . Caso 1 : Teniendo en cuenta el uso de PP sobre los métodos defectuosos para todo el período de observación. Para cada método . En el segundo caso . reduce tal dependencia . " Este análisis podría utilizarse para estudiar el efecto a largo plazo del PP en la prevención de defectos . se basa principalmente en los resultados del algoritmo aplicado . Los defectos en la DT son parte del 8. Los puntos de los datos incluidos en este caso son los métodos defectuosos que podrían ser asignados a los defectos encontrados durante todo el período de observación (sección 3. El objetivo de esta observación es analizar " si el mayor esfuerzo gastado en los resultados del PP en la menor tasa de defectos en un método . por tanto. El propósito del primer caso es observar la distribución de DD en un método con respecto a la cantidad de PP . Los siguientes casos ilustran este concepto . la cardinalidad de DT cambia de acuerdo a cada pregunta de investigación más adelante en esta sección. % PP es la relación entre el esfuerzo de PP y el esfuerzo total que el desarrollador ( s ) dedicado a trabajar en ese método . la unidad de nuestro análisis es un método ( en clases ) . La métrica de calidad . existe evidencia empírica de que el número total de defectos tiene un patrón de relación con las líneas de código [ 38 ] . lo que podría generar sesgo para el análisis .4 por ciento de los defectos que tiene la información de seguimiento completo durante las correcciones (Sección 3.5 ) . DD se calcula usando el número total de defectos encontrados después. Puesto que no hay enlace directo . por tanto. estamos interesados en la cantidad de PP que se ha gastado en el método antes de la identificación del defecto. DD se define por DD = DT / LOC donde DT es el número total de defectos encontrados en el método y el LOC es Líneas del método de código. considerando los eventos que se producen durante la vida útil del método.Código comparable entre los métodos de diferente tamaño . aparece en los puntos de datos varias veces con diferentes valores de % .

El último caso se centra en la puesta en práctica de una historia de usuario . % PP está ahora evaluó como la relación entre el esfuerzo de PP y el esfuerzo total gastado durante la corrección de defectos . se considera el mismo conjunto de métodos como el cuarto caso . estamos interesados en la cantidad de PP utilizado durante la corrección de defectos y los defectos encontrados después. Esta observación podría utilizarse para comprender la eficacia del PP en la implementación de una historia de usuario . DD se calcula utilizando el número total de defectos encontrados después de que haya comenzado la ejecución . este El análisis tiene como objetivo entender si el uso regular del PP permitan mejorar los conocimientos de los desarrolladores sobre el método (por ejemplo . la introducción de ninguna o menos defectos ) . El cuarto caso se centra en la cantidad de PP que se ha gastado en un método antes de que un desarrollador comienza a modificarlo ( como parte de la aplicación de una historia de usuario ) .de PP y DD . En este caso. Los puntos de los datos incluidos en este caso son los métodos que han sido modificados durante la ejecución de las historias de usuario . Del mismo modo para el segundo caso . En el tercer caso . % PP ahora se da por la relación entre el esfuerzo de PP y el esfuerzo total gastado durante la aplicación . Para cada punto de datos . Caso 5 : Teniendo en cuenta la duración en el que se estaba aplicando la historia de usuario . Este análisis puede proporcionar evidencias de si a menudo es el caso y si PP ayuda a mejorar la situación . Un método asociado a más de una historia de usuario aparece en los puntos de datos varias veces con diferentes valores de % de PP y DD . la puntos de datos son los mismos métodos usados en los dos primeros casos . los métodos que contienen más de un defecto aparecen en los puntos de datos varias veces . DD se calcula usando el número total de defectos encontrados después de la aplicación se ha . En general . DD se calcula usando el número total de defectos encontrados después de la corrección . entender las decisiones de diseño subrayadas y dependencias ) y da como resultado un mejor rendimiento al hacer cambios (es decir . Nosotros medimos la cantidad de PP usado en esta duración y la cantidad de defectos encontrados después. % PP está dada por la relación entre el esfuerzo de PP y el esfuerzo total gastado en que el método antes de que un desarrollador comienza a modificarlo . es probable que los desarrolladores introducir nuevos defectos mientras se cambia el código existente. Caso 4: Teniendo en cuenta el momento en el que se realiza un cambio en el método ( el método se cambió como parte de la implementación historia de usuario ) . Caso 3: Teniendo en cuenta la duración en la que se fijó el defecto.

[ 80 ] . Tabla 11 resume los cinco casos estudiados. Kernel estimación Nadaraya -Watson [ 53 ]. Para estos cinco casos. Una de dos muestras de permutación de prueba [ 91 ] . Los desarrolladores son todos italianos de edades comprendidas entre 30 y 40 años . [ 66 ] . Splines suavizado cúbicos [ 42 ]. El equipo se compone de 17 desarrolladores : 15 veteranos y 2 recién llegados. Aplicamos los siguientes modelos: . con una versión personalizada de XP. Cada miembro del equipo está equipado con una máquina de personal. No planean cuándo hacerlo PP . En particular . . Todos los desarrolladores se encuentran en un espacio de trabajo abierto a estimular el flujo de información y la colaboración dentro del equipo . ni cuándo cambiar los roles . En él se describe el problema de investigación correspondiente a cada caso. Regresión polinómica local (que es una generalización de la estimación del núcleo ) . . es decir . Utilizan PP de manera espontánea. trabajan en pares cuando lo encuentran útil y apropiado . 3. un teclado y un ratón. Todos ellos tienen títulos universitarios en las áreas de informática y tienen de 10 a 15 años de experiencia en programación. El equipo había estado usando XP durante más de dos años antes de nuestro estudio. . consideramos un conjunto diferente de los métodos y la duración de la PP . El equipo trabaja en varios proyectos .3 Contexto El estudio de caso se basa en el conjunto de datos de 14 meses recogido de un equipo de desarrolladores profesionales que trabajan en un departamento de TI de una gran empresa de fabricación italiana ( que prefiere permanecer en el anonimato ) . Esta hipótesis se aplica a todos los cinco casos mencionados anteriormente . métodos asociados para más de una historia de usuario aparecen en los puntos de datos varias veces . Ellos son un equipo ágil . . y el enfoque de la primera prueba . Zero inflado Possion regresión . historias de usuarios. PP . 3. como se describe en la Tabla 11 . . . utilizan iteraciones semanales.completado . Los miembros del equipo no eran conscientes de la finalidad real de nuestro estudio. Llevamos a cabo dos pruebas no paramétricas diferentes para obtener una conclusión válida desde el punto de vista estadístico : . De manera similar a la cuarta caso . Para cada caso. el evento centrado o la duración de la vida útil del método y las suposiciones / limitaciones.2 exploratorio y análisis de datos confirmatorios Realizamos un análisis exploratorio de datos para observar la estructura de los efectos del PP en los cinco contextos considerados. una prueba no paramétrica de Wilcoxon -Mann -Whitney [ 92 ] . se formula la hipótesis nula de la siguiente manera : H0 : No hay diferencia significativa entre un método visitada por completo durante la programación en solitario y un método de acceso durante PP con respecto al DD . principalmente en C #. Modelo de regresión lineal . las partes se centraron de código . con quién. dos monitores .

4. Todos los días . En este estudio . asignado . la duración y los identificadores (ID) de los desarrolladores emparejadas si lo hacen PP durante el marco de tiempo. y cerrado.1 Fiabilidad de datos y privacidad Consideramos que los datos recogidos por PROM muy fiable por las razones siguientes : . sistema de control de código fuente y el código fuente . 3.3.4 Los datos y recopilación de datos Hemos combinado varios tipos de datos en bruto para preparar las métricas . Además . Se describen datos y fuentes en la Tabla 12 . clasificamos los elementos de trabajo en tres categorías: los defectos . las historias de usuario y tareas. hemos desarrollado una aplicación para identificar las partes del código que los desarrolladores cambiaron cuando se trabaja en un elemento de trabajo específico. los desarrolladores recibido informes de tiempo que contienen el porcentaje de tiempo dedicado a cada aplicación en el día anterior. durante todo el período de estudio. Cada interacción consiste en una indicación de la hora . Desarrolladores estaban familiarizados con la interfaz de PROM y PP plug-in. PROM registra automáticamente el esfuerzo dedicado a cada elemento de trabajo . los desarrolladores pueden especificar el elemento de trabajo que están trabajando actualmente. El conjunto de datos recogidos por la PROM se compone de una serie de marcos de tiempo que representan la interacción de los desarrolladores sobre el código fuente y una serie de actividades de PP . Los datos que representan las actividades de los desarrolladores se han recogido a través de PROM [ 25 ]. Por lo tanto . . Por medio de este plug-in. verificado . . Los posibles estados de un elemento de trabajo son los siguientes : creado . De esta forma. el nombre de un método centrado en la actualidad o de una clase . Recoge un conjunto personalizable de producto y de proceso medidas [16]. El conjunto de datos para este estudio se recogió principalmente de los siguientes cuatro fuentes de datos : PROM . los desarrolladores no se distrae de su trabajo diario y que no cambió su comportamiento habitual debido al estudio en curso . Estaban usando la herramienta durante un par de meses antes de empezar la recogida de datos. les pedimos a los desarrolladores para comprobar los datos muy cuidadosamente y reportar cualquier inconsistencia. El conjunto de datos para este estudio se recogió de forma no invasiva . El diseño de la RPM se basa en una arquitectura de plug-in que permite que la herramienta se integrará en un entorno de desarrollo y aplicaciones de oficina. [ 26 ] . RPM es una herramienta automatizada para la recolección de datos y análisis no invasivo que se ejecuta en segundo plano en el equipo del desarrollador. Los desarrolladores han confirmado la . [ 65 ] . resuelto. los desarrolladores no se distraigan de su trabajo diario durante el proceso de recolección de datos. Utilizamos esta información para analizar la eficacia de los PP cuando se trabaja en las diferentes categorías de los elementos de trabajo . sistema de seguimiento de elementos de trabajo . Antes del inicio del estudio. El gestor de puntos de la historia (SPM ) es un plug-in de PROM que se encarga de vincular los métodos de la clase con los elementos de trabajo que se tiene acceso por los desarrolladores cuando trabajando en un trabajo en particular elemento .una unidad de trabajo en un proyecto.

Los desarrolladores fueron informados en detalle acerca de la RPM y qué tipo de datos que recoge . b . No obstante . La entrada a este paso fue la lista de eventos generados por PROM -SPM .Tn ) se pudo determinar . Identificación de defectos con información suficiente. durante nuestro estudio ninguno de los desarrolladores decidieron dejar por completo la recolección de datos. podría haber una limitación interna de la herramienta que recopila datos. Por lo tanto . para cada defecto . Condiciones preliminares Así. La entrada a este paso fue el marco de tiempo de corrección de defectos (T1. La información esencial incluye : la identificación de defectos. Identificación de una secuencia de marcos de tiempo cuando los desarrolladores están trabajando en un defecto particular. se identifican los métodos que se han cambiado durante la actividad de corrección de defectos . El estado final de la corrección de defectos era "completo" y que introdujo cambios en el código fuente. Sin embargo .5 Defectos Correlación de código fuente para medir DD en cada método de la clase . Por otra parte . 3 . 3. Esta lista contiene los métodos a través del cual un desarrollador estaba navegando en localizaciones de defectos y errores. es importante mencionar que la participación en el estudio fue de carácter voluntario [ 15 ] . PROM no registró si un acceso a un archivo era leer el fichero o para modificarlo. La identificación de una lista de métodos o clases que se accede durante la corrección de defectos.Mn) invocado durante cada periodo de tiempo. hizo una pausa. Para ello. Como tal . se definen como un archivo. los datos recogidos se almacenan primero en la máquina del desarrollador. 2 . el estado . nos un mapa defectos en sus ubicaciones en el código fuente . Si bien la herramienta es capaz de discernir los periodos de inactividad largos en la computadora y eliminarlos del tiempo total grabado (por lo tanto a partir de los datos considerados en nuestro estudio) . identificamos la lista de métodos ( M1. Al comparar el tiempo de trabajo en el conjunto de datos PROM . Este tipo de interacción puede ser fácilmente generado desde los desarrolladores trabajan en un entorno compartido donde la comunicación informal es frecuente [ 14 ] . el título . como se analiza por Coman et al . el paso siguiente identifica los métodos que se acceder y . no es capaz de discernir las interrupciones cortas ( segundos o unos pocos minutos ) . Llevamos a cabo los siguientes pasos para dicho mapeo : 1 .exactitud de los datos recogidos. En cuanto a la integridad de datos. Además. dicha información fue esencial para este estudio. reanudó y se detuvo. y las marcas de tiempo de cada cambio de estado. El conjunto de datos recogidos por la RPM es altamente confidencial. la razón (resolución) . Información durante el ciclo de vida del defecto se registró suficientemente . [ 14 ] . La herramienta genera y envía un evento al baile servidor cuando se inicia una sesión de trabajo en un elemento de trabajo específico .Tn) y los datos de interacción de código del desarrollador de código recogidos por PROM . la secuencia de marcos de tiempo de corrección de defectos (T1. la persona responsable de cada cambio de estado . Los desarrolladores pueden acceder a su propia base de datos y decidir si enviarlo a la base de datos central o para borrar .

377 métodos se modificaron durante 39 correcciones de defectos y 1904 se modificaron los métodos de 144 implementaciones de la historia de usuario .8 por ciento) corresponden a este caso . se aplicó el mismo mecanismo para identificar una lista de los métodos que se han cambiado durante la ejecución del caso de usuario y tareas generales . La segunda y la tercera etapa es necesario identificar un conjunto de marcos de tiempo y métodos asociados a cada elemento de trabajo. el equipo trabaja en los casos de usuario en orden de prioridad . El número máximo de defectos por cada método es 4 . Este valor representa el nivel de importancia para el cliente . 93. Esta información se utilizó para el análisis exploratorio . sólo tres métodos ( 0.4 por ciento de los defectos encontrados durante el período de observación al código fuente . se generó un programa para realizar el seguimiento del estado de un método cuando su fichero propiedad o clase cambiaron. La figura 4 muestra cómo estos defectos se distribuyen sobre los métodos 377 . hemos sido capaces de asignar el 8. cada historia de usuario está asociada con una cierta prioridad dada por el cliente. 3. La mayoría de los métodos ( 352 . Como resultado . Se necesita la cuarta etapa de distinguir esos métodos modificados para las correcciones de defectos de los modificados para otros fines . hubo un 8. La Tabla 13 resume la cantidad de elementos de trabajo que queda después de que se aplicó a cada uno de los cuatro pasos .6 Estadística Descriptiva Para resumir el número de métodos asociados a la implementación de cada elemento de trabajo .37 por ciento ) contiene sólo un defecto . Las tareas generales estaban relacionados con el documento . Estos datos proporcionan una lista de archivos y clases que se han cambiado para cada confirmación . 3 presenta el número total de métodos que están siendo accedidos y modificados por las correcciones de defectos y la aplicación de las historias de usuario . La entrada a este paso fue el registro de cambios del sistema de control de código fuente . La Tabla 14 muestra los estadísticos descriptivos de la prioridad de los defectos y las historias de usuario . Sin la información adquirida a partir de la tercera etapa . 4 . En total. Uso de la API del sistema de control de código fuente . 1 que indica la prioridad más alta . Para representar la prioridad tanto de las historias de usuario y los defectos . lo que significa que las historias highPriority a aplicarse . en lugar de para el código . Un total de 213 . La identificación de un subconjunto de métodos que se están modificados durante las correcciones de defectos . En la empresa .77 por ciento) contienen dos defectos .8 por ciento de los casos de usuario con información completa durante la implementación . La figura .4 por ciento de los defectos con información de seguimiento completo durante las correcciones de defectos y el 8.modificar durante la corrección de defectos . Además de las correcciones de defectos . fig. Como se mencionó anteriormente . no sería posible determinar los efectos de los cambios detectados para cada confirmación . 18 métodos ( 4. Cuatro métodos ( 1. El objetivo de este algoritmo es el de identificar la lista de métodos modificados durante la corrección de defectos y de los plazos en los que el desarrollador ha trabajado en esos métodos. un ordinal se utiliza la escala ( de 1 a 3 ) .06 por ciento) contienen tres defectos .

Fuera de 430 defectos con la información suficiente para el análisis (sección 3. El análisis de la relación entre la prioridad ( de los defectos y las historias de usuario ) y el tiempo necesario para completar el trabajo se presenta en la Sección 5 (caso 3 para las correcciones de defectos y el caso 5 para las implementaciones de la historia de usuario).5 ) . y sólo un defecto tiene prioridad 3 . 378 defectos mantener la prioridad 2 . 1351 tienen prioridad 2 .568 casos de usuario mantenga la prioridad 1 . . y sólo cuatro de usuario historias tienen prioridad 3 . 51 defectos mantener la prioridad 1 .de cada 1.