Für die vorherige Aufnahme siehe Revision 1 dieser Antwort . Die Kommentare und Änderungen an der Frage verdeutlichen jedoch weiter, wonach die Frage sucht, und ermöglichen es mir, klarer zu sein.
Ja, evidenzbasiertes Software-Engineering (EBSE) ist eine Sache. Es scheint einige Anstrengungen in Richtung EBSE-Datenbanken zu geben, wie diese an der Durham University und SEED, die von einem Professor an der Cal Poly ins Leben gerufen wurden . All diese Bemühungen sowie diejenigen, die in einer Reihe von Artikeln besprochen wurden, die über den IEEE Xplore-Server oder die ACM Digital Library verfügbar sind(Abonnement oder Kauf für viele Artikel in beiden erforderlich), basieren auf evidenzbasierter Medizin. Sie bieten Literaturübersichten zu veröffentlichten empirischen Daten (Beobachtung und Experiment). Tatsächlich liefert das Einfügen von "Literaturübersicht" in eine Suchzeichenfolge bei jeder Publikationssuche Informationen zu den meisten Themen - über 14000 Treffer im ACM und über 1000 in der IEEE-Datenbank (wenn nur Computerthemen beschränkt sind).
Wenn ich mir die allgemeinen Arten von Themen anschaue, die in diesen EBSE-Datenbanken und Literaturrecherchen behandelt werden, sehe ich einen roten Faden - sie sind in der Regel technologieunabhängig. Der Schwerpunkt scheint eher auf dem Prozess und der Methodik als auf den spezifischen Tools zu liegen, die für die Durchführung des Software-Engineerings verwendet werden.
Dieses Konzept existiert also in der Softwareentwicklung. Die Wissenschaft ist sich des evidenzbasierten Konzepts bewusst und kann es erfolgreich auf das Software-Engineering anwenden.
Insbesondere scheint die Frage, ob EBSE-Techniken auf die Auswahl eines Paradigmas angewendet werden sollen, schwierig zu sein, da es sich um eine Vielzahl von Variablen handelt, die Annahmen erzwingen und die Fähigkeit zur Wiederholung des Experiments oder der Beobachtung verringern. Er sagte , das Recht in der Frage - „ das Paradigma kommt als‚die richtige Antwort‘kann davon abhängen , welche Messwerten eine bestimmte Studie achtet auf, unter welchen Bedingungen der Studie hält konstant oder variiert, und zweifellos von anderen Faktoren zu“ . Obwohl dies nicht bedeutet, zu untersuchen, welches Paradigma in einer bestimmten Situation "am besten" ist, macht es jede Art von Literaturrecherche dieser Dokumente unglaublich schwierig, Informationen zu vervollständigen und dennoch zu extrahieren.
Es gibt definitiv keine "Turn the Crank" -Lösung für die Auswahl eines Paradigmas.
In Anbetracht eines Programmierparadigmas finden Sie in den verschiedenen akademischen und industriellen Datenbanken Studien darüber, wie dieses Paradigma verschiedene Aspekte der Softwareentwicklung - Qualität, Mängel, Effizienz usw. - unter verschiedenen spezifischen Bedingungen beeinflusst, angefangen vom Wissen und der Erfahrung des Team zur Problemdomäne. Jedes strenge Papier sollte die Bedingungen, unter denen die Daten gesammelt wurden, und die Annahmen klar identifizieren. Das Problem besteht darin, zu versuchen, die Faktoren zu isolieren, die es unter jeder dieser Bedingungen gut machen.
Akademisch gibt es einige Aussagen, die leicht zu recherchieren sind. Die Aussage, dass das Funktionsparadigma gut für Anwendungen geeignet ist, die Parallelität erfordern, stammt beispielsweise aus dem Church-Rosser-Theorem . Aus diesem Grund ist es wahrscheinlich, dass ein in einer funktionalen Sprache geschriebenes Softwaresystem weniger Parallelitätsfehler aufweist als dasselbe in einer prozeduralen oder objektorientierten Sprache geschriebene System.
Aus praktischer Sicht kann ein Softwareteam jedoch nicht immer "das beste" Werkzeug oder die beste Technik für den Job verwenden, nur weil die Forschung dies anzeigt. Obwohl wir uns bemühen, Softwaresysteme von höchster Qualität zu produzieren, arbeiten wir innerhalb von Einschränkungen. Oft sehe ich diese Einschränkungen minimiert (oder sogar aus der Gleichung entfernt), wenn ich die Wirksamkeit einer Methodik diskutiere.
Als Praktiker versuche ich bei der Auswahl der zu verwendenden Technologien, die bestmöglichen Werkzeuge zu identifizieren. Aber dann beschränke ich mich auf das, was das Team, das ich habe, kennt und versteht. Zurück zu meinem vorherigen Beispiel: Wenn ich ein Team habe, das sich mit dem Erstellen gleichzeitiger Anwendungen in C ++ auskennt und keine Erfahrung mit Haskell hat, ist es nicht sinnvoll, das System in Haskell zu erstellen, da ich dies wahrscheinlich nicht tun kann Zeitplan- und Budgetbeschränkungen, und meine Qualität wird wahrscheinlich aufgrund mangelnder Erfahrung in der Toolchain leiden.
Zusammenfassend lässt sich sagen, dass evidenzbasiertes Software-Engineering im Allgemeinen eine gute Sache ist und dass Literaturrecherchen existieren und leicht verfügbar sind. Es gibt jedoch Aspekte des Software-Engineerings, bei denen die Anwendung evidenzbasierter Ansätze wenig Wert bietet. Die Auswahl eines Programmierparadigmas für einen großen Entwicklungsaufwand ist eine davon.
Wenn Sie herausfinden möchten, wie die Objektorientierung Wiederverwendbarkeit oder Mängel in der Funktionsprogrammierung behebt, finden Sie leicht Veröffentlichungen zu diesen Themen. Ich habe jedoch keine Veröffentlichung gefunden (und ich würde auch kein gewisses Vertrauen in sie setzen), die in der Lage ist, die Paradigmenauswahl in einem breiten Spektrum realer Softwareentwicklungsprojekte effektiv anzugehen.