Para la toma anterior, vea la Revisión 1 de esta respuesta . Sin embargo, los comentarios y ediciones de la pregunta aclaran aún más lo que busca la pregunta y me permiten ser más claro.
Sí, la ingeniería de software basada en evidencia (EBSE) es una cosa. Parece haber algunos esfuerzos hacia las bases de datos EBSE, como este en la Universidad de Durham y SEED, que fue iniciado por un profesor en Cal Poly . Todos estos esfuerzos, así como los discutidos en una serie de documentos que se pueden encontrar a través del servidor IEEE Xplore o la Biblioteca Digital ACM(se requiere suscripción o compra para muchos artículos en ambos), se basan en medicina basada en evidencia. Proporcionan revisiones de literatura de datos empíricos publicados (observación y experimento). De hecho, la inclusión de "revisión de literatura" en una cadena de búsqueda en cualquier búsqueda de publicación arroja información sobre la mayoría de los temas: más de 14000 visitas en el ACM y más de 1000 en la base de datos IEEE (cuando se limita solo a temas informáticos).
Al observar los tipos generales de temas discutidos en estas bases de datos EBSE y revisiones de literatura, veo un hilo común: tienden a ser independientes de la tecnología. El énfasis parece centrarse principalmente en el proceso y la metodología en lugar de las herramientas específicas utilizadas para llevar a cabo la ingeniería de software.
Entonces, este concepto existe en la ingeniería de software. La academia conoce el concepto basado en evidencia y puede aplicarlo con éxito a la ingeniería de software.
Específicamente, la pregunta aborda la aplicación de técnicas EBSE a la selección de un paradigma parece difícil, debido a la gran cantidad de variables involucradas, lo que obliga a hacer suposiciones y reduce la capacidad de repetir el experimento u observación. Se dice correctamente en la pregunta: "qué paradigma aparece como" la respuesta correcta "puede depender de las métricas a las que presta atención un estudio en particular, en qué condiciones el estudio se mantiene constante o varía, y sin duda también en otros factores" . Aunque eso no significa que estudiar qué paradigma es el "mejor" en una situación dada, hace que cualquier tipo de revisión de la literatura de estos documentos sea increíblemente difícil de completar y aún así extraer información a través de ellos.
Definitivamente, no existe una solución de "girar la manivela" para elegir un paradigma.
Dado un paradigma de programación, puede encontrar estudios en las diversas bases de datos académicas y de la industria sobre cómo ese paradigma influye en varios aspectos del desarrollo de software (calidad, defectos, eficiencia, etc.) en varias condiciones específicas, que van desde el conocimiento y la experiencia del equipo al dominio del problema. Cualquier trabajo riguroso debe identificar claramente las condiciones bajo las cuales se recopilaron los datos y los supuestos. El problema se convierte en tratar de aislar los factores que lo hacen bueno en cada una de esas condiciones.
Académicamente, hay algunas declaraciones que son fáciles de investigar. Por ejemplo, la afirmación de que el paradigma funcional se adapta bien a las aplicaciones que requieren concurrencia se deriva del teorema de Church-Rosser . Debido a esto, es probable que un sistema de software escrito en un lenguaje funcional tenga menos defectos relacionados con la concurrencia que el mismo sistema escrito en un lenguaje de procedimiento u orientado a objetos.
Sin embargo, desde un punto de vista práctico, un equipo de software no siempre puede usar "la mejor" herramienta o técnica para el trabajo solo porque la investigación lo indique. Aunque nos esforzamos por producir sistemas de software de la más alta calidad, operamos dentro de las limitaciones. A menudo, veo estas limitaciones minimizadas (o incluso eliminadas de la ecuación) cuando discuto la efectividad de cualquier metodología.
Como profesional, cuando estoy involucrado en la elección de tecnologías para usar, trato de identificar las mejores herramientas posibles. Pero luego me limito a lo que el equipo que tengo conoce y entiende bien. Volviendo a mi ejemplo anterior, si tengo un equipo bien versado en la creación de aplicaciones simultáneas en C ++ y no tengo experiencia en Haskell, no tiene sentido proponer la construcción del sistema en Haskell, ya que probablemente no pueda hacer restricciones de horario y presupuesto, y mi calidad probablemente sufrirá debido a la falta de experiencia en la cadena de herramientas.
En resumen, la ingeniería de software basada en evidencia es generalmente algo bueno que existe y las revisiones de literatura existen y están fácilmente disponibles. Sin embargo, hay aspectos de la ingeniería de software donde la aplicación de enfoques basados en evidencia ofrece poco valor. La selección de un paradigma de programación para un esfuerzo de desarrollo a gran escala es uno de estos.
Si desea averiguar cómo la orientación a objetos aborda la reutilización o los defectos en la programación funcional, encontrará fácilmente publicaciones sobre ellos. Sin embargo, no encontré (ni confiaría) una publicación que fuera capaz de abordar con eficacia la selección de paradigmas en la amplia gama de proyectos de ingeniería de software del mundo real.