Estudio de Mapeo sobre Adopcin de Inspecciones de Software

Daro Macchi, Martin Solari

Universidad ORT Uruguay macchi@uni.ort.edu.uy, martin.solari@ort.edu.uy

Abstract. Se quiere determinar si existe una preocupacin sobre como incrementar el uso de inspecciones de software, siendo la evidencia de sus beneficios tan abundante. Se realiza un estudio de mapeo para responder esta pregunta, conocer los temas de mayor investigacin en el rea y listar factores causantes de la baja adopcin. Como resultado se obtiene evidencia de que problema de adopcin existe y la comunidad cientfica se encuentra interesada en l. Respecto a los factores, la mayora se encuentran relacionados con la percepcin que tienen los desarrolladores respecto al proceso, la falta de capacitacin y algunas caractersticas propias del proceso como la rigidez, la complejidad y la dificultad de conectar el esfuerzo realizado con la calidad del producto final. Estos factores deberan de ser objeto de estudio en futuros trabajos.

Introduccin

Se estima que entre el 50% y el 60% del esfuerzo total de producir software se invierte en tareas de aseguramiento de calidad [1]. Por otra parte, de acuerdo a un estudio realizado en el 2002 por el NIST (National Institute of Standards and Technology) la entrega de software defectuoso le cuesta a los Estados Unidos $59.5 billones por ao, de los cuales $22.2 billones podran ahorrarse mejorando la infraestructura de testing, revisiones e inspecciones [2]. Humphrey dijo que la calidad de los productos de software depende directamente de la calidad del proceso que los genera [3]. Dentro de estos procesos, los de verificacin y validacin permiten evaluar si un software cumple con los requerimientos y con el uso previsto. Tambin permiten detectar defectos en los artefactos de software lo que contribuye a aumentar la productividad y reducir el esfuerzo de retrabajo. Estos conceptos no solamente son aplicables al cdigo, sino tambin a todo artefacto elaborado durante el proceso de desarrollo. Normalmente cuando se utiliza el trmino inspeccin de software se hace en referencia al mtodo introducido por Michael Fagan [4], el cual puede verse en la Figura 1. Esto se debe a que la mayor parte de los mtodos de inspeccin que existentes son variantes del mtodo de Fagan. Por ejemplo se quitan o agregan elementos del proceso como en el mtodo de Gilb y Graham [5]. En otros casos se

Daro Macchi, Martin Solari

modifica la cantidad de participantes, como en el caso del mtodo limited logging meeting, o la distribucin en distintas locaciones fsicas virtual logging meeting [6].

Figura 1. Proceso de inspeccin segn IEEE-1028 2008.

Existen distintos mtodos manuales (o semi-automticos) de detectar anomalas que complementan el testing, estandarizados por IEEE [7]. La inspeccin de software es el mtodo ms formal en cuanto a sus procedimientos y se realiza con el objetivo de producir resultados ms repetibles [4]. Consiste en un proceso de revisin utilizado para mejorar la calidad del software, documentos relacionados y de todo artefacto que sea producido durante el proceso de desarrollo de software. Un mtodo menos formal es el de las revisiones (tcnicas y de gestin) cuyo objetivo es examinar uno o varios productos para darlos a conocer y comentar sobre ellos. Por ltimo tenemos el enfoque ms informal llamado walkthrough que consiste en un anlisis esttico guiado que se desarrolla durante una sesin buscando anomalas o violacin de estndares. Algunos autores califican a los walkthroughs como una debilitacin del proceso formal de inspecciones [8]. Segn el estndar IEEE 1028-2008 [7], los anteriores conceptos se definen de la siguiente forma: Inspeccin: examen visual de un producto de software con el objetivo de identificar anomalas, errores y desvos con respecto a estndares o especificaciones. Revisin: Proceso o reunin donde un producto, varios productos o un proceso de software son presentados al personal del proyecto, gerentes, usuarios, clientes, auditores o cualquier otro interesado a los efectos de ser examinado, comentado o aprobado. Walkthrough: tcnica de anlisis esttico donde el diseador o desarrollador gua a los miembros de un equipo de desarrollo a travs del producto de software mientras los participantes pueden hacer preguntas o realizar comentarios sobre posibles anomalas, violacin de estndares u otros problemas. Los resultados obtenidos al realizar inspecciones de software son generalmente conocidos y aceptados, encontrndose presentes en muchas publicaciones. Por ejemplo se afirma que este mtodo tiene hasta un 85% de eficiencia en la remocin de

Estudio de Mapeo sobre Adopcin de Inspecciones de Software

defectos, con un promedio del 65% [9]. Tambin se indica que, combinado con prcticas habituales de testing, se puede llegar a reducir hasta en un factor de 10 la cantidad de defectos detectados [8]. Este trabajo se encuentra motivado por el aparente problema de la baja adopcin de procesos de inspeccin de software [10] [11] en contraposicin con la abundancia de reportes positivos respecto a su efectividad en la remocin de defectos. El objetivo de este artculo es obtener un mapa de los factores que dificultan la adopcin inspecciones de software. Para ello se realiza un estudio de mapeo de forma de obtener una clasificacin de los trabajos de investigacin recientes y una lista de factores extrados de los mismos. A diferencia de una revisin sistemtica, el estudio de mapeo plantea responder varias preguntas de investigacin sobre un tema amplio dentro de la Ingeniera de Software usando a menudo una estrategia de bsqueda menos estricta [12]. De sta forma tambin se busca establecer si la comunidad cientfica ha planteado inquietudes similares a las que motivan a este artculo en los ltimos aos. El resto del documento se estructura de la siguiente forma: la seccin 2 plantea los trabajos previos a este y definiciones; en la seccin 3 se explica el mtodo de investigacin y los detalles del estudio de mapeo llevado a cabo; la seccin 4 muestra los resultados de la investigacin, (tanto la clasificacin de los artculos como el procesamiento de los mismos); en la seccin 5 se discuten los hallazgos realizados en la seccin anterior y su relacin con los objetivos generales del trabajo; por ltimo, la seccin 6 resume las conclusiones a las que se lleg durante la realizacin de este trabajo.

Trabajos relacionados

Es comnmente aceptado que las inspecciones de software son de gran utilidad a la hora de producir software de mejor calidad. Por ejemplo, Aurum et al. mencionan como principal beneficio que puede aplicarse a cualquier artefacto producido durante el proceso de desarrollo de software [13]. Laitenberger dice que es un mtodo probado de deteccin y remocin de defectos en artefactos de software ni bien el artefacto es creado [14] y que es una de las tcnicas ms efectivas de aseguramiento de la calidad dentro de la Ingeniera de Software [15]. Por otro lado, hay autores como Wiegers, que afirman que muy pocos profesionales conocen los mtodos de inspeccin de software 1 y muchos menos realizan inspecciones efectivas [16]. Iisakka et al. dicen que no todas las empresas tienen el poder para implementar inspecciones eficientemente y que personalmente nunca vieron ninguna empresa seguir la tcnica formal de Fagan [17]. En un estudio centrado en el retrabajo como factor de costo significativo en el desarrollo de software, se afirma que si bien empresas lderes del sector industrial realizan inspecciones (los beneficios se encuentran verificados y documentados), la industria en general no realiza inspecciones [8].

Tcnica que da origen al concepto de inspeccin de software.

Daro Macchi, Martin Solari

La contraposicin de evidencia acerca de los beneficios de las inspecciones de software y la baja adopcin en la industria ha sido tratada por varios investigadores. Por ejemplo, Stewart y Priven, realizando un anlisis exhaustivo acerca de la evolucin de los mtodos de inspeccin, se cuestionan la falta de adopcin por parte de la industria y llegan a listar una serie de causas y posibles soluciones [18]. Weller, haciendo un anlisis acerca del ROI (Return of Investment) de las inspecciones de software, plantea su asombro al ver el nmero de organizaciones de desarrollo de software que no hacen uso de estos mtodos [19]. Otro trabajo relevante es el libro High Quality, Low Cost Software Inspection, [10], el cual aborda el tema de inspecciones desde un punto de vista prctico planteando algunas causas subyacentes al problema de la falta de adopcin. Esta visin prctica se complementa con el trabajo de Ciolkowski et al. quines motivados por el mismo problema, realizaron una encuesta para conocer cmo y de que forma la industria realiza inspecciones. Dicha encuesta confirma que el grupo de empresas participantes realizan inspecciones regularmente pero estas no se llevan a cabo de forma sistematizada [11]. Por ltimo, la revisin sistemtica realizada por Kollanus et al. clasifica los artculos referentes a inspecciones de software publicados desde 1980 a 2008 y analiza el volumen de trabajos dentro de cada clase de la taxonoma planteada. Esta taxonoma clasifica los trabajos en tres clases: los que tratan temas tcnicos, los que tratan aspectos gerenciales de las inspecciones y otros. Luego cada clase se divide en subclases para poder organizar el conocimiento. La principal conclusin a la que dichos autores arribaron es que se deben realizar ms estudios empricos para validar el efecto de las distintas propuestas tericas en la prctica [1].

Mtodo de investigacin

El mtodo consiste en realizar un estudio de mapeo para conocer los trabajos de investigacin recientes, su relacin con la adopcin de inspecciones y encontrar factores que puedan estar afectando dicha adopcin. El estudio de mapeo es un mtodo definido para construir clasificaciones a los efectos de obtener un resumen visual, un mapa, del conocimiento correspondiente a un campo de la Ingeniera de Software. El anlisis de los resultados se centra en las frecuencias de las publicaciones dentro de cada categora de la clasificacin permitiendo determinar la cobertura de las distintas reas dentro de un campo de investigacin. La informacin relevada se puede combinar para responder a preguntas de investigacin ms especficas. El uso de esta herramienta es reciente y se sugiere en casos donde el tema a cubrir es amplio dentro de la Ingeniera de Software. Tambin se sugiere el mtodo de estudio de mapeo para identificar tpicos donde existan suficientes estudios primarios para conducir revisiones sistemticas y tpicos donde se necesiten generar ms estudios primarios [12].

Estudio de Mapeo sobre Adopcin de Inspecciones de Software

La planificacin del estudio de mapeo se realiza siguiendo los lineamientos propuestos por Kitchenham et al.[12] y las preguntas de investigacin a responder en este estudio son las siguientes: 1. Qu temas interesan a la comunidad respecto a inspecciones de software dentro de un marco temporal reciente? 2. Existe evidencia sobre la baja adopcin de tcnicas de inspecciones de software? 3. Qu factores son mencionados como causantes de la baja adopcin? 4. Qu soluciones se han planteado al respecto? La estrategia de bsqueda debe tener en cuenta el problema de terminologa existente respecto a inspecciones de software. La denominacin de los distintos procesos de revisin de software son frecuentemente utilizados de manera imprecisa. No existe un acuerdo acerca de qu es un proceso de inspeccin y qu lo diferencia de un walkthrough o de una revisin [13]. Por este motivo se realizan distintas bsquedas relacionadas con el tema de investigacin a los efectos de refinar el vocabulario y conocer el uso de sinnimos (algunas veces mal utilizados) para poder generar cadenas ms potentes. Las bsquedas se realizan en publicaciones arbitradas del rea computer science, sin demasiadas restricciones en cuanto a las fuentes de los artculos cubriendo los trabajos del 2007 a la fecha. Este perodo de tiempo fue seleccionado tomando como base un trabajo anterior que cubre los trabajos hasta el 2008 [1]. El criterio de inclusin adems tiene en cuenta aquellos trabajos que tratan sobre inspecciones de software cubriendo aspectos tcnicos, de gestin y conocimiento generado. A la hora de excluir, se quitan aquellos trabajos que no traten de inspecciones de software. La fuente de datos seleccionada para realizar la bsqueda de documentos es la base de datos SciVerse Scopus2 la cual tiene una amplia cobertura de publicaciones del rea computer science (entre otras) e indexa varios catlogos de publicaciones (incluidas IEEE, ACM, Springer y Elsevier). Para la extraccin de datos y procesamiento de los artculos se siguen las guas provistas por Petersen et al. [20]. Los datos necesarios para responder la pregunta 1 se obtienen del anlisis de ttulos y abstracts. Si bien en las guas se sugiere la exploracin de algunas partes del artculo solo en aquellos casos donde el abstract no se encuentra bien estructurado, para esta investigacin se decide realizar la lectura del texto completo. De esta forma se puede responder a las preguntas 2, 3 y 4 ya que el solo hecho de analizar ttulos y abstracts no basta. Tambin se incluyen aquellos trabajos que tratan el tema de la adopcin directamente (mencionados en la seccin 2). Debido a que en un principio el volumen de informacin con la que se debe trabajar es desconocido, se realiza una bsqueda inicial para obtener una primera impresin. El resultado de la misma, utilizando la cadena de bsqueda software inspection, fue de 223 trabajos. La Tabla 1 resume las distintas variantes utilizadas (desestimando las diferencias entre conceptos) y el resultado de cada una. Algunas de
2

Accesible a travs del portal Timb, al cual accede la comunidad de investigadores en Uruguay gracias a la Agencia Nacional de Investigacin Innovacin (ANII).

Daro Macchi, Martin Solari

estas variantes no son tenidas en cuenta en el resultado final debido a dos motivos diferentes. El primero, high recall (HR), se da al obtenerse toda la informacin relevante ms una gran cantidad de informacin de poca utilidad para la investigacin. El segundo, low precisin (LP), sucede al ser muy chica la proporcin entre la cantidad de documentos relevantes obtenidos en la bsqueda y el total de resultados [21].
Tabla 1. Resultado de variantes en string de bsqueda por ttulo. String (solo TITLE-ABS-KEY) software inspection software review inspection walkthrough walkthrough AND inspection walkthrough AND verification reading techniques inspection methods # 57 22 ~2000 ~200 23 6 22 167 Motivo # aplican 41 12 Precisin 72% 55% ~0% ~0% ~0% 50% 41% ~0%

HR,LP HR,LP LP 3 9 LP

La precisin que vemos en la tabla se obtiene de calcular el porcentaje entre aquellos trabajos que se encuentran comprendidos por el criterio de inclusin y los que no lo hacen.

Resultados

Luego de aplicados los criterios de inclusin y exclusin y realizada la unin de resultados de las distintas cadenas de bsquedas, se obtiene un total de 65 trabajos que aplican al tema de investigacin. Los resultados del estudio de mapeo se presentan como respuesta a cada una de las preguntas planteadas en la planificacin. La respuesta a la pregunta sobre los temas de inters para la comunidad en un marco temporal reciente se presenta como una clasificacin de los artculos obtenidos en la bsqueda y su resultado puede verse en la Tabla 2. Para realizar la clasificacin se utiliza la taxonoma usada por Kollanus et al. la cual tiene bien definidos los criterios a seguir para determinar la pertenencia o no a una categora [1]. Tambin se tuvo en cuenta las guas provistas por Petersen et al. [20] para realizar esquemas de clasificacin.

Estudio de Mapeo sobre Adopcin de Inspecciones de Software Tabla 2. Resultados (absolutos y relativos) clasificados segn taxonoma. Clase/subclase Vista tcnica Factores de efectividad Otros temas tcnicos Procesos Tcnicas de lectura Vista de Gestin Impacto de inspecciones en proceso de desarrollo Otros temas de gestin Otros temas principales Vista integral Estimacin de defectos Herramientas de inspeccin Aprendizaje Temas sin clasificar Cantidad (34) 15 5 12 2 (6) 3 3 (25) 3 3 8 6 5 Porcentaje 52,3% 23,1% 7,7% 18,5% 3,1% 9,2% 4,6% 4,6% 38,5% 4,6% 4,6% 12,3% 9,2% 7,7%

La subclase Aprendizaje no se encuentra definida en la taxonoma original y fue agregada ya que existen una serie de artculos que tratan sobre gestin de conocimiento y aspectos cognitivos que se queran destacar y separar de la subclase Temas sin clasificar. Respecto a la pregunta sobre si existe evidencia que confirme la sospecha de la baja adopcin de procesos de inspeccin, la respuesta es que si. Se encontr que no se ha logrado un amplio uso de inspecciones de software [22], que no han tenido el xito esperado [10] a pesar de los esfuerzos para mejorar el proceso [23] [24] y que existe un gap entre el conocimiento sobre su utilidad y el estado real de la prctica [25]. Existe un gran nmero de empresas de desarrollo de software que no utilizan inspecciones [19] [25] y las que s, lo hacen de forma no sistemtica y con pocos conocimientos [11] [23]. Tambin hay autores que se cuestionan abiertamente el hecho de que a pesar de los beneficios comprobados de las inspecciones, estas no se practiquen [10] [19] [16]. La pregunta acerca de los factores causantes de la baja adopcin se responde listando los mismos, pero dado el volumen encontrado y la diversidad, se usa una codificacin. La codificacin unifica el trmino usado para referirse a factores que son conceptualmente lo mismo, pero mencionados en forma diferente en los artculos. Por ejemplo, existen afirmaciones que indican como principales factores algunas caractersticas propias del proceso como ser la dificultad y rigurosidad [22] [26]. Dentro de este mismo grupo existen factores ms subjetivos que vale la pena investigar ya que las inspecciones son vistas como actividades aburridas, que no generan valor y que provocan prdidas de tiempo [27] [28] [26]. Tambin existen afirmaciones que indican como principal factor la falta de capacitacin o el desconocimiento de las tcnicas de inspeccin [18] [10] mientras que Shull et al. mencionan la curva de aprendizaje como principal dificultad [28]. Por ltimo existen factores de costo a considerar. La Tabla 3 muestra la frecuencia con la cual aparecen los distintos factores en los artculos procesados.

Daro Macchi, Martin Solari Tabla 3. Frecuencia de factores causantes de la baja adopcin. Factor
Caractersticas propias del proceso o percibidas como parte del mismo Falta de conocimiento y entrenamiento de los inspectores Inspecciones son consideradas costosas (aumento del costo upfront) Falta de adaptacin y mejoras del proceso segn el contexto donde se aplique Falta de herramientas de gestin, soporte, anlisis del proceso y sus resultados Falta de tiempo asignado a las inspecciones durante la planificacin Falta de monitoreo y registro de la ejecucin del proceso y de resultados Malas experiencias previas y experiencias fallidas sin reportar Falta o consumo intensivo de recursos Resistencia al cambio Desarrollo distribuido Rol de facilitador Otros

#
19 9 5 4 4 4 3 3 2 2 1 1 7

Por ltimo se gener una lista (Tabla 4) con algunas soluciones planteadas por distintos autores para responder a la ltima pregunta.
Tabla 4. Soluciones planteadas resultantes del estudio de mapeo. Planteo de solucin
Nuevos procesos de inspeccin fciles de implementar, que no requieren casi documentacin y adaptables. Mejora la habilidad de modificar cdigo a travs de inspecciones. Utilizar la informacin generada durante una inspeccin para entender mejor las salidas del proceso. Otros usos de inspecciones como inspeccionar casos de test (identificar test smells). El uso generalizado de inspecciones de software es ms un tema de liderazgo que tcnico. Soporte a la innovacin por parte de la gerencia. Definir un champion dedicado. Material de apoyo para los inspectores. Informacin mostrando resultados de inspecciones en contextos similares. Adaptar el proceso al contexto sin quitar las partes ms importantes. Integrar el proceso de inspeccin al de desarrollo dejando de ser opcional su uso. Uso de tcnicas de lectura sistemticas para disminuir dependencia respecto a la experiencia del inspector.

Ref.
[22] [23] [27] [28] [29] [26] [26] [30] [26] [30] [26] [30] [26] [30] [26] [11] [11] [11]

Discusin

Del estudio de mapeo se obtuvieron resultados que coinciden con lo mencionado por otros autores contribuyendo a reafirmar ciertos conceptos que sern usados para realizar un aporte sobre el problema de la adopcin de inspecciones de software. Por ejemplo, Laitenberger & DeBaud [15] mencionan que han habido muchas contribuciones en forma de nuevas metodologas lo que concuerda con los resultados del estudio dado que una de las subclases de mayor actividad es la de Procesos. Tambin se mencionan contribuciones en forma de mejoras incrementales (prometiendo aumentar los beneficios de las inspecciones) lo que concuerda con que la subclase Factores de efectividad sea una de las ms activas.

Estudio de Mapeo sobre Adopcin de Inspecciones de Software

El volumen de trabajo en la subclase Procesos es evidencia del problema planteado por Shull et al. acerca de que en forma frecuente nuevas tecnologas son propuestas pero nunca llegan a salir del ambiente acadmico y las que si lo hacen generan muy poca informacin emprica [31]. De esta forma la industria tiene una gran variedad de tecnologa para elegir pero muy pocas guas y evidencias que contribuyan a la toma de decisiones acertadas. Esto lleva a afirmar que uno de los problemas que ha llevado a que las inspecciones no sean una prctica habitual en la industria es la confusin entre los distintos mtodos de revisin [8]. Sera interesante encontrar una relacin entre el volumen de trabajos dentro de la clase Vista tcnica de la taxonoma con las causas del problema de adopcin antes mencionadas. Un posible camino de investigacin podra ser descubrir si los problemas de adopcin se han intentado atacar creando o modificando tcnicas de inspeccin en lugar de tratar de entender que pasaba con las ya existentes. Esta sospecha podra estar sustentada en que faltan datos empricos que permitan validar propuestas tericas [1] [31]. El procesamiento de los resultados del estudio de mapeo dej una lista de evidencias sobre el problema de la adopcin de inspecciones de software. Este hecho confirma que el tema de la adopcin es de inters para la comunidad y que se debe trabajar ms en l. Otro resultado de este anlisis es que las empresas que realizan inspecciones no lo hacen de forma sistemtica [11] [23], lo que agrega al problema de la adopcin otro factor que es el de la calidad con que se realiza dicha adopcin. Con respecto a los factores causantes de la baja adopcin, se puede ver en los resultados de la Tabla 3 que el que aparece con mayor frecuencia tiene que ver con caractersticas propias del proceso o percibidas como parte del mismo. Dentro de este grupo, hay coincidencias al expresar que el proceso de inspeccin es muy rgido y riguroso [32] [33] [22] y que su complejidad evita que se adopte en pequeas y medianas empresas, donde se hace difcil su implementacin con pocos recursos [22]. A esto se le suma el hecho de que es un proceso no tecnolgico [10] que depende mucho de la experiencia de los inspectores [34]. Adems, el esfuerzo realizado es de difcil conexin con la calidad final del producto [23], lo que ayuda a que se considere como un actividad poco disfrutable [10]. Tambin, como opiniones ms subjetivas, se trata a la inspeccin como un proceso aburrido [35] [26], laborioso [36] [11], pesado [28] y poco creativo [26]. Por otra parte se encuentran aquellos que cuestionan al proceso en s mismo, vindolo como una prdida de tiempo [26], una actividad desconectada del da a da de los desarrolladores [28], que no resuelven problemas reales del equipo [28] llegando a cuestionar la efectividad del proceso [11] [26]. El siguiente factor es el relacionado con aspectos asociados con la formacin de inspectores y capacitacin en general. Como ejemplos relacionados con la formacin, se menciona la falta de entrenamiento [11], la dificultad de realizar inspecciones correctamente [10] y la curva de aprendizaje que implica que a los desarrolladores les lleve algn tiempo entender cmo encontrar defectos efectivamente [28]. Respecto a la capacitacin en general, la falta de conocimiento sobre el uso de inspecciones [18] y la confusin entre los distintos procesos de revisin [8] parecen ser los ms frecuentes. De todas formas esta falta de conocimiento no solo se da a nivel tcnico (de quines lo aplican) sino que tambin se da a nivel gerencial. A este nivel se

10

Daro Macchi, Martin Solari

manifiesta una falta de entendimiento del proceso de inspeccin, cules son sus beneficios y que responsabilidades tiene la gerencia en la adopcin de este tipo de procesos [18]. Respecto al tercer factor de la lista, este trata sobre el costo adicional asociado al proceso de inspeccin. Si bien algunos autores solo mencionan la adicin de costo al proceso de desarrollo [26] [10] [11] otros describen el costo como una gran inversin inicial [8] [23]. El resto de los factores que aparecen con menor frecuencia no dejan de ser importantes y es evidente que algunos se encuentran relacionados. Por ejemplo, sera interesante determinar si existe algn tipo de relacin entre los factores de percepcin del proceso de inspecciones y los factores correspondientes a malas experiencias o experiencias fallidas sin reportar. Por otra parte, tambin sera interesante estudiar cmo afectara la adaptacin de un proceso de inspeccin y el monitoreo de resultados en la percepcin acerca del proceso de desarrolladores y niveles gerenciales. Otro resultado obtenido del estudio de mapeo fue una serie de sugerencias realizadas por parte de distintos autores para solucionar el problema de la adopcin. Dichas soluciones, as como tambin cualquier otra que surja del anlisis de los factores hallados, debern ser estudiadas en mayor profundidad. La principal dificultad de la incorporacin de algunas de estas sugerencias es que se desconoce que implicancias pueden llegar a tener en procesos de desarrollo de software ya establecidos. Por ejemplo, no se sabe el impacto que puede tener la definicin de un rol encargado de velar por la forma en que se realizan las inspecciones (champion) en la actividad cotidiana, dado que se agrega un overhead al trabajo de una persona. No sera una buena solucin la incorporacin de cambios (a causa de los factores encontrados) al proceso tradicional de inspeccin sin un profundo anlisis del impacto de los mismos en la efectividad del proceso. Por ejemplo, quitarle rigurosidad o rigidez al proceso quizs haga que los inspectores se sientan ms a gusto con el mismo pero por otra parte haga que el nmero de defectos encontrados disminuya [37].

Conclusiones

El objetivo de esta investigacin fue obtener un mapa de factores que dificultan la adopcin de inspecciones de software. Esto fue posible gracias al uso de la herramienta estudio de mapeo que permite explorar un tema amplio como el de inspecciones y responder varias preguntas con diferentes niveles de complejidad. La pregunta respecto a los temas o reas que son de inters para la comunidad, fue respondida utilizando el resultado de la bsqueda y el anlisis de ttulos y abstracts. La clasificacin de trabajos permiti conocer que existen subclases como ser las de Factores de efectividad y Procesos que han sido muy activas concentrando el 42% del total de artculos estudiados (correspondientes a los ltimos aos). Esto significa que existen muchas propuestas nuevas de mejoras que deben ser probadas experimentalmente para medir dichas mejoras.

Estudio de Mapeo sobre Adopcin de Inspecciones de Software

11

Por otra parte se encontr evidencia en trabajos previos que confirman que la comunidad cientfica ha planteado inquietudes similares a las que motivan este artculo. De todas maneras se encontr un enfoque distinto en alguno de estos trabajos que mencionan, no solo la adopcin, sino tambin la calidad con la que se lleva a cabo dicho proceso. Respecto a los factores causantes de la baja adopcin, se elabor una lista de los mismos. Por motivos de espacio se decidi generar una lista de factores ms amplios (una abstraccin) de forma de concentrar la informacin surgida del anlisis de los trabajos resultantes del estudio. El resultado indica que el mayor nmero de factores se encuentran relacionados con la percepcin (subjetiva) que tienen los desarrolladores respecto al proceso, la falta de capacitacin y algunas caractersticas propias del proceso como la rigidez, la complejidad y la dificultad de conectar el esfuerzo realizado con la calidad del producto final. Los prximos pasos a seguir deberan ir por dos caminos. Por un lado sera interesante investigar si existe una relacin entre el volumen de trabajo (superior al resto) dentro de la clase Vista tcnica de la taxonoma utilizada para clasificar los hallazgos y las causas de adopcin mencionadas. Por otra parte se espera poder tomar algunos de los factores sugeridos como los causantes del problema planteado y realizar algn tipo de estudio emprico. El objetivo sera comprobar que la baja adopcin de inspecciones de software, en ciertas condiciones y bajo determinados parmetros, es causada por ese subconjunto de factores seleccionados.

7
[1] [2] [3] [4] [5] [6]

Referencias
S. Kollanus and J. Koskinen, Survey of Software Inspection Research, Open Software Engineering Journal, vol. 3, pp. 1534, 2009. G. Tassey, The economic impacts of inadequate infrastructure for software testing, National Institute of Standards and Technology, RTI Project, 2002. W. S. Humphrey, Managing the software process, vol. 88. Addison-Wesley Longman Publishing Co., Inc., 1989. M. Fagan, Design and code inspections to reduce errors in program development, IBM Systems Journal, vol. 15, no. 3, pp. 182-211, 1976. T. Gilb and D. Graham, Software inspection. Addison-Wesley Professional, 1993, p. 496. I. Tervonen, L. Harjumaa, and J. Iisakka, The virtual logging meeting: a web-based solution to resource problems in software inspection, pp. 1-10, 1999. IEEE, IEEE Standard 1028-2008, IEEE Standard for Software Reviews and Audits, 2008. B. Brykczynski, R. Meeson, and D. Wheeler, Software Inspection: Eliminating Software Defects, in In Proceedings of the Sixth Annual Software Technology Conference, 1994. C. Jones, Measuring defect potentials and defect removal efficiency, CrossTalk The Journal of Defense Software Engineering, vol. 21, no. 6. pp. 11-13, 2008.

[7] [8]

[9]

12

Daro Macchi, Martin Solari

[10] [11] [12]

[13]

[14]

[15]

[16] [17]

[18]

[19] [20] [21] [22]

[23] [24] [25] [26]

[27]

R. Radice, High Quality Low Cost Software Inspections. Paradoxicon Publishing Andover, 2002, p. 479. M. Ciolkowski, O. Laitenberger, and S. Biffl, Software reviews: The state of the practice, IEEE software, pp. 4651, 2003. B. Kitchenham, D. Budgen, and O. Pearl Brereton, Using mapping studies as the basis for further research A participant-observer case study, Information and Software Technology, vol. 53, no. 6, pp. 638-651, Jun. 2011. A. Aurum, H. Petersson, and C. Wohlin, State-of-the-art: software inspections after 25 years, Software Testing, Verification and Reliability, vol. 12, no. 3, pp. 133-154, Sep. 2002. O. Laitenberger, A survey of software inspection technologies, in Handbook on Software Engineering and Knowledge Engineering, vol. 2, Citeseer, 2002, pp. 517-556. O. Laitenberger and J.-M. DeBaud, An Encompassing Life-Cycle Centric Survey of Software Inspection, Journal of Systems and Software, vol. 50, no. 1, pp. 5-31, 2000. K. Wiegers, The more things change, Better Software, vol. 8, no. 1, pp. 3034, 2006. J. Iisakka, I. Tervonen, and L. Harjumaa, Experiences of painless improvements in software inspection, Project Control for Software Quality, ESCOM-SCOPE, vol. 99, pp. 321327, 1999. R. Stewart and L. Priven, How to Avoid Software Inspection Failure and Achieve Ongoing Benefits, CrossTalk: The Journal for Defense Software Engineering, pp. 23-27, 2008. E. Weller, Calculating the Economics of Inspections, StickyMinds, 2002. . K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson, Systematic Mapping Studies in Software Engineering, pp. 1-10, 2007. C. J. van Rijsbergen, Information Retrieval, in Information Retrieval, 1979, p. 208. D. Mishra and A. Mishra, Simplified software inspection process in compliance with international standards, Computer Standards & Interfaces, vol. 31, no. 4, pp. 763-771, Jun. 2009. C. Denger and F. Shull, A Practical Approach for Quality-Driven Inspections, IEEE Software, vol. 24, no. 2, pp. 79-86, Mar. 2007. J. Remillard, Source code review systems, IEEE Software, vol. 22, no. 1, 2005. S. Kollanus, Experiences from using ICMM in inspection process assessment, Software Quality Journal, vol. 17, no. 2, pp. 177-187, Jan. 2009. M. Komssi, M. Kauppinen, M. Pyhajarvi, J. Talvio, and T. Mannisto, Persuading Software Development Teams to Document Inspections: Success Factors and Challenges in Practice, 2010 18th IEEE International Requirements Engineering Conference, pp. 283-288, Sep. 2010. D. A. McMeekin, B. R. V. Konsky, E. Chang, and D. J. A. Cooper, Checklist Based Readings Influence on a Developer' s Understanding, in 19th Australian Software Engineering Conference, 2008.

Estudio de Mapeo sobre Adopcin de Inspecciones de Software

13

[28]

[29]

[30]

[31]

[32]

[33] [34]

[35]

[36]

[37]

F. Shull, R. L. Feldmann, C. Seaman, M. Regardie, and S. Godfrey, Fully employing software inspections data, Innovations in Systems and Software Engineering, May 2010. F. Lanubile and T. Mallardo, Inspecting Automated Test Code: A Preliminary Study, Agile Processes in Software Engineering and Extreme Programming, vol. 4536, pp. 115-122, 2007. F. Shull and C. Seaman, Inspecting the History of Inspections: An Example of Evidence-Based Technology Diffusion, IEEE Software, vol. 25, no. 1, pp. 88-90, 2008. F. Shull, J. Carver, G. H. Travassos, J. C. Maldonado, R. Conradi, and V. R. Basili, Replicated studies: building a body of knowledge about software reading techniques, Lecture notes on empirical software engineering, pp. 3984, 2003. S. Nazir, N. Fatima, and S. Malik, Effective Hybrid Review Process (EHRP), 2008 International Conference on Computer Science and Software Engineering, pp. 763-771, 2008. D. Mishra and A. Mishra, Efficient software review process for small and medium enterprises, IET Software, vol. 1, no. 4, pp. 132 -142, 2007. B. Xu, Cost Efficient Software Review in an E-Business Software Development Project, 2010 International Conference on E-Business and EGovernment, pp. 2680-2683, May 2010. V. Suma and T. R. G. Nair, Enhanced Approaches in Defect Detection and Prevention Strategies in Small and Medium Scale Industries, 2008 The Third International Conference on Software Engineering Advances, pp. 389-393, Oct. 2008. . Albayrak and D. Davenport, Impact of Maintainability Defects on Code Inspections, Empirical Software Engineering and Measurement, pp. 9-12, 2010. L. Harjumaa, I. Tervonen, and P. Vuorio, Improving software inspection process with patterns, Fourth International Conference onQuality Software, 2004. QSIC 2004. Proceedings., pp. 118-125, 2005.