@hupfdule
in der Tat ... da ich gerade keinen anderen Link zur Hand habe http://www.amazon.de/Softwareentwicklun ... 3540419586
markus
Wieviel Zeilen Code pro Tag
Hi,
Da ich nicht erst seit gestern im Showgeschaeft taetig bin, "norde ich die dann erstmal ein", bzw. mache denen die Konsequenzen klar, dann geht's normalerweise wieder. Wenn man das nicht macht, ist man selber am Ende der Arsch, und das ist mir zu Anfag ein paar male passiert. Mein Chef hatte dafuer zwar Verstaendniss, aber vom Kunden "rund gemacht zu werden" ist nicht das was ich mir wuensche.
Wie auch immer, ich werde das Thema weiter verfolgen.
Noe, eigentlich nicht.meandtheshell hat geschrieben:Weil ich das Gefühl habe das Du (roli) vielleicht unter einem Managment tätig bist, welches Deadlines setzt die nonsense sind.
Ich bin als Berater unterwegs, und die "tollen Ideen" was man immer alles noch machen koennte kommen meist vom Kunden.meandtheshell hat geschrieben:- Du hast das Fachwissen und musst aufklären (a room, a notebook, a beamer the managment and finally you)
- es ist deine Reputation die evtl. Schaden nimmt nicht nur die der Firma
Da ich nicht erst seit gestern im Showgeschaeft taetig bin, "norde ich die dann erstmal ein", bzw. mache denen die Konsequenzen klar, dann geht's normalerweise wieder. Wenn man das nicht macht, ist man selber am Ende der Arsch, und das ist mir zu Anfag ein paar male passiert. Mein Chef hatte dafuer zwar Verstaendniss, aber vom Kunden "rund gemacht zu werden" ist nicht das was ich mir wuensche.
Wie auch immer, ich werde das Thema weiter verfolgen.
Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
-
meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
@roli
Verstehe. Nichts für ungut, ich dachte nur Dir sitzt vielleicht jemand im Nacken. Viel Spass und guten Erfolg im Showgeschäft
well, ... and don't forget - people used to say: there's no business like show business. I'd not hesitate to agree on that (with the execption of "being with managment")
Wie nennt man das? Satirische Ironie?
markus
Verstehe. Nichts für ungut, ich dachte nur Dir sitzt vielleicht jemand im Nacken. Viel Spass und guten Erfolg im Showgeschäft
well, ... and don't forget - people used to say: there's no business like show business. I'd not hesitate to agree on that (with the execption of "being with managment")
Wie nennt man das? Satirische Ironie?
markus
Hi Markus,
Realismus? Kommt aber immer drauf an, zu welcher Guppe man selber gehoert.meandtheshell hat geschrieben:well, ... and don't forget - people used to say: there's no business like show business. I'd not hesitate to agree on that (with the execption of "being with managment")
Wie nennt man das? Satirische Ironie?
Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
-
dopehouse
- Beiträge: 452
- Registriert: 01.09.2005 12:02:16
- Lizenz eigener Beiträge: GNU General Public License
- Wohnort: Hildesheim (Niedersachsen)
-
Kontaktdaten:
Also auf einem IT-Meeting habe ich mal gehört, wie ein Redner sagte, dass seine Mitarbeiter ca 50 Zeilen Code pro Tagen schreiben würden ( C, C++ und C# keine kritischen Anwendungen).
Nun muss ich dazu sagen, dass man ja auch nicht genau weiß, wie die Zahlen zu interpretieren sind. Ich persönlich schreibe z.B. die geschweiften Klammern immer in einzelne Zeilen. D.h. ich hab schon mal zwei Zeilen Code in jedem Block, wofür ich ne Sekunde Zeit in anspruch nehme. Ne Headerdatei ist auch mal schnell geschrieben, weil ich die Funktionsdekleration nur eins-zu-eins übernehmen muss.
Hin und wieder verwerfe ich ganze Blöcke von Code, um sie durch etwas kleineres zu ersetzen, und mache mir so die Arbeit von Tagen zu nichte. Von daher ist es wirklich nicht Messbar, wieviel Code man so schreibt. Es gibt Tage, da sitzt man vor der Kiste und kommt nicht dazu ein Stück Code zu schreiben, weil man die Tage zuvor so einen Mist verzapft hat, dass man alles nochmal überarbeiten muss.
Im Großen und Ganzen finde ich aber, dass es mehr auf Qualität als auf Quantität ankommt. 100.000 Zeilen müssen nicht unbedingt besser sein als 1.000 Zeilen.
Power to the Code
Nun muss ich dazu sagen, dass man ja auch nicht genau weiß, wie die Zahlen zu interpretieren sind. Ich persönlich schreibe z.B. die geschweiften Klammern immer in einzelne Zeilen. D.h. ich hab schon mal zwei Zeilen Code in jedem Block, wofür ich ne Sekunde Zeit in anspruch nehme. Ne Headerdatei ist auch mal schnell geschrieben, weil ich die Funktionsdekleration nur eins-zu-eins übernehmen muss.
Hin und wieder verwerfe ich ganze Blöcke von Code, um sie durch etwas kleineres zu ersetzen, und mache mir so die Arbeit von Tagen zu nichte. Von daher ist es wirklich nicht Messbar, wieviel Code man so schreibt. Es gibt Tage, da sitzt man vor der Kiste und kommt nicht dazu ein Stück Code zu schreiben, weil man die Tage zuvor so einen Mist verzapft hat, dass man alles nochmal überarbeiten muss.
Im Großen und Ganzen finde ich aber, dass es mehr auf Qualität als auf Quantität ankommt. 100.000 Zeilen müssen nicht unbedingt besser sein als 1.000 Zeilen.
Power to the Code
Desktop: Lenny
Notebook: Lenny
Server: auch schon Lenny (mit Pinning von util-vserver auf die vorletzte Version)
Notebook: Lenny
Server: auch schon Lenny (mit Pinning von util-vserver auf die vorletzte Version)
Bisher ist mir in meiner Arbeit noch nie die Zeilenanzahl als Kriterium begegnet. Ich schreib ja auch keinen Code des Codes wegen, sondern um Wünsche und Forderungen des Kunden umzusetzen. Dafür ist die Anzahl der zeilen völlig unwichtig. Wichtig ist, wie ja auch schon mehrfach gesagt, die Erfüllung der geforderten Features, die Fehlerfreiheit und die Wartbarkeit des Codes.
Bin ich z.B. ein Copy-Paste Programmierer, dann hab ich zwar viel Code, meine Kollegen würden mich aber lunchen..
Gruß bert
Bin ich z.B. ein Copy-Paste Programmierer, dann hab ich zwar viel Code, meine Kollegen würden mich aber lunchen..
Gruß bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
Jaja, Programmierer sind ein hartes Volk 
Zum Glück bin ich kein Copy-Paste Programmierer, da kann mir ja nichts passieren.
Gruß Bert
Zum Glück bin ich kein Copy-Paste Programmierer, da kann mir ja nichts passieren.
Gruß Bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
Hi,
Mir gings/gehts in erster Linie darum zu erfahren, ob das eine "gaengige Groesse" ist. Bis vor zwei Tagen hatte ich halt noch nicht davon gehoert.dopehouse hat geschrieben:Also auf einem IT-Meeting habe ich mal gehört, wie ein Redner sagte, dass seine Mitarbeiter ca 50 Zeilen Code pro Tagen schreiben würden ( C, C++ und C# keine kritischen Anwendungen).
Sehe ich auch so, nur was wuerde das nuetzen wenn andere (Chef's) dich an X Zeilen pro Tag messen wuerden.dopehouse hat geschrieben:Im Großen und Ganzen finde ich aber, dass es mehr auf Qualität als auf Quantität ankommt. 100.000 Zeilen müssen nicht unbedingt besser sein als 1.000 Zeilen.
Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
markus_b hat geschrieben:Dann machst du einfach MDSD
Wenn ich mein aktuelles Metamodell generiere, schaffe ich 85.768 Zeilen in 5 Minuten
Geil, so wird's gemacht, und die Doku erzeuge ich dann mit SCIgen - An Automatic CS Paper Generator, dann sieht Supermann einfach nur alt aus Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
Hi,
na dann habe ich ja Glueck, das ich das Problem nicht habe mit meinem Chef ;-}
na dann habe ich ja Glueck, das ich das Problem nicht habe mit meinem Chef ;-}
Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
dann will ich auch mal meine senf dazu geben!
IBM hat vor einiger zeit eine studie durchgeführt und ist zu folgendem ergebnis gekommen:
nachtrag:
IBM hat vor einiger zeit eine studie durchgeführt und ist zu folgendem ergebnis gekommen:
Dies ist durchaus realistisch zu betrachen. Auf ein langfristiges Projekt passt das sehr gut. da viele vorab überlegungen getroffen werden müssen und der prozess der software entwicklung nicht unterschätzt werden sollte. (aus eigener leidlichen beruflichen erfahrung)Softwareentwicklung ist in besonderem Maße geprägt von Fehleinschätzungen. Sehr häufig wird der Zeitbedarf zu kurz geschätzt, sowohl für die Projektorganisation als auch für den Kommunikationsbedarf und die Programmierdauer. Laut Mayr produziert ein Programmierer im längerfristigen Durchschnitt:
* 10 LOC (Lines of Code) pro Arbeitstag
nachtrag:
auszug wikipediaLines of Code (abgekürzt LOC oder auch LoC) ist ein Begriff aus der Informationstechnik beziehungsweise dem Programmiererjargon. Er kommt aus dem Englischen und heißt übersetzt soviel wie "Programmzeilen". Gemeint ist damit die Anzahl an Programmzeilen, die ein Programmierer in einem bestimmten Zeitintervall (z. B. ein Tag) effektiv (also zur Lösung einer Problemstellung beitragend; "unter'm Strich") produziert hat. Diese Zahl ist stark von der Verfassung (Konzentration, Müdigkeit, ...) des Programmierers abhängig und kann nicht unwesentlich von der tatsächlich geschriebenen Anzahl an Quelltextzeilen abweichen.
Die Lines of Code sollen somit ein Maß für die Effizienz der Arbeit eines Entwicklers sein.
Hi,
hast du zu dem IBM Zitat auch die Quelle zur Hand?
hast du zu dem IBM Zitat auch die Quelle zur Hand?
Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
Wichtige Sachen dazu sind hier zu finden:
http://www.file-upload.net/download_10. ... n.zip.html
zu empfehlende kapitel:
Kapitel 2 - Zielsetzung und messung
Kapitel 5 - Software aufwandschätzung
http://www.file-upload.net/download_10. ... n.zip.html
zu empfehlende kapitel:
Kapitel 2 - Zielsetzung und messung
Kapitel 5 - Software aufwandschätzung
nicht schlecht, da habe ich was zu lesen
Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
Um die Entwicklungskosten schätzen zu können, wurden Methoden zur Kosten- und Terminschätzung
entwickelt. Die meisten Modelle basieren auf dem geschätzten Umfang des zu erstellenden Software-
Produkts in »Anzahl der Programmzeilen« bzw. in Lines of Code (LOC). Bei höheren Sprachen werden
z.B. alle Vereinbarungs- und Anweisungszeilen (ohne Kommentare) geschätzt.
Im einfachsten Fall wird dann der geschätzte Umfang durch einen Erfahrungswert für die
Programmierproduktivität (in LOC) eines Mitarbeiters pro Jahr oder Monat geteilt. Daraus erhält man
einen geschätzten Aufwand in Mitarbeiterjahren (MJ) oder Mitarbeitermonaten (MM) bzw.
Personenmonaten (PM). Um Urlaubs- und sonstige Fehlzeiten sowie Schulungszeiten zu
berücksichtigen, wird im Allgemeinen ein Mitarbeiterjahr neun oder zehn Mitarbeitermonaten
gleichgesetzt.
Wird der so ermittelte Aufwand noch durch die nach der Termin-Vorgabe zur Verfügung stehenden
Entwicklungszeit geteilt, dann erhält man theoretisch die Zahl der für die Entwicklung einzusetzenden,
parallel arbeitenden Mitarbeiter.
Empirische Untersuchungen bei der Firma Hewlett-Packard (135 P-Projekte) haben zu folgender
»Faustregel« geführt:
Eine durchschnittliche Software-Entwicklung liefert ungefähr 350 Quellcodezeilen (ohne Kommentare)
pro Ingenieurmonat. Dabei umfasst die Ingenieurzeit alle Phasen von der Definition bis zur
Implelentierung.
Beispiel:
Es soll ein Software-Produkt mit geschätzten 21.000 LOC realisiert werden. Beträgt die durchschnittliche
Produktivität pro Mitarbeiter 500 LOC/Jahr, dann werden sechs Mitarbeiterjahre zur Erstellung benötigt.
Arbeiten drei Mitarbeiter im Team zusammen, dann werden zwei Jahre bis zur Fertigstellung benötigt.
Eine Reduktion des Schätzmodells auf die Faktoren Produkt-Umfang und Mitarbeiterproduktivität
stellt natürlich ein sehr grobes Raster dar. Hinzu kommt, dass selbst diese Faktoren unsicher sind.
Die Schätzung des Produktumfangs wird mehr oder weniger intuitiv vorgenommen, wobei vorwiegend
auf Erfahrungen zurückgegriffen wird.
Bei kleineren Projekten und vertrautem Anwendungsgebiet sind solche Schätzungen noch hinreichend
genau, bei größeren Projekten und neuartigen Produkten sind sie jedoch sehr problematisch.
Quelle: aus meinen AusbildungsunterlagenEntwicklungsdauer
Die Entwicklungsdauer beeinflusst den Aufwand in folgender Form: Soll die Zeit verkürzt werden, dann
werden mehr Mitarbeiter benötigt. Mehr Mitarbeiter erhöhen den Kommunikationsaufwand innerhalb des
Entwicklungsteams. Der höhere Kommunikationsanteil jedes Mitarbeiters reduziert seine Produktivität.
Kann dagegen die Entwicklungsdauer verlängert werden, dann werden weniger Mitarbeiter benötigt und
der Kommunikationsanteil sinkt. Die Produktivität jedes Mitarbeiters steigt.
In /Boehm 81, S. 75/ wird folgende Formel zur Berechnung der optimalen Entwicklungsdauer
angegeben, wenn der Aufwand in Mitarbeitermonaten (MM) bekannt ist:
Optimale Entwicklungsdauer =2,5 * (Aufwand in MM)^S 2
[Monate] mit s = 0,38 für Stapel-Systeme
s = 0,35 für Dialog-Systeme
s = 0,32 für Echtzeit-Systeme.
Es wird geschätzt, dass der Entwicklungsaufwand für ein neues Dialog-System neun
Mitarbeitermonate beträgt. Als optimale Entwicklungsdauer ergibt sich: Dauer = 2,5 * 9^(0,35) = 5,3
Monate.
Die durchschnittliche Größe des Entwicklungsteams beträgt: Anzahl Mitarbeiter = 9 MM / 5,3
Monate = 1,7-2.
Hi,
ich vermute mal nicht, das du das abgetippt hast, oder?
Wenn ja => danke!
Wenn nein => wo gibt's das?
ich vermute mal nicht, das du das abgetippt hast, oder?
Wenn ja => danke!
Wenn nein => wo gibt's das?
Roland
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"
"Aber wenn du schon so unwissend bist, davon noch nicht gehört zu haben,
so will ich es doch als gut ansehen, daß du lieber einmal töricht fragst,
als weiterhin nichts von etwas zu wissen, das man doch wissen sollte."
aus "Die Edda des Snorri Sturluson", "Gylfis Täuschung"