Dies ist keine Frage der Qualität der SLoC-Metrik. Ich akzeptiere es als eine begrenzte, ungenaue oder sogar schlechte Metrik.
Abgesehen davon suche ich nach Daten, die angeben, welche vernünftigen Preise für die Softwareentwicklung SLoC gegeben haben. Von besonderem Interesse sind die Tarife für verschiedene Regierungsbehörden, aber alle Erkenntnisse sind hilfreich.
Klärung
Ich habe bereits eine Softwareanwendung entwickelt und sie ist versandbereit. Der Preis wurde zuvor vertraglich festgelegt und ist nicht strittig. Das Buchhaltungsteam sucht jedoch nach einem numerischen Grund, um seine Zustimmung zu geben. Diese Leute berücksichtigen nicht die erforderlichen Fähigkeiten oder Kenntnisse, die Lernkurve, den generierten Code, die Effizienz oder irgendetwas anderes. Ihnen wurden bereits gültige Metriken vorgelegt, die die „Kosteneinsparungen“ zeigen. Wir haben sie zu 80 % gerettet. Aber jetzt müssen wir die restlichen 20 % rechtfertigen. Sie haben andere Kostenvoranschläge erhalten, aber das reicht nicht aus. Also versuche ich, die Bürokratie mit etwas zu beschwichtigen, auf das sie sich beziehen könnte.
In Software Estimation: Demystifying the Black Art präsentiert Steve McConnell eine angepasste und erweiterte Tabelle aus Measures for Excellence: Reliable Software On Time, Within Budget , Industrial Strength Software und Five Core Metrics: The Intelligence Behind Successful Software Management für line of Code pro Mitarbeitermonat für verschiedene Arten von Software. Diese Tabelle zeigt die niedrigen, hohen und nominalen Werte für verschiedene Arten von Projekten und die Gesamtgröße (in Codezeilen, die von 10.000-LOC bis 250.000-LOC reichen).
Im Folgenden fasse ich diese Tabelle mit dem Bereich der höchsten hohen Produktivitätsrate, der niedrigsten niedrigen Produktivitätsrate und dem Bereich der Nominalraten in Klammern zusammen:
Wie immer sollte beachtet werden, dass die internen Daten Ihrer Organisation nützlicher sind, da sie Ihre Methoden und Verfahren berücksichtigen. Daten, die aus breit angelegten Umfragen gesammelt wurden, sind tendenziell verrauschter, da sie eine große Bandbreite an technischen Fähigkeiten, Prozessen, Werkzeugen usw. beinhalten.
Beachten Sie, dass dies andere Variationsquellen nicht berücksichtigt. Beispielsweise spielen Programmiersprache und -umgebung eine Rolle. Die Wiederverwendung bestehender Komponenten ist wichtig. Erfahrung zählt. Allgemeine Komplexität und Variabilität sind wichtig.
Als schnelle Antwort: „Roughly 1 screen, per team member, pro day“ von getestetem (gedebuggtem) Code.
Also etwa 24 Zeilen in den 70/80er Jahren. Und heutzutage bis zu 50 Zeilen.
Aber es kommt sehr darauf an, wie die Entwicklung organisiert ist! Beispielsweise kann die (richtige) Einführung von Lean/Agile/Scrum diese Zahlen um 30 % verbessern.
Ashok Ramachandran