Projektgrösse - Was ist klein, was ist gross?
-
Deine Überheblichkeit brauche ich bestimmt nicht. Daher würde ich es begrüssen, wenn Du Dich von diesem Thread einfach fern hälst und die Antworten den Leuten überlässt, die nicht so Arrogant sind wie Du. Danke.
-
Ich denke mal deine Frage lässt sich objektiv schwer beantworten. Für mich sind kleine Projekte immer die die jemand auch Alleine stemmen kann, das können aber auch Webprojekte mit 100 Klassen sein, denn ein Framework wie z.B. Zend bringt schon einiges an Klassen mit.
Minecraft zum Beispiel wurde wiederum nur von einem Einzelnen programmiert, aber ich würde es gefühlsmäßig zwischen klein und mittel einordnen.
Facebook z.B. war anscheinend ein sehr kleines Projekt da der Kern innerhalb weniger Stunden realisiert wurde. Ich denke hier ist die Schwierigkeit weniger die Lines of Code sondern eher Datenbank-/Serverarchitektur.
Vielleicht gibt es für dich eine Möglichkeit, bei den ganzen OpenSource Portalen eine Statistik über z.B. Klassenanzahl herauszufinden und damit kannst du dann dein Projekt vergleichen.
-
Was interessiert dich denn die Klassenzahl? Wenn du es mit weniger Klassen schaffst, und diese nicht völlig überladen sind, ist doch alles in Butter. Einfacher Test: Geh zur Konkurenz, überlege für alle Features die dein Framework nicht hat aber irgendwann man brauchen könnte, ob man sie implementieren kann ohne das ganze Design umzuwerfen.
-
Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code. Das nur C+++, dazu kommt noch ein ganzer Haufen anderer Sprachen...
Ich selbst schätze das Projekt als mittelgroß ein. Kommt an die ganze großen Projekte, wie Open Office oder Visual Studio nicht ganz heran.
-
Mechanics schrieb:
Das nur C+++...
Ist das deutlich besser als C++?
-
Mechanics schrieb:
Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code. Das nur C+++, dazu kommt noch ein ganzer Haufen anderer Sprachen...
Ich selbst schätze das Projekt als mittelgroß ein. Kommt an die ganze großen Projekte, wie Open Office oder Visual Studio nicht ganz heran.also wenn 6msloc nicht groß ist, weiß ich auch nicht
-
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.