Projektgrösse - Was ist klein, was ist gross?
-
Nee, so viel besser als C++ ist C+++ auch nicht
Erst in der Version C++++ wirds wirklich besser 
Naja, "wirklich groß" sind für mich als Richtwert die bekannten großen Programme. Und Visual Studio umfasst angeblich 65 Millionen Zeilen Code. Bei Open Office sind es glaub so 15-20 Mio. Also ist unsere Software im Moment noch eine Stufe drunter.
-
Mechanics schrieb:
Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code.
Ist das alles für nur ein Programm? Wie lang kompiliert ihr?
-
Mechanics schrieb:
Nee, so viel besser als C++ ist C+++ auch nicht
Erst in der Version C++++ wirds wirklich besser Naja, "wirklich groß" sind für mich als Richtwert die bekannten großen Programme. Und Visual Studio umfasst angeblich 65 Millionen Zeilen Code. Bei Open Office sind es glaub so 15-20 Mio. Also ist unsere Software im Moment noch eine Stufe drunter.
Jo, Linux 2.6 hatte nichtmal 6msloc, aber das ist ja auch nur ein kleines Projekt.
-
90000.1 schrieb:
Mechanics schrieb:
Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code.
Ist das alles für nur ein Programm? Wie lang kompiliert ihr?
Das könnte man als Programmsuite bezeichnen... Sind mehrere zusammengehörende Programme, die auf denselben Bibliotheken von uns basieren. Alles durchkompilieren dauert so 4 Stunden.
-
Ethon schrieb:
Jo, Linux 2.6 hatte nichtmal 6msloc, aber das ist ja auch nur ein kleines Projekt.
Mittlerweile hat Linux ja 15 Mio Zeilen. Und ich hab gesagt, dass ich unser Projekt als mittelgroß einschätze, nicht klein
Und "Linux 2.6" gibts nicht, es gibt den Kernel. Und außer dem Kernel gibt es bei Linux schon einen ganzen Haufen anderer Programme, ich schätze, eine übliche Installation mit X-Server, KDE, paar Programmen wird es auf über 100 Mio Zeilen bringen.
-
da haben auch paar affen ganz schön geklotzt
-
Mechanics schrieb:
Und Visual Studio umfasst angeblich 65 Millionen Zeilen Code.
Wo hast Du das gelesen?
VS ist schon ein mächtiges Programm, aber 65 Mio scheinen mir arg übertrieben. Zum Vergleich: Win XP hat laut Wiki gerade mal 45 Mio.Neee. Glaub ich nicht
-
Mechanics schrieb:
Und "Linux 2.6" gibts nicht, es gibt den Kernel.
Doch, gibt es. Linux 2.6 ist der Kernel. In Version 2.6.
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
-
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
In Klassen aber genauso. Ich wüsste so aus dem Stehgreif keine sinnvolle Messgröße. Unterliegt alles alles entweder menschlichen Einflüssen, die naturgemäß subjektiv sind, oder aber Codestil oder anderen Dingen. Ein und das selbe Projekt kann je nach Umsetzung bei einer gegebenen Messgröße sehr unterschiedliche Messungen ergeben.
-
Ein Mittel zur Aufwandsschätzung im Projektmanagement ist das Function-Point-Verfahren
http://de.wikipedia.org/wiki/Function-Point-Verfahren
Wie der Name vermuten lässt, wird hier der Aufwand anhand der Funktionalität gemessen und nicht anhand der Codezeilen. Dadurch ergibt sich der Vorteil, dass man nicht von der eingesetzten Programmiersprache abhängig ist.
-
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
Findest du? Ich bin fast sicher, dass Unterschiede von 10000 vs. 100000 vs. 6 Mio Zeilen vs. 60Mio Zeilen sich in allen anderen Metriken ebenfalls widerspiegeln. Die Einteilung ist zwar grob, aber für eine erste Einschätzung scheint mr das gut hinzuhauen -- zumindest bei diesen stark unterschiedlichen Größenordnungen.
Funktionspunkte sind zwar nett, aber leider kennt man die hält bei Fremdprojekten nicht, deswegen sind die zum vergleichen nicht so gut geeignet.
-
Bei uns gibt's um die 600.000 LOC und ca. 3000 Labview-Vi's (allerdings fast alles in einer exe, keine "Programmsuite"). Das sehe ich als mittelgroßes Projekt an. 6 Mio. hört sich schon groß an, ehrlich gesagt.
-
Vic schrieb:
Ein Mittel zur Aufwandsschätzung im Projektmanagement ist das Function-Point-Verfahren
http://de.wikipedia.org/wiki/Function-Point-Verfahren
Wie der Name vermuten lässt, wird hier der Aufwand anhand der Funktionalität gemessen und nicht anhand der Codezeilen. Dadurch ergibt sich der Vorteil, dass man nicht von der eingesetzten Programmiersprache abhängig ist.Interessanter Ansatz, allerdings sieht es für mich ein bischen so aus, als würde man das Kernproblem damit teilweise einfach verschieben:
"Die Functional-Size wird bestimmt, in dem man die funktionalen Anforderungen an eine Anwendung in kleinste, für den Anwender sinnvolle Aktivitäten, die Elementarprozesse, zerlegt. Gleiche Elementarprozesse werden nur einmal gewertet. Jedem Elementarprozess wird ein definierter Punktwert zugeordnet. Die Summe der Punktwerte aller Elementarprozesse ergibt die Functional-Size."
Für den Anwender ist beispielsweise das Gesamtverhalten der Software, an der ich gerade arbeite (Objekterkennung), selbst die kleinste sinnvolle Aktivität. Bild rein -> Erkennungsergebnis raus. Wieviele Punkte gibt man dem nun im Vergleich zu einem zusätzlichen Eingabefeld, in das der Benutzer den Namens seines Haustiers eintragen kann?
-
Dobi schrieb:
Für den Anwender ist beispielsweise das Gesamtverhalten der Software, an der ich gerade arbeite (Objekterkennung), selbst die kleinste sinnvolle Aktivität. Bild rein -> Erkennungsergebnis raus. Wieviele Punkte gibt man dem nun im Vergleich zu einem zusätzlichen Eingabefeld, in das der Benutzer den Namens seines Haustiers eintragen kann?
Genau. Diese Function-Points sind für so typische Business-Software mit Eingabemasken und Datenbanken ohne nennenswerte algorithmische Komplexität.
-
Jester schrieb:
Die Einteilung ist zwar grob, aber für eine erste Einschätzung scheint mr das gut hinzuhauen -- zumindest bei diesen stark unterschiedlichen Größenordnungen.
Die Frage ist, ob eine Einteilung in "kleine", "mittlere" und "große" Projekte überhaupt irgendwie Sinn macht. Bzw. wozu man die in der Form des Threads hier überhaupt verwenden kann.
Klar kann man Codezeilen zählen; das Problem das ich damit habe ist, dass verdammt viele andere Parameter übereinstimmen müssen, damit die LOC zweier unterschiedlicher Projekte in irgendeiner Form brauchbar vergleichbar sind.
-
pumuckl schrieb:
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
In Klassen aber genauso.
Klar, absolut. Häufig sogar noch eigenartiger.
-
Die Anzahl Klassen/LOC machen z.B. wenig bis überhaupt keinen Sinn wenn man ewig an dem Knowhow gegrübelt hat und mit viel Manpower über Jahre dann unter dem Strich in "wenig" LOG oder Klassen gepackt hat. Wie z.B 3D-Engines, Datenbanken und so weiter und so fort.
EDIT: Wie viel legacy code unter Klassen/LOG zu finden sind müsste auch für einen guten Vergleich bekannt sein.
-
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
Was ist besser?
-
RAM-Verbrauch.
-
Mannjahre
noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist. Aber dazu müßte man erstmal die Problemkomplexität des zugrundeliegenden Problems kennen, und das ist bisher nur in wenigen Fällen gelungen (Sortierprobleme, boolesche netze ...)