Projektplaung - Schätzwerte

[bernhard_LA]

Hallo,

ich muss für ein existierendes Delphi Projekt eine Kostenschätzung für die Option Neuentwicklung bzw. Wartung/Refactoring abgeben .

Die Rahmenbedingungen des Projektes sind

1. ca. 500.000 Zeilen Quellcode ( Delphi ca. 80 %, Matlab ca. 15 % , C++ ca. 5 % )
2. Thema : stark technisch
3. Entwickler Team (heute) : Fachexperten ( Elektrotechnik, Mathematik)
4. Entwickler Team (geplant) : Informatiker , ...
5. Aufwand bisher : ca. 5..8 Mann-Jahre
6. Anwender : Experten

Was suche ich als Antwort :

wie bekomme ich eine erste Kostenabschätzung, gibt es Referenzen (am besten Projekte auf die man sich beziehen kann) , Erfahrungswerte, Richtwerte ....
gibt es Aussagen zum Thema "Minimale Teamstärke in der Abhängigkeit von der Projektkomplexität " um ein Projekt stabil hinzubekommen ???
gibt es überhaupt eine Eingruppierung vom Entwicklungen vs. Komplexität ?

[Furtbichler]

Breche das Projekt in Teilprojekte mit max 10 PT auf, d.h. jedes Teilprojekt, das > 10 PT ist, wird unterteilt (wobei die 10 Personentage etwas willkürlich ist). Zeit für das Testen nicht vergessen!

Verwende PERT, um eine einigermaßen reelle Abschätzung zu bekommen.

Wenn im Projekt unterschiedliche Expertisen gefragt sind, kannst Du das parallel fahren lassen.

Ich würde dann noch 30% Overhead einbauen, für Meetings und Abstimmung, wobei 30% vielleicht etwas knapp sind.

Ich habe für ein Projekt, das stark GUI-lastig war, natürlich separate GUI-Entwickler genommen. Die müssen keine Supercoder sein, aber wenn sie ein gutes Formgefühl haben und die Grundkenntisse ergonomischer Benutzerschnittstellen kennen, und dann noch lernwillig sind (sind die meisten jungen Leute), dann kannst Du ne geile Truppe zusammenstellen.

[Lemmy]

Zitat von bernhard_LA:

Was suche ich als Antwort :

wie bekomme ich eine erste Kostenabschätzung, gibt es Referenzen (am besten Projekte auf die man sich beziehen kann) , Erfahrungswerte, Richtwerte ....
gibt es Aussagen zum Thema "Minimale Teamstärke in der Abhängigkeit von der Projektkomplexität " um ein Projekt stabil hinzubekommen ???
gibt es überhaupt eine Eingruppierung vom Entwicklungen vs. Komplexität ?

wüsste nicht, dass es so was gibt - ausgenommen halbwegs allgemeine Statistiken von den Branchengrößen, die sich darüber schon sehr viel Gedanken gemacht haben. Aber die werden so allgemein sein, dass sie dir nicht helfen, weil bei dir ja das Entwicklungsteam vermutlich erst mal recht stabil (d.h. wenig Fluktiation) sein wird. Wobei, schau dir insbes. mal Kapitel 27 von "Code Complete" (bzw. finde ich das ganze Buch super) an

Hier hilft wirklich nur das Problem in kleine Teile zu zerlegen und selbst zu schätzen. Und am besten machen das mind. 2 Personen und dann noch am besten mit 2 verschiedenen Vorgehensweisen. Liegen die Schätzungen von Teilbereichen recht nah beieinander dann sollte das wohl so hinkommen (gehen wir mal davon aus, dass die beiden Schätzer wirklich unterschiedliche Methoden anwenden und nicht den selben Fehler machen). Bei großen Differenzen dann nachschauen wo diese herkommen.

[r2c2]

Oh, da gibts so einiges. Übers Schätzen gibts ganze Bücher und in den Projektmanagement-Vorlesungen an der Uni gibts immer mindestens eine, wenn nicht sogar mehr Vorlesungseinheiten dazu. Wenn du ein bisschen suchst, findest du da viel.

Leider hab ich momentan kaum Zeit, kann hier also nicht viel schreiben. Außerdem muss ich sagen, dass ich auf dem Gebiet hauptsächlich theoretische Kenntnisse hab. Meine eigenen Erfahrungen bezüglich Schätzen, sind überschaubar, also sei vorsichtig mit dem, was hich heir sage:

- Zum Schätzen eignet sich das Delphi-Verfahren. Das heißt tatsächlich so, hat aber mit Delphi nichts zu tun. Wie hier schon vorgeschlagen wurde, stützt sich das auf das systematische runterbrechen in Teilaufgaben und getrennte Schätzungen. Am Ende fällt ein Wert in Personentagen raus.
- Es gibt FunctionPoint-Verfahre + diverse Abwandlungen. Die Vergeben für bestimmte Anforderungen Punkte, die dann über einen erfahrungsbasierten, organisationsabhängigen Schlüssel in Personentage umgerechnet werden. Kanst du nur machen, wenn du da viel Erfahrung drin hast oder externe Experten kommen lässt. Ist also wohl eher weniger relevant.
- Eines der Lieblingsverfahren meines Profs sei auch noch erwähnt. CoCoMo. Hier basiert die Schätzung auf basis der ebenfalls geschätzten Größe LOC. Kannst du nur machen, wenn du bereits eine große Datenbasis hast. Also eher weniger interessant.
- Es gibt Datenbanken mit tausenden von Projektdaten drin. Von ganz kleinen bis ganz große. Du gibtst deine Daten ein (Projektgröße, Anzahl und Erfahrung der Entwickler, etc.) und am Schluss kriegst du ne statistische Auswertung, wie lange andere gebraucht haben. Zugang zu solchen Datenbanken ist aber IIRC kostenpflichtig und ich müsste auch erst nachgucken, wie die Dinger heißen.
- Man sagt als Daumenregel gilt: die Quadratwurzel des Projektaufwands in Personenmonaten ergibt in etwa die maximal sinnvolle Teamgröße. Der Name der Regel ist mir grad entfallen.
- Auch wichtig: Hofstadter's law

mfg

Christian

[bernhard_LA]

Danke für die Antworten.

Einige von Euch verdienen ja auch mit Software Entwicklung ihr Geld wie ich vermute
Ich möchte hier jetzt keine öffentliche Projektausschreibung beginnen,
mich würden aber Eure ersten Fragen an mich interessieren um bei einem möglich Auftrag die Rahmenbedigungen abzustecken.

[mjustin]

Nach CoCoMo geschätzt hat ein 524KLOC Delphi Open Source Projekt laut ohloh.net 141 Mannjahre benötigt: http://www.ohloh.net/p/DAV

[r2c2]

Zitat von mjustin:

Nach CoCoMo geschätzt hat ein 524KLOC Delphi Open Source Projekt laut ohloh.net 141 Mannjahre benötigt: http://www.ohloh.net/p/DAV

Wobei man anmerken muss, dass das so, wie das da verwendet wurde, nicht viel aussagt:
- Es wird nur das Basismodell verwendet und alle Einflussfaktoren ignoriert
- Es wird nicht auf die Zählweise Rücksicht genommen. Boehm verwendete nicht einfach die reine Zeilenzahl, sondern die Größe kDSI: kilo delivered source instructions.
- Es werden die festen Faktoren a = 2,4 und b = 1,05 verwendet. Das sind aber quasi nur Beispielwerte, die Boehm aus ner Handvoll Projekten aus den 80ern errechnet hatte. Will man CoCoMo selbst einsetzen, braucht man neue und vor allem eigene Zahlen. Also hübsch ne DB mit den eigenen Projekten aufbauen, nen Scatterplot machen, ne Kurve reinlegen und anhand dessen die Parameter für CoCoMo bestimmen. Wenn du mal so 50 oder 100 Projekte gemacht hast, kann das IMHO ganz gut funktionieren. [1] Je größer die Datenbasis desto besser wird die Schätzung. Bei Datenbasis 0 ist die Schätzung nach CoCoMo nur ne nichtssagende Zahl.

Deshalb hab ich gesagt, dass das hier nicht in Frage kommt. Schätzen ist nicht so einfach, dass man ne Zeilenzahl in ne Formel einsetzt und am Ende fällt ne gute Schätzung raus. Es ist nicht ungewöhnlich, dass Schätzungen um 150% daneben liegen. Um gut zu schätzen braucht man entweder ne gute Datenbasis oder viel Erfahrung.

[1] Mein Prof behauptet, dass Genauigkeiten +- 5% realistisch sind. Nagel mich aber nicht auf die 50 oder 100 fest. Das war nur ne Zahl aus dem hohlen Bauch heraus. Bin kein Statistiker.

[mjustin]

Zitat von r2c2:

Wobei man anmerken muss, dass das so, wie das da verwendet wurde, nicht viel aussagt

Geschenkt

Nach den "Rahmenbedingungen" wurden für das bestehende Projekt bei 500 KLOC nur fünf bis acht MJ benötigt. Wobei nicht klar ist, wie hoch der Anteil Code ist, der durch Wiederverwendung (Bibliotheken) eingebracht wurde, und ob auch Analyse, Design, Dokumentation und Test in der Zeitangabe enthalten sind. Bei einer Neuimplementierung könnte je nach Verfügbarkeit von Bibliotheken der zu erstellende Umfang ebenfalls geringer ausfallen. Und neben dem Code lassen sich auch Systemanalysen und Spezifikationen wiederverwenden.

Wenn doch nur alles so einfach abzuschätzen wäre wie die Bauzeit eines Flughafesn