n8a4

Vista previa del material en texto

25 
 
 
 
 
Search Convincing Evidence in Software Engineering Studies 
 
Búsqueda de Evidencia Convincente en los Estudios de Ingeniería de Software 
 
Alan Dunkel1, Alice Gödel2 
Instituto Tecnológico de Massachusetts. adunkel(AT).mit.edu1, agodel(AT)mit.edu2 
 
INFORMACIÓN DEL ARTÍCULO 
 
Tipo 
Reflexión 
 
Historia 
Recibido: 28-01-2015 
Correcciones: 30-04-2015 
Aceptado: 10-05-2015 
 
Keywords 
Computer Science, empirical 
research, software community, 
software projects. 
 
Palabras clave 
Ciencias Computacionales, 
Comunidad de software, 
investigación empírica, proyectos 
software. 
 
 
 
 
 
 
 
 
 
 
ABSTRACT 
What makes elegant, valid, useful and convincing evidence? Find the answer to this question 
has been the work field for decades by various researchers. In the literature there is a number 
of papers on Empirical Software Engineering and discussed in countless discussions, 
workshops, conferences and special issues of journals. This article presents a reflection on 
the evidence; is reviewed progress in Software Engineering and attempts to answer questions 
such as: What is the good that has been done so far? Where will the related research? The 
findings show that: 1) find about convincing evidence is harder than you may think, 2) 
Software Engineering researchers have to work together as a community and share their 
achievements, and 3) it must be acknowledged that convincing evidence is a specific 
component context, because that is convincing for someone may not be for others. 
Consequently, we must be prepared to reinterpret and rescan each time you disclose 
something about. 
 
RESUMEN 
¿Qué es lo que hace elegante, válida, útil y convincente a la evidencia? Buscar la respuesta a 
esta pregunta ha sido el campo de trabajo por décadas de diversos investigadores. En la 
literatura se encuentra un sinnúmero de trabajos acerca de la Ingeniería de Software (SE) 
empírica y se discute en innumerables mesas, talleres, conferencias y números especiales de 
revistas. En este artículo se presenta una reflexión acerca de la evidencia; se revisa los 
avances en Ingeniería de Software y se intenta responder a interrogantes tales como: ¿qué es 
lo bueno que se ha hecho hasta el momento? ¿Hacia dónde va la investigación relacionada? 
Los hallazgos demuestran que: 1) buscar acerca de la evidencia convincente es más difícil de 
lo que piensa, 2) los investigadores en Ingeniería de Software tienen que trabajar más juntos 
como comunidad y compartir sus logros, y 3) hay que reconocer que la evidencia convincente 
tiene un componente específico de contexto, porque la que es convincente para alguien puede 
no serlo para otros. En consecuencia, hay que estar preparado para reinterpretar y volver a 
analizar cada vez que se divulga algo relacionado. 
 
© 2015 IAI. All rights reserved 
 
1. Introducción 
Hace algunas décadas, cuando se indagaba acerca de la 
realidad de la hermosura de la evidencia en SE, era posible 
presentar alguna combinación de los siguientes rasgos: 
 
 Estudios elegantes. Diversos estudios en Ingeniería de 
Software incluyen factores humanos, debido a que la 
eficacia de muchas de las tecnologías subyacentes 
depende en gran medida de quién las utilizan. En este 
sentido y después de estudiar 161 proyectos, Boehm et 
al. [1] encontraron que el mejor personal del proyecto 
es 3.5 veces más productivo que el peor. Pero tratar la 
variabilidad humana es una tarea muy difícil, e 
inclusive, los estudios con diseños sofisticados que 
minimicen estos aspectos de confusión pueden ser una 
fuente de inspiración por otros investigadores. Por 
ejemplo, un estudio realizado por Basili y Selby [2] 
utilizó un diseño factorial fraccional en el que todos los 
desarrolladores utilizan todas las técnicas bajo prueba, 
y cada técnica fue utilizada en cada fragmento del 
programa en experimentación. 
 
 Estadística fuerte. Como la sofisticación matemática 
crece también lo hace el énfasis en resultados 
estadísticamente significativos, por lo que los 
investigadores pueden estar seguros que su teoría tiene 
algún efecto en el mundo real, que quede por fuera del 
ruido de fondo aleatorio. 
 
 Replicabilidad de resultados. Los resultados son mucho 
más convincentes cuando se encuentran una y otra vez 
en muchos contextos diferentes, es decir, no se limitan 
a un contexto o conjunto de condiciones 
experimentales. En otras ciencias la replicación genera 
RACCIS 5(1), pp. 25-31, 2015 
Revista Antioqueña de las 
Ciencias Computacionales y la Ingeniería de Software 
 
ISSN: 2248-7441 
 
www.fundacioniai.org/raccis 
raccis@fundacioniai.org 
 
26 
 
confianza, y por esta razón se ha dedicado mucho 
esfuerzo para realizar experimentos de Ingeniería de 
Software fáciles de ejecutar por otros investigadores en 
otros contextos [3]. Como un ejemplo de replicabilidad, 
Turhan et al. [4] mostraron que las técnicas para 
predecir defectos en el software, aprendidas en un sitio 
determinado, podrían ser aplicadas con éxito en un 
nuevo sitio. 
 
Pero, ¿qué es lo que hace elegante, válida, útil y 
convincente a la evidencia? Buscar la respuesta a esta 
pregunta ha sido por décadas el campo de trabajo de 
diversos investigadores. En la literatura se encuentra un 
sinnúmero de trabajos acerca de la Ingeniería de Software 
empírica y se discute en innumerables mesas, talleres, 
conferencias y números especiales de revistas. En este 
artículo se presenta una reflexión acerca de la evidencia 
convincente; se revisa los avances en Ingeniería de 
Software y se intenta responder a interrogantes tales 
como: ¿qué es lo bueno que se ha hecho hasta el momento? 
¿Hacia dónde va la investigación relacionada? 
 
2. Estado de la evidencia 
Mirando hacia atrás, hoy es posible darse cuenta de lo 
ingenuo que eran las definiciones de evidencia 
convincente que se presentaban. Los rasgos de la 
estadística fuerte y la evidencia replicada es difícil de 
encontrar en esos trabajos, y a menudo no satisfacían los 
objetivos más relevantes de cualquiera de las 
investigaciones. 
 
2.1 Desafíos para los estudios elegantes 
Hoy se encuentra que los estudios elegantes pueden ser 
persuasivos para los que tienen una formación suficiente 
en investigación, pero pueden ser difíciles de explicar a los 
profesionales porque generalmente presentan 
limitaciones y simplificaciones que hacen que en el 
contexto sean menos representativos que en los entornos 
de desarrollo real. Por ejemplo, el estudio de Basili y Selby 
[2] aplica las técnicas estudiadas solamente a problemas 
simples, ninguno con más de 400 líneas de código, y en un 
ambiente artificial. Este estudio se cita a menudo y a pesar 
de que ha sido objeto de muchas repeticiones, no parece 
que ninguno de ellas utilizara aplicaciones 
sustancialmente más representativas o más grandes [5]. 
Aunque este elegante estudio ha hecho una importante 
contribución a la comprensión de las fortalezas y 
debilidades de los diferentes enfoques para la eliminación 
de defectos de código, tal vez no sea ideal para una parte 
sustancial de la forma de pensar sobre este tema, debido a 
que proviene de pequeños segmentos de código. 
 
2.2 Desafíos para la estadística fuerte 
Hay muy poco consenso sobre lo que constituye estadística 
fuerte para los problemas del mundo real. En primer lugar, 
está la cuestión de la validez externa, es decir, si las 
medidas que se están probando reflejan adecuadamente 
los fenómenos del mundo real de interés. Mostrar 
significación estadística no es de ninguna ayuda cuando las 
medidas no tienen sentido. Por ejemplo, Foss et al. [6] 
demuestran que utilizar comúnmente medidas de 
evaluación para la estimación del esfuerzo es 
fundamentalmente un problema. Peor aún, sostienen que 
no existe una única solución, porque es inútil buscar el 
santo grial, es decir, una simple, amable, fácil de usar y 
universal bondad de ajuste del indicador, que se pueda 
aplicar con facilidad para comparar diferentes métodos. 
Por otra parte, diferentesautores aplican diferentes 
análisis estadísticos y ninguno de esos métodos es 
aceptado generalmente como fuerte por una comunidad 
amplia. 
 
 Demsar [7] documenta la enorme gama de métodos 
estadísticos observados en una conferencia 
internacional importante, y se centra en lecciones 
aprendidas a partir de los datos. 
 
 Cohen [8] analiza el uso de las pruebas estándar de 
hipótesis estadística para la toma de conclusiones 
científicas. Mordazmente describe las pruebas como un 
rastrillo intelectual potente, pero estéril, que no deja 
ninguna descendencia científica viable. 
 
En apoyo de la tesis de Cohen se puede ofrecer la lección 
aprendida por Armstrong [9]. Este autor, escribiendo en el 
campo del marketing y utilizando pruebas de significado, 
revisa un estudio y concluye que las estimaciones 
generadas a partir de múltiples fuentes no son mejores que 
las generadas a partir de una sola. Posteriormente, echa 
por tierra esta conclusión haciendo una lista de 31 estudios 
en los que la predicción de múltiples fuentes supera 
consistentemente a la de una sola fuente en promedio de 
12.5%. En todos los estudios analizados por Armstrong 
estas mejoras son exactamente lo contrario de lo que se 
predice a partir de los resultados de las pruebas de 
significado. 
 
Con base en estos descubrimientos, los investigadores de 
hoy están cambiado sus puntos de vista acerca del análisis 
estadístico. En la medida de la posible utilizan 
visualizaciones sucintas para introducir un cierto punto, y 
degradan la estadística de las pruebas de significado al 
papel de una prueba de razonabilidad de las conclusiones 
extraídas de las visualizaciones. Pero todavía las revistas 
rechazan por lo menos dos envíos por mes, porque 
solamente informan significados de valor de los resultados 
sin una representación estadística o visual de la varianza 
en torno a esa media. Se recomienda como mínimo una 
prueba de Mann-Whitney o de Wilcoxon para los 
resultados apareados y no-apareados respectivamente, 
con el objetivo de demostrar que resultados 
aparentemente diferentes en realidad podrían ser 
diferentes. 
 
2.3 Desafíos para la replicabilidad de los resultados 
La replicabilidad ha demostrado ser un objetivo muy difícil 
de alcanzar. En algunos temas existe poca evidencia de que 
los resultados de un proyecto han sido, o pueden ser, 
generalizados a los demás: 
 
 Zimmermann [10] estudió 629 pares de proyectos de 
desarrollo de software, en los que solamente el 4% de 
los casos fueron un modelo de predicción de defectos 
aprendido de un proyecto útil sobre su contraparte. 
27 
 
 Una encuesta realizada por Kitchenham, Mendes y 
Travassos [11] afirman que los datos de un proyecto 
son útiles para la estimación del esfuerzo en un 
segundo. Encontraron que la evidencia existente es no 
concluyente e incluso contradictoria. 
 
En otros temas, se puede encontrar pruebas de que un 
determinado efecto se mantiene a través de una serie de 
diferentes contextos. Por ejemplo, que una técnica madura 
como las inspecciones de software puede encontrar una 
cantidad significativa de defectos existentes en un 
producto software [12]. Sin embargo, si un nuevo estudio 
reporta evidencia de lo contrario, sigue siendo difícil 
determinar si el estudio nuevo (o el viejo) son de alguna 
manera defectuosos, o si el estudio fue hecho para 
funcionar en un entorno único. Dada la amplia variación en 
los contextos en los que el desarrollo de software se 
realiza, a menudo ambas conclusiones son igualmente 
plausibles. 
 
De hecho, parece que a pesar de la atracción intuitiva de 
que los resultados que puedan repetirse, estos estudios no 
son o muy pocos están relacionados con una pregunta de 
Ingeniería de Software específica, o los estudios son 
incompletos. Como ejemplo de la falta de estudios, Menzies 
et al. [13] analizaron 100 métodos de aseguramiento de la 
calidad del software propuestos por diversos grupos 
(IEEE1017 y las normas internas de NASA IV y V), y no 
encontraron experimentos que demuestren que alguno de 
los método es más rentable que cualquiera otro. Algunos 
ejemplos son: 
 
 Zannier, Melnik y Maurer [14] estudiaron un subgrupo 
seleccionado aleatoriamente de un 5% de los trabajos 
que se publican en International Conference on 
Software Engineering (ICSE). Encontraron que de los 
documentos que dicen ser empíricos, muy pocos de 
ellos (2%) comparan métodos de varios investigadores. 
 
 Neto et al. [15] informan de una revisión de la literatura 
acerca del enfoque Model-Based Testing (MBT). 
Encontraron 85 documentos que describían 71 
enfoques MBT distintos y una muy pequeña minoría 
con cualquier componente experimental, lo que indica 
una tendencia general de los investigadores a continuar 
innovando y presentando informes sobre nuevos 
enfoques, en lugar de la comprensión de las ventajas 
prácticas comparables de los ya existentes. 
 
Para comprobar si estos trabajos son aislados o forman 
parte de un patrón más general, se revisaron todas las 
presentaciones hechas desde 2005 en International 
Conference on Predictive Models in Software Engineering 
(PROMISE), sobre experimentos repetibles de Ingeniería 
de Software: 
 
 Se han realizado 68 presentaciones de las que 48 
prueban un nuevo análisis de datos antiguos o de 
informes realizados al estilo de Zannier, Melnik y 
Maurer [14], es decir, que un nuevo método funcionó 
para un proyecto en particular. 
 
 Nueve documentos plantearon preguntas acerca de la 
validez de los resultados anteriores. Por ejemplo, 
Menzies [16]. 
 
 Cuatro argumentaron que la generalidad de los 
modelos de Ingeniería de Software era poco probable o 
imposible. Por ejemplo Briand [17]. 
 
 Solamente, en raras ocasiones (7 de 68 
presentaciones), los investigadores informan sobre 
generalizaciones de un proyecto a otros proyectos: 
 
 Cuatro documentos reportaron que un predictor de 
calidad del software aprendido en un proyecto se 
aplicó de manera útil a uno nuevo [18, 19]. 
 
 Tres documentos presentan un caso parcial de que 
tal generalidad es posible [20]. 
 
Debido a lo desconcertante de estos hallazgos, se 
realizaron conversaciones con los principales 
investigadores en Ingeniería de Software empírica en los 
Estados Unidos y Europa. El resumen es el siguiente: 
 
 Vic Basili [3], pionero en la Ingeniería de Software 
empírica por más de 30 años, después de afirmar que la 
Ingeniería de Software empírica es más saludable 
ahora que en la década de 1980, reconoció que: 1) hasta 
el momento los resultados son incompletos, y 2) que 
hay pocos ejemplos de métodos demostrados que sean 
útiles en múltiples proyectos. 
 
 David Budgen, al igual que Barbara Kitchenham, es un 
defensor líder en Europa de la Ingeniería de Software 
basada en la evidencia (EBSE). En este enfoque las 
prácticas de los ingenieros deben basarse en métodos 
suficientemente fundados en la literatura. Ellos se 
preguntan si el enfoque es lo suficientemente maduro 
para la práctica y la política, y su respuesta es que 
todavía no. Porque la Ingeniería de Software necesita 
reestructurarse significativamente antes que se pueda 
demostrar que los resultados pueden ser replicados en 
diferentes proyectos [21]. Además, abogan por 
diferentes estándares para informar en esta ingeniería, 
concretamente del uso de resúmenes estructurados 
para simplificar el análisis a gran escala de la literatura. 
 
3. El cambio es posible 
Hasta el momento no se puede afirmar con certeza que la 
evidencia reportada sea estadísticamente sólida y 
replicable, y donde se han encontrado pruebas en cada una 
de estas categorías no siempre ha tenido el impacto que se 
espera. Tal vez haya que revisar la definición de evidencia 
convincente. Dada la retroalimentación anterior, ¿existirá 
una definición más práctica que pueda motivar a los 
investigadores? 
 
Una propuesta es definirla como algo que motiva al 
cambio. Algunos investigadores están convencidos que 
comenzaron su búsqueda de la evidenciaconvincente 
cuando vieron de primera mano en el mundo real los 
problemas y dificultades en el desarrollo de software. El 
28 
 
santo grial para ellos tiende a ser los resultados de la 
investigación que pueden crear mejoras en el mundo real. 
Para motivar el cambio, algunos de mayor influencia en la 
audiencia tienen que confiar en la evidencia. Una manera 
de hacerle frente a la falta de rigor en los informes de 
experiencias o estudios de casos podría ser asignar un 
índice de confianza a cada pieza de evidencia. La 
calificación podría reflejar en cada reporte de ajuste un 
espectro que vaya desde la evidencia anecdótica o 
problemática a la muy confiable. Estas evaluaciones son 
una parte esencial del proceso propuesto por Kitchenham 
[22] para las revisiones sistemáticas y los estudios de 
Ingeniería de Software. Una escala simple destinada a 
ayudar a comunicar los niveles de confianza se puede 
encontrar en el trabajo de Feldmann, Shull y Shaw [23]. 
 
Generar cuerpos de evidencia verdaderamente 
convincentes podría requerir un cambio en la forma en que 
se difunden resultados. Es muy posible que las 
publicaciones científicas no sean la única tecnología 
necesaria para transmitirlos. Entre otros problemas, estas 
publicaciones no suelen publicar los datos en bruto 
disponibles para que otros investigadores los vuelvan a 
analizar, reinterpretar y verificar. Además, aunque los 
autores de este tipo de publicaciones tratan de ser muy 
exhaustivos en la descripción del contexto, es casi 
imposible enumerar todos los posibles factores que 
podrían ser relevantes. 
 
Otra cuestión que puede ayudar es crear repositorios de 
datos de Ingeniería de Software, que contengan los 
resultados entre de diferentes entornos de investigación, o 
por lo menos a través de proyectos, y de los análisis que 
puede llevarse a cabo. Para esto ya se han propuesto 
algunos: 
 
 Software-artifact Infrastructure Research, de la 
Universidad de Nebraska. Este repositorio almacena 
artefactos relacionados con el software, que los 
investigadores pueden utilizar en la experimentación 
rigurosa controlada con las técnicas de análisis de 
programas y de pruebas de software, y que los 
educadores pueden utilizar para formar a los 
estudiantes en la experimentación controlada. El 
repositorio contiene muchos sistemas software Java y 
C, en múltiples versiones, junto con artefactos de apoyo, 
tales como bancos de pruebas, datos de fallas y scripts. 
Los artefactos en este repositorio se han utilizado en 
cientos de publicaciones. 
 
 CeBASE. Fue un esfuerzo para crear repositorios de 
datos y lecciones aprendidas que podrían ser 
compartidos y volver a analizar por otros 
investigadores. Aquí se aprovechan las experiencias de 
NASA para explorar formas de contextualizar los datos 
con menos gastos generales, tales como el etiquetado 
de todos los conjuntos de datos con un rico conjunto de 
metadatos, que describen desde donde se ha extraído la 
información. Estas experiencias proporcionan a su vez 
las bases para un repositorio de las lecciones 
aprendidas, que mantiene la Universidad del 
Departamento de Defensa de los Estados Unidos y que 
le permite a los usuarios finales especificar su propio 
contexto en función de variables como el tamaño del 
proyecto, la criticidad, o dominio, y encontrar prácticas 
con la evidencia para ambientes similares. 
 
 NASA Software Engineering Laboratory. El impacto de 
este laboratorio fue un gran éxito y sus datos y los 
resultados siguen siendo citados. Una lección 
importante concierne a su contexto: los líderes del 
laboratorio requerían investigadores que utilizaran los 
datos para sus proyectos, y de esta manera entendieran 
correctamente el contexto y no malinterpretaran los 
resultados de sus análisis. 
 
 PROMISE. Otro repositorio de la Ingeniería de Software 
activo que busca experimentos de Ingeniería de 
Software repetibles. El proyecto consta de tres partes: 
1) un repositorio en línea de datos de dominio público, 
relacionados con la predicción de defectos y de 
esfuerzo, la Ingeniería de Software basada en modelos, 
la minería de texto y otros temas; 2) una conferencia 
anual, donde se anima fuertemente a los autores no 
solamente a publicar documentos sino también a 
contribuir al repositorio con los datos que utilizan para 
hacer sus conclusiones; y 3) números especiales de 
revistas para publicar los mejores trabajos de la 
conferencia [16]. 
 
Los repositorios son especialmente útiles cuando 
proporcionan un enlace a quienes contribuyen con los 
datos. Esto se debe a que los datos rara vez están solos, por 
lo que los autores deben esperar como norma y no una 
anomalía a responder preguntas y participar en un diálogo 
con los que tratan de interpretar su trabajo. Estos 
contactos son muy importantes para aprender el contexto 
del que se ha extraído la información, y posiblemente 
ayudarles a los usuarios a extraer los datos que sean más 
relevantes para su pregunta o su propio contexto. 
 
4. El efecto del contexto 
Aunque son un elemento necesario para la solución que se 
busca, los repositorios solamente son una parte de ella que 
puede ser motivadora y convincente. Ya se ha mencionado 
que la obtención de evidencias depende un poco del 
contexto específico, pero también hay que tener en cuenta 
su interpretación en ese contexto específico e incluso la 
audiencia. Para apreciarlo es necesario discutir un poco de 
teoría. Muchos de los problemas de la Ingeniería de 
Software viven en un espacio de soluciones que se retuerce 
y se vuelve como una manta tirada en el piso. Imagine una 
hormiga navegando por las colinas y valles de esta manta, 
buscando el punto más bajo donde sea mínimo, por 
ejemplo, el esfuerzo de desarrollo de software y el número 
de defectos. Si el problema es lo suficientemente complejo, 
como de hecho lo son el diseño y las decisiones del proceso 
del software, no existe una mejor manera de encontrar una 
mejor solución. Más bien, la hormiga podría atascarse en el 
valle equivocado, pensando que es el más bajo, cuando en 
realidad no lo es. Los algoritmos de optimización y la 
Inteligencia Artificial utilizan diversas heurísticas para 
explorar este espacio de opciones. Una heurística consiste 
en modelar el contexto del problema, de acuerdo con los 
29 
 
objetivos de un público en particular, y luego orientar la 
búsqueda en una dirección particular. Imagine que la 
hormiga es una correa y la correa está siendo tirada 
suavemente por el objetivo de la heurística. 
 
Ahora bien, estas heurísticas de búsqueda, aunque útiles, 
imponen un sesgo en los resultados. Si cambia el contexto 
y cambia el sesgo heurístico, estos algoritmos encontrarán 
diferentes mejores soluciones. Por ejemplo, en 
experimentos con AI buscando modelos de procesos de 
software, Green et al. [24] usaron dos funciones-objetivo 
diferentes. Uno de ellos representa un proyecto 
gubernamental de seguridad crítica, donde trataron de 
reducir tanto el esfuerzo de desarrollo como el número de 
defectos en el software entregado. Otro representa una 
situación de negocios más estándar donde se busca liberar 
el software al mercado, tratando todo el tiempo de no 
inyectar demasiados defectos. Ese estudio examinó cuatro 
proyectos diferentes utilizando un optimizador de AI. Cada 
búsqueda se repitió para cada objetivo. Una característica 
notable de los resultados fue que las recomendaciones 
generadas utilizando un objetivo fueron generalmente 
rechazadas por el otro: una búsqueda recomienda 
aumentar el tiempo hasta la entrega, mientras que la otra 
recomienda disminuirlo. 
 
Estos resultados tienen importantes implicaciones para 
cualquier investigador, que trata de encontrar pruebas que 
convenzan a una audiencia para cambiar el proceso o las 
herramientas utilizadas para desarrollar software. En vez 
de asumir que todas las evidencias convencerán a todos los 
públicos, hay que sintonizar la evidencia con la audiencia. 
No es suficiente estar en el escenarioy sacar de un 
sombrero evidencias aparentemente impresionantes. 
Incluso si fueran estadísticamente fuertes, poder repetir 
evidencias desde estudios elegantes no debería pedir 
ningún cambio cuando trata acerca de los problemas que 
son irrelevantes para el público. Es decir, hay que respetar 
el sesgo del negocio de la audiencia, porque puede 
preguntarse para qué sirve todo lo que se publica. 
 
5. Conclusiones 
A pesar de las décadas dedicadas a la investigación en 
Ingeniería de Software, hasta ahora se han visto 
relativamente pocos ejemplos de evidencias convincentes, 
que hayan realmente dado lugar a cambios en cómo las 
personas ejecutan proyectos de software. Es posible creer 
que esto se debe al problema de contexto: los 
investigadores han estado generando evidencias sobre A, 
mientras que el público se preocupa por B, C, D, y así 
sucesivamente. La recomendación es un poco más de 
humildad entre los investigadores que exploran las 
evidencias en la Ingeniería de Software, al menos como 
están las cosas ahora, y de voluntad para mezclarse con y 
escuchar a la industria del software, porque puede ayudar 
a una mejor comprensión de lo que en realidad son B, C y 
D. De este campo puede tener que retirarse, al menos por 
un tiempo, el objetivo de buscar evidencias sobre los 
resultados que tienen los proyectos para todos los casos; y 
en este caso, puede ser un reto buscar resultados locales 
antes que globales. 
Endres y Rombach [25] proponen una visión de cómo se 
construye el conocimiento sobre el software y los sistemas 
de ingeniería: 
 
 Observar todo el tiempo lo que realmente puede 
ocurrir durante el desarrollo en un contexto específico. 
En este caso en esa observación se deben incluir tanto 
datos duros como impresiones subjetivas. 
 
 Observaciones recurrentes que conducen a leyes que 
ayudan a entender cómo es probable que las cosas 
ocurran en el futuro. 
 
 Las leyes se explican por las teorías que revelan por qué 
suceden los acontecimientos. 
 
Dada la complejidad de las cuestiones que se abordan 
actualmente en la investigación empírica, es posible que se 
deba frenar un poco la creación de teoría. Porque se 
requiere un modelo más productivo de la construcción de 
conocimiento a partir de todos los datos y estudios que hay 
actualmente, a través de los niveles de observación y las 
leyes y con el apoyo de los repositorios que se describieron 
anteriormente. Para el primer nivel, un investigador 
podría modelar los objetivos de la audiencia local y luego 
reunir pruebas centrado en ellos. La disponibilidad de 
modernas herramientas de minería de datos puede ayudar 
a los ingenieros a aprender esas lecciones locales. En el 
segundo nivel, donde se presentan conclusiones abstractas 
a través de proyectos y/o contextos, se podrían abstraer 
los factores importantes o principios básicos en un área, en 
vez de proporcionar la solución que funcionará a través de 
algún subconjunto de contextos. 
 
Por ejemplo, Hall et al. [26], tratando de responder a la 
pregunta de lo que motiva a los desarrolladores de 
software, analizaron 92 estudios que habían examinado 
esta cuestión, cada uno en un contexto diferente. Luego de 
tratar de luchar con todos los estudios y sus diversos 
resultados, los investigadores tomaron el enfoque de 
buscar los factores que parecen motivar a los 
desarrolladores, a pesar de que no fue posible cuantificar 
cómo contribuyen. Por lo tanto, los factores que se han 
encontrado en múltiples estudios y que contribuyen a la 
motivación podrían incluirse con cierta confianza en este 
modelo. El resultado final fue un modelo no-predictivo de 
que un factor X fuera tan importante como un factor Y. Más 
bien, se trató de una lista de control de los factores 
importantes que los administradores podrían utilizar en su 
propio contexto para asegurarse de que no habían 
descuidado u olvidado algo. Tal vez lo mejor que se puede 
hacer en muchas cuestiones es armar a los desarrolladores 
con los factores que deben tener en cuenta en la búsqueda 
de sus propias soluciones. 
 
Para ello es necesario ampliar la definición de evidencias 
para que sea aceptable para el primer nivel de observación. 
Algunos investigadores han sostenido durante mucho 
tiempo que la investigación en Ingeniería de Software 
muestra un sesgo hacia los datos y el análisis cuantitativos, 
pero que el trabajo cualitativo puede ser riguroso y 
proporcionar respuestas útiles a las preguntas pertinentes 
30 
 
[27]. Un comienzo hacia la construcción de colecciones de 
evidencia robustas sería ampliar realmente la definición 
de evidencias para incorporar tanto fuentes cualitativas 
como cuantitativas, que sea más textual, o tratar datos 
gráficos sobre qué hacen o no hacen las tecnologías 
además de datos cuantitativos que midan los efectos que 
tienen. 
 
Sin embargo, los cuerpos verdaderamente convincentes de 
evidencias deberían ir más allá y aceptar diferentes tipos 
en su totalidad, no solamente estudios de investigación 
que tratan de encontrar estadística significante, sino 
también informar de la experiencia de investigadores que 
puedan proporcionar más información sobre la aplicación 
práctica de las tecnologías. Estas experiencias están 
actualmente subestimadas porque sufren de ser menos 
rigurosas que gran parte de la literatura existente. Por 
ejemplo, no siempre es posible confiar en que los aspectos 
de interés se han medido con precisión, que se han 
excluido los factores de confusión, o que se han evitado las 
cuestiones de procesos de conformidad. Sin embargo, 
estos informes deben ser parte explícita del camino de las 
evidencias de cualquier tecnología de desarrollo de 
software. Aquí es donde cobra importancia la sugerencia 
de definir observaciones de manera suficientemente 
amplia para incluir las impresiones subjetivas; incluso, 
formas de entrada menos rigurosas pueden ayudar a llegar 
a conclusiones, si son válidas, como para que no creer en 
leyes con un sentido injustificado de confianza. La 
aplicación de un índice de fiabilidad de estas fuentes de 
evidencias es importante para que esas cuestiones 
metodológicas se puedan destacar. Por supuesto, es poco 
probable que sean completamente libres de cuestiones 
metodológicas, incluso los estudios de investigación más 
rigurosos. 
 
Los reportes de experiencias pueden mantener la 
investigación aterrizada, mediante la demostración de que 
lo que se consigue con las limitaciones prácticas no 
siempre coincidirá con las expectativas para una 
tecnología determinada. Igual de importante, proporciona 
una visión sobre cómo deben adaptarse las tecnologías 
para satisfacer las limitaciones prácticas de desarrollo de 
software en el día a día. En el ámbito de la transferencia de 
tecnología a menudo se encuentra que un estudio de caso 
único bueno narra experiencias positivas con una 
tecnología en la práctica, que puede ser más valioso para 
los profesionales que una multitud de informes de 
investigación adicionales. Tales cuerpos convincentes de 
evidencias también pueden ayudar a impulsar el cambio, al 
proporcionar evidencias de que pueden llegar a diferentes 
tipos de usuarios. Rogers [28] propuso un modelo citado 
frecuentemente y que caracteriza a los consumidores de 
alguna innovación a lo largo de una curva de campana: la 
cola del extremo izquierdo comprende los innovadores, el 
centro representa a la mayoría que adopta algún lugar de 
la curva media, y la cola más a la derecha contiene los 
rezagados que se resisten al cambio. Los investigadores 
que conocen su audiencia pueden seleccionar 
subconjuntos de datos apropiados de un conjunto 
verdaderamente robusto con el fin de presentar su caso: 
 Los primeros pueden encontrar un pequeño conjunto 
de estudios relativamente bajo de viabilidad 
convincente, o uno o dos estudios elegantes de 
investigación, suficientes para que adopten un cambio 
por sí mismos. Sobre todo si el contexto de esos 
estudios demuestra que la evidencia se reunió en un 
ambienteun poco como el suyo. 
 
 La mayoría puede tener que ver una mezcla de los 
estudios de diferentes contextos, para convencerse de 
que una idea de investigación tiene mérito, ha 
demostrado ser viable en algo más que un entorno 
determinado y ha comenzado a convertirse en parte de 
la forma aceptada de hacer las cosas. 
 
 Los rezagados pueden requerir pruebas abrumadoras, 
que comprendan más de un puñado de estudios de alta 
confianza y una amplia gama de contextos en los que se 
han obtenido resultados beneficiosos. 
 
Se han propuesto diferentes formas para combinar 
evidencias [29], pero lo que más importa es la interacción 
de tener tanto informes cualitativos como datos 
cuantitativos. Muchas veces los desarrolladores responden 
mejor a los conjuntos de datos que tienen mezclas de 
diferentes tipos. Por ejemplo, tener un rico conjunto de 
datos duros y experiencias positivas de equipos reales 
ayuda a las tecnologías de inspección de software a 
difundirse a través de múltiples centros [30]. La evidencia 
de estudios empíricos bien diseñados puede ayudar a que 
un hallazgo alcance significación estadística, pero todavía 
puede ser poco práctico para implementar o demasiado 
lento en la entrega de respuestas oportunas 
(especialmente en un área de rápido cambio tecnológico 
como la Ingeniería de Software). La evidencia de aplicación 
en la práctica puede ser más convincente que los 
beneficios, pero suele ser menos rigurosa. A menudo, lo 
que realmente es convincente es una combinación de 
pruebas de ambas fuentes, donde una corrobora a la otra. 
 
Referencias 
 
[1] Boehm, B. et al. (2000). Software cost estimation with 
COCOMO II. New York: Prentice Hall PTR. 
[2] Basili, V. & Selby, R. (1987). Comparing the effectiveness of 
software testing strategies. IEEE Transactions on Software 
Engineering 13(12), pp. 1278-1296. 
[3] Basili, V. 2009. Personal communication. September. 
[4] Turhan, B. et al. (2009). On the relative value of cross-
company and within-company data for defect prediction. 
Empirical Software Engineering 14(5), pp. 540-557. 
[5] Runeson, P. et al. (2006). What do we know about defect 
detection methods? IEEE Software 23(3), pp. 82-90. 
[6] Foss, T. et al. (2003). A simulation study of the model 
evaluation criterion MMRE. IEEE Transactions on Software 
Engineering 29(11), pp. 985-995. 
[7] Demsar, J. (2006). Statistical comparisons of classifiers over 
multiple data sets. Journal of Machine Learning Research 7, 
pp. 1-30. 
[8] Cohen, J. (1988). The earth is round (p < .05). American 
Psychologist 49, pp. 997-1003. 
[9] Armstrong, J. (2007). Significance tests harm progress in 
forecasting. International Journal of Forecasting 23(2), pp. 
321-327. 
http://www.amazon.es/Software-Cost-Estimation-Cocomo-Paperback/dp/0137025769
http://www.amazon.es/Software-Cost-Estimation-Cocomo-Paperback/dp/0137025769
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1702179&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1702179
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1702179&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1702179
https://www.safaribooksonline.com/library/view/making-software/9780596808310/ch01s06.html
http://dl.acm.org/citation.cfm?id=1612782
http://dl.acm.org/citation.cfm?id=1612782
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1628944&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1628944
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1628944&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1628944
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1245300&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1245300
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1245300&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1245300
http://dl.acm.org/citation.cfm?id=1248548
http://dl.acm.org/citation.cfm?id=1248548
http://ist-socrates.berkeley.edu/~maccoun/PP279_Cohen1.pdf
http://repository.upenn.edu/cgi/viewcontent.cgi?article=1104&context=marketing_papers
http://repository.upenn.edu/cgi/viewcontent.cgi?article=1104&context=marketing_papers
31 
 
[10] Zimmermann, T. et al (2009). Cross-project defect 
prediction. Proceedings of the 7th joint meeting of the 
European Software Engineering Conference and the ACM 
SIGSOFT Symposium on the Foundations of Software 
Engineering (pp. 91-100). August 24-28. Amsterdam, The 
Netherlands. 
[11] Kitchenham, B., Mendes, E & Travassos, G. (2007). Cross 
versus within-company cost estimation studies: A 
systematic review. IEEE Transactions of Software 
Engineering 33(5), pp. 316-329. 
[12] Shull, F. et al (2002). What we have learned about fighting 
defects. Proceedings IEEE International Symposium on 
Software Metrics (pp. 249-258). June 4-7. Ottawa, Canada. 
[13] Menzies, T. et al (2008). Learning better IV & V practices. 
Innovations in Systems and Software Engineering 4(2), pp. 
169-183. 
[14] Zannier, C., Melnik, G. & Maurer, F. (2006). On the success of 
empirical studies in the International Conference on 
Software Engineering. Proceedings of the 28th 
international conference on software engineering (341–
350). May 20-28. Shanghai, China. 
[15] Neto, A. et al. (2008). Improving evidence about software 
technologies: A look at model-based testing. IEEE Software 
25(3), pp. 10-13. 
[16] Menzies, T. (2008). Editorial, special issue, repeatable 
experiments in Software Engineering. Empirical Software 
Engineering 13(5), pp. 469-471. 
[17] Briand, L. (2006). Predictive models in Software 
Engineering: State-of-the-art, needs, and changes. Keynote 
address, PROMISE workshop. September 24. Ottawa, 
Canada. 
[18] Weyuker, E., Ostrand, T. & Bell, R. (2008). Do too many 
cooks spoil the broth? Using the number of developers to 
enhance defect prediction models. Empirical Software 
Engineering 13(5), pp. 539–559. 
[19] Tosun, A., Bener, A. & Turhan, B. (2009). Practical 
considerations of deploying AI in defect prediction: A case 
study within the Turkish telecommunication industry. 
Paper presented at the International Conference on 
Predictor Models in Software Engineering. May 18–19. 
Vancouver, Canada. 
[20] Boehm, B. (2009). Future challenges for software data 
collection and analysis. Proceedings International 
Conference on Predictor Models in Software Engineering 
(Article 1). May 18-19. Vancouver. Canada. 
[21] Budgen, D., Kitchenham, B. & Brereton, P. (2009). Is 
evidence based software engineering mature enough for 
practice & policy? Proceedings 33rd Annual IEEE Software 
Engineering Workshop. October 13-14. Skövde, Sweden. 
[22] Kitchenham, B. (2004). Procedures for undertaking 
systematic reviews. Technical Report TR/SE-0401, 
Department of Computer Science, Keele University, and 
National ICT, Australia Ltd. 
[23] Feldmann, R., Shull, F. & Shaw, M. (2006). Building decision 
support in an imperfect world. Proceedings ACM/IEEE 
International Symposium on Empirical Software 
Engineering (pp. 33-35). September 21-22. Rio de Janeiro, 
Brazil. 
[24] Green, P. et al. (2009). Understanding the value of Software 
Engineering technologies. Proceedings of the 2009 
IEEE/ACM International Conference on Automated 
Software Engineering (pp. 52-61). November 16-20. 
Auckland, New Zeland. 
[25] Endres, A. & Rombach, H. (2003). A handbook of Software 
and Systems Engineering: Empirical Observations, Laws 
and Theories. Boston: Addison-Wesley. 
[26] Hall, T. et al. (2008). What do we know about developer 
motivation? IEEE Software 25(4), pp. 92-94. 
[27] Seaman, C. (1999). Qualitative methods in empirical studies 
of software engineering. IEEE Transactions on Software 
Engineering 25(4), pp. 557-572. 
[28] Rogers, E. (1962). Diffusion of innovations. New York: Free 
Press. 
[29] Shull, F., Carver, J. & Travassos, G. (2001). An empirical 
methodology for introducing software processes. ACM 
SIGSOFT Software Engineering Notes 26(5),pp. 288-296. 
[30] Shull, F. & Seaman, C. (2008). Inspecting the history of 
inspections: An example of evidence-based technology 
diffusion. IEEE Software 24(7), pp. 88-90.
 
 
http://dl.acm.org/citation.cfm?id=1595713
http://dl.acm.org/citation.cfm?id=1595713
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4160970&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4160970
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4160970&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4160970
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4160970&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4160970
http://dl.acm.org/citation.cfm?id=824031
http://dl.acm.org/citation.cfm?id=824031
http://link.springer.com/article/10.1007%2Fs11334-008-0046-3
http://dl.acm.org/citation.cfm?id=1134333&dl=ACM&coll=DL&CFID=522309802&CFTOKEN=53810296
http://dl.acm.org/citation.cfm?id=1134333&dl=ACM&coll=DL&CFID=522309802&CFTOKEN=53810296
http://dl.acm.org/citation.cfm?id=1134333&dl=ACM&coll=DL&CFID=522309802&CFTOKEN=53810296
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4497754&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4497754
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4497754&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4497754
http://link.springer.com/article/10.1007/s10664-008-9087-3
http://link.springer.com/article/10.1007/s10664-008-9087-3
http://squall.sce.carleton.ca/people/briand/pubs/ICSM06-keynote.pdf
http://squall.sce.carleton.ca/people/briand/pubs/ICSM06-keynote.pdf
http://link.springer.com/article/10.1007%2Fs10664-008-9082-8
http://link.springer.com/article/10.1007%2Fs10664-008-9082-8
http://link.springer.com/article/10.1007%2Fs10664-008-9082-8
http://dl.acm.org/citation.cfm?id=1540453
http://dl.acm.org/citation.cfm?id=1540453
http://dl.acm.org/citation.cfm?id=1540453
http://dl.acm.org/citation.cfm?id=1540440
http://dl.acm.org/citation.cfm?id=1540440
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=5619232
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=5619232
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=5619232
http://people.ucalgary.ca/~medlibr/kitchenham_2004.pdf
http://people.ucalgary.ca/~medlibr/kitchenham_2004.pdf
http://www.cos.ufrj.br/~ght/files/prelim_isese_2006.pdf
http://www.cos.ufrj.br/~ght/files/prelim_isese_2006.pdf
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5431782
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5431782
http://www.amazon.com/Handbook-Software-Systems-Engineering-Observations/dp/0321154207
http://www.amazon.com/Handbook-Software-Systems-Engineering-Observations/dp/0321154207
http://www.amazon.com/Handbook-Software-Systems-Engineering-Observations/dp/0321154207
https://www.computer.org/csdl/mags/so/2008/04/mso2008040092.pdf
https://www.computer.org/csdl/mags/so/2008/04/mso2008040092.pdf
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=799955&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F32%2F17384%2F00799955.pdf%3Farnumber%3D799955
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=799955&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F32%2F17384%2F00799955.pdf%3Farnumber%3D799955
http://books.simonandschuster.com/Diffusion-of-Innovations-5th-Edition/Everett-M-Rogers/9780743222099
http://dl.acm.org/citation.cfm?id=503248
http://dl.acm.org/citation.cfm?id=503248
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4420076&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F52%2F4420053%2F04420076.pdf%3Farnumber%3D4420076
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4420076&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F52%2F4420053%2F04420076.pdf%3Farnumber%3D4420076
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4420076&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F52%2F4420053%2F04420076.pdf%3Farnumber%3D4420076