Pour la prise précédente, voir la révision 1 de cette réponse . Cependant, les commentaires et les modifications à la question clarifient davantage ce que la question cherche et me permettent d'être plus clair.
Oui, l'ingénierie logicielle basée sur des preuves (EBSE) est une chose. Il semble y avoir quelques efforts vers les bases de données EBSE, comme celle-ci à l'Université de Durham et SEED, qui a été lancée par un professeur à Cal Poly . Tous ces efforts, ainsi que ceux discutés dans un certain nombre d'articles qui peuvent être trouvés via le serveur IEEE Xplore ou la bibliothèque numérique ACM(abonnement ou achat requis pour de nombreux articles dans les deux), sont basés sur la médecine factuelle. Ils fournissent une revue de la littérature des données empiriques publiées (observation et expérience). En fait, l'inclusion de la «revue de la littérature» dans une chaîne de recherche sur n'importe quelle recherche de publication donne des informations sur la plupart des sujets - plus de 14 000 visites sur l'ACM et plus de 1 000 sur la base de données IEEE (lorsqu'elle est limitée aux seuls sujets informatiques).
En regardant les types généraux de sujets abordés dans ces bases de données EBSE et revues de littérature, je vois un fil conducteur - ils ont tendance à être indépendants de la technologie. L'accent semble être principalement centré sur les processus et la méthodologie plutôt que sur les outils spécifiques utilisés pour effectuer le génie logiciel.
Donc, ce concept existe en génie logiciel. Le milieu universitaire connaît le concept fondé sur des preuves et peut l'appliquer avec succès au génie logiciel.
Plus précisément, la question porte sur l'application des techniques EBSE à la sélection d'un paradigme semble difficile, en raison du grand nombre de variables impliquées, obligeant à faire des hypothèses ainsi qu'à réduire la capacité de répéter l'expérience ou l'observation. Il est dit juste dans la question - "quel paradigme apparaît comme" la bonne réponse "peut dépendre des paramètres auxquels une étude particulière prête attention, des conditions dans lesquelles l'étude reste constante ou varie, et sans doute également d'autres facteurs" . Bien que cela ne signifie pas qu'étudier quel paradigme est le "meilleur" dans une situation donnée, cela rend toute sorte de revue de la littérature de ces documents incroyablement difficile à compléter et à extraire des informations à travers eux.
Il n'y a certainement pas de solution "tourner la manivelle" pour choisir un paradigme.
Étant donné un paradigme de programmation, vous pouvez trouver des études dans les différentes bases de données universitaires et industrielles sur la façon dont ce paradigme influence divers aspects du développement de logiciels - qualité, défauts, efficacité, etc. - dans diverses conditions spécifiques, allant de la connaissance et de l'expérience du équipe au domaine du problème. Tout document rigoureux doit clairement identifier les conditions dans lesquelles les données ont été collectées et les hypothèses. Le problème devient d'essayer d'isoler les facteurs qui le rendent bon dans chacune de ces conditions.
D'un point de vue académique, certaines déclarations sont faciles à rechercher. Par exemple, l'affirmation selon laquelle le paradigme fonctionnel est bien adapté aux applications qui nécessitent une concurrence provient du théorème de Church-Rosser . Pour cette raison, il est probable qu'un système logiciel écrit dans un langage fonctionnel aura moins de défauts liés à la concurrence que le même système écrit dans un langage procédural ou orienté objet.
Cependant, d'un point de vue pratique, une équipe logicielle ne peut pas toujours utiliser "le meilleur" outil ou technique pour le travail simplement parce que la recherche l'indique. Bien que nous nous efforçons de produire des systèmes logiciels de la plus haute qualité, nous opérons dans les limites des contraintes. Souvent, je vois ces contraintes minimisées (ou même supprimées de l'équation) lorsque je discute de l'efficacité de toute méthodologie.
En tant que praticien, lorsque je suis impliqué dans le choix des technologies à utiliser, j'essaie d'identifier les meilleurs outils possibles. Mais ensuite je me contrains à ce qui est connu et bien compris par l'équipe que j'ai. Pour revenir à mon exemple précédent, si j'ai une équipe qui connaît bien la construction d'applications simultanées en C ++ et aucune expérience en Haskell, cela n'a pas de sens de proposer de construire le système dans Haskell car je ne serai probablement pas en mesure de faire calendrier et contraintes budgétaires, et ma qualité souffrira probablement en raison d'un manque d'expérience dans la chaîne d'outils.
Pour récapituler, le génie logiciel fondé sur des données probantes est généralement une bonne chose qui existe et des analyses documentaires existent et sont facilement disponibles. Cependant, il existe des aspects de l'ingénierie logicielle où l'application d'approches fondées sur des preuves offre peu de valeur. La sélection d'un paradigme de programmation pour un effort de développement à grande échelle en fait partie.
Si vous souhaitez savoir comment l'orientation objet résout la réutilisation ou les défauts de programmation fonctionnelle, vous trouverez facilement des publications à ce sujet. Cependant, je n'ai pas trouvé (et je ne ferais pas confiance à) une publication capable de traiter efficacement la sélection de paradigmes dans le large éventail de projets d'ingénierie logicielle du monde réel.