Welche Evidenzhierarchie passt zu Aussagen über Software-Engineering-Praktiken?

Offene Frage

Die Medizin verfügt über explizite Evidenzhierarchien, etwa die Oxford-CEBM-Stufen, samt einer anerkannten Debatte über deren starre Anwendung. Aussagen über Engineering-Praktiken (Code-Reviews verringern Fehler, Trunk-based Development beschleunigt die Auslieferung, Microservices helfen oder schaden ab einer bestimmten Grösse) stützen sich vor allem auf Fallstudien, Praktiker-Umfragen, Herstellerberichte und eine kleine Zahl kontrollierter Experimente mit Studierenden oder innerhalb eines einzelnen Unternehmens. Hat jemand ein Bewertungsschema für solche Aussagen vorgeschlagen, das Praktiker tatsächlich anwenden, wenn sie Richtlinien schreiben oder Vorschläge prüfen? Welche Stufen und Abwertungsfaktoren enthält es (Anzahl der Teams, Selbstselektion, Messung durch die Anwendenden selbst, Herstellerinteresse, ob Fehlschläge veröffentlicht wurden), und wie behandelt es Praktiken, deren Wirkung stark von Teamgrösse, Domäne oder Tooling abhängt?

Was eine nützliche Antwort enthält

Die Stufen und Kriterien des Schemas vollständig; wo es eingesetzt wurde (ein Wiki, ein Review-Prozess, interne Richtlinien eines Unternehmens) und wie lange; Beispiele derselben Praxis, unabhängig von zwei Lesenden bewertet, samt den Abweichungen und wie sie aufgelöst wurden; bekannte Fälle, in denen eine hoch bewertete Aussage später revidiert wurde; sowie die vom Schema selbst genannten Grenzen aus Sicht seiner Anwender. Antworten sollten angeben, ob das Schema Aussagen über Ergebnisse (Fehlerraten, Durchlaufzeit) von Aussagen über Mechanismen (warum eine Praxis wirkt) unterscheidet, da Letztere selten durch Vergleich prüfbar sind, und ob es eine eigene Note für die Übertragbarkeit auf einen anderen Kontext vergibt. Vorschläge, die noch nicht angewendet wurden, sollten als solche gekennzeichnet werden; wurde nirgends ein Schema angewendet, ist auch eine Antwort nützlich, die dies feststellt und die nächstliegenden Versuche samt den Gründen nennt, warum sie nicht übernommen wurden.