Projektgrösse - Was ist klein, was ist gross?
-
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.
-
Bill Gates schrieb:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
-
Jester schrieb:
!rr!rr_. schrieb:
noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist.
Mir scheint, das ist kein geeignetes Maß.
wieso? Der Wert einer Lösung richtet sich nach der inhärenten Schwierigkeit des Problems.
Das ist der Idealfall.
-
Dann musst du halt ne Metrik für Problemkomplexität erfinden.
Etwas, womit alle zufrieden sind, wird sich hier vermutlich eh nicht finden lassen. Vielleicht bevorzugen einige von uns ja eh die Metrik, in der sie selbst mit ihrem Projekten am besten abschneiden würden.
Selbst sich auf ein Mittelwertsverfahren zur Kombination vieler Metriken zu einigen, könnte ziemlich schwierig werden.
-
hustenkuchen schrieb:
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
Was ist besser?
Für Schwanzlängenvergleiche in Programmierforen? Dafür passen sowohl Codezeilen als auch Klassenanzahl ganz gut. Besonders wenn man dann noch Binning über die LOC macht, um in "klein", "mittel" und "groß" einzuteilen.
Ansonsten ist es interessanter, sich anzusehen zu welchem Zweck überhaupt die Projektgröße gecheckt werden soll. Eine sinnvolle Metrik, mit der man jedem fachfremden BWLer ein paar hübsche Diagramme in die Hand drücken kann und damit dann ein brauchbares Bild der Projektgröße vermittelt, gibt es wohl kaum.
-
nman schrieb:
hustenkuchen schrieb:
nman schrieb:
Projektgrößen in Zeilen Code zu messen ist… Eigenartig.
Was ist besser?
Für Schwanzlängenvergleiche in Programmierforen? Dafür passen sowohl Codezeilen als auch Klassenanzahl ganz gut. Besonders wenn man dann noch Binning über die LOC macht, um in "klein", "mittel" und "groß" einzuteilen.
Ansonsten ist es interessanter, sich anzusehen zu welchem Zweck überhaupt die Projektgröße gecheckt werden soll. Eine sinnvolle Metrik, mit der man jedem fachfremden BWLer ein paar hübsche Diagramme in die Hand drücken kann und damit dann ein brauchbares Bild der Projektgröße vermittelt, gibt es wohl kaum.
Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt und dann kommt doch nur raus, dass du auch nix weißt, außer dass man LOC eigenartig finden muss...
-
hustenkuchen schrieb:
Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt
Das ist eine interessante Interpretation meines Posts. Ich brauche keine bessere Idee zu haben, um eine schlechte Idee zu erkennen.
Vielleicht ist es einfach eine dumme Idee, zu versuchen so etwas kompliziertes wie die Frage wieviel Arbeit bereits in einem Projekt steckt und wieviel man noch hineinstecken muss, in eine einzelne Zahl packen zu wollen, die auch fachfremde Menschen leicht verstehen und vergleichen können. Nein, Moment, du hast natürlich Recht, das kann es doch nicht sein…
-
nman schrieb:
hustenkuchen schrieb:
Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt
Das ist eine interessante Interpretation meines Posts. Ich brauche keine bessere Idee zu haben, um eine schlechte Idee zu erkennen.
Vielleicht ist es einfach eine dumme Idee, zu versuchen so etwas kompliziertes wie die Frage wieviel Arbeit bereits in einem Projekt steckt und wieviel man noch hineinstecken muss, in eine einzelne Zahl packen zu wollen, die auch fachfremde Menschen leicht verstehen und vergleichen können. Nein, Moment, du hast natürlich Recht, das kann es doch nicht sein…
Darum, wieviel Zeit man noch reinstecken muss, gings nie. Aber egal, schon ab deinem Post mit dem Schwanzlängenvergleich hätte man dich ignorieren sollen.
