Projektgrösse - Was ist klein, was ist gross?
-
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 ...)
-
!rr!rr_. schrieb:
Mannjahre
Auch schwierig, weil manche Männer einfach Jahre für Kleinkram brauchen während andere in der selben Zeit spektakuläre Welten aufbauen.
Um das loszuwerden könnte man nicht die tatsächlich gebrauchten Mannjahre nehmen sondern die Zeit, die viele Entwickler aus verschiedenen Bereichen durchschnittlich als Entwicklungszeit dafür schätzen würden wenn sie es selbst machen müssten.
Mal abgesehen davon, dass man dafür viele Entwickler braucht, die alle drüber nachdenken, um eine Schätzung abgeben zu können, hätte man dann wieder das Problem, dass manche Themen vielleicht tendentiell eher unterschätzt und andere tendentiell eher überschätzt werden.
-
Dobi schrieb:
Um das loszuwerden könnte man nicht die tatsächlich gebrauchten Mannjahre nehmen sondern die Zeit, die viele Entwickler aus verschiedenen Bereichen durchschnittlich als Entwicklungszeit dafür schätzen würden wenn sie es selbst machen müssten.
Abre es kann sein, dass a-posteriori Projekte am Code geschätzt als sehr schnell implementierbar gelten "sind ja nur 10000 Zeilen Code", aber hinter dem Projekt a-priori ein Problem steckt, für dessen Lösung enorm viel Denkleistung rein gesteckt werden musste.
Der langsame Programmierer könnte am Ende dann doch der sein, der das Gesamtprojekt von Problemstellung bis Programmierung am Schnellsten hin kriegt.
-
!rr!rr_. schrieb:
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 ...)
Wieso sollte ausgerechnet das ein gutes Maß sein? Es gibt Probleme, die lassen äußerst effiziente Algorithmen zu, aber implementieren möchte ich die auf keinen Fall. Mir scheint, das ist kein geeignetes Maß.
-
ich bin mittlerweile an dem punkt, wo ich mich einfach freu, wenn mein derzeitiges 'projekt' fertig ist/wird. es ist so verzwickt, hätt ichs nur mit php gemacht, wär ich schon 10 mal fertig
und das ohne komplexität, besondere algorithmen oder eine neue idee
-
Ich finde, wenn ein Projekt ausreichend "groß" ist, dann gleichen sich die Metriken meist aus... Es ist davon auszugehen, dass in jedem großen Projekt sowohl hochkomplexe Algorithmen sind, die bei wenigen Codezeilen sehr viel Zeit und Hirnschmalz in Anspruch nehmen, als auch viel Code, den man einfach runtertippt und dabei zehntausende von Programmzeilen produziert. Haben wir zumindest in unserem Projekt. Bei meinem Projekten ist es auch meist so, dass die zeilenmäßig größten Teile nicht die meiste Zeit brauchen. Ich kann Klasse mit 1000 Zeilen Code oder mehr an einem Tag runtertippen, aber es gibt auch Tage, da suche ich einfach einen Bug und ändere dabei eine einzige Zeile, oder ich überlege mir eine Lösung für einen Sonderfall.