Diskussion:COCOMO

Zeit zum Abstauben?

Puh, dieser Artikel verdient eine Runderneuerung. Zum einen fehlt nach meiner Einschätzung komplett der Praxisbezug (ich kenne keinen Anwender, der "semidetached mode" oder so etwas benutzt). Zum 2. historisch überholt: COCOMO II ist seit 2000 der Standard. Zum 3.: Konkrete Kalibrierungen und Konstanten (z.B. Personenmonat = 152 Stunden) werden als im Modell festgeschrieben dargestellt - was grundsätzlich vollkommen falsch ist.

Wer hilft mit bei einer Neufassung?

--Poensgen (Diskussion) 14:51, 26. Mär. 2015 (CET)

Absoluter Wahnsinn.

Ich meine: Dieses modell hat vielleicht mal Geschichte geschrieben. aber dass es trotzall dem so bescheiden ist???

Und was soll ansich diese Unvollständige angelegenheit hier? Wo sind die Nachteile gelistet?

Hallo Unbekannte(r)! Du darst gerne den Artikel erweitern... --Zubi 22:40, 30. Okt 2005 (CET)

Also, das wird viel benutzt in der Industrie, der Artikel muss nur überarbeitet werden. --WiseWoman 00:08, 4. Sep 2006 (CEST)

Ich finde den Artikel eigentlich nicht schlecht. Er liest sich zwar so, als währe er aus einem Lehrbuch entnommen, aber ansonsten fid ich, dass man ihn so lassen könnte. Was wollt ihr daran eigentlich verändern ? 12:35 11.9.06

Das Modell erscheint mir sehr ungenau

Ich bin Software-Entwickler und habe den Cocomo-Rechner auf eine von mir erstellte Software angewendet, für deren Entwicklung genau 8 Personen-Monate aufgewendet wurden. Die Anzahl der Codezeilen beträgt etwa 64000. Der Cocomo-Rechner hat für dieses Projekt einen Aufwand von 125 Personen-Monaten ermittelt. Selbst wenn ich die Zahl der Codezeilen sehr ungenau ermittelt habe, zwischen 8 und 125 Monaten liegen Welten.

Das liegt vermutlich auch daran, dass man gemäß Cocomo auch den Zyklus Anforderungsdefinition, Grobkonzept, Feinkonzept, Implementation, Test, Integration & Wartung pro _Funktion_ betreibt. 64.000 Zeilen in 8 Monaten lassen darauf schließen, dass diverse Phasen übersprungen wurden. Außerdem: hast du die entsprechenden Parameter auch korrekt eingetragen? ^^

) Thorny 14

15, 19. Okt. 2007 (CEST)

Ich muss auch sagen dass das ganze extrem ungenau ist. Exklusive tests hab ich in ca. 12 "personenmonaten" arbeitszeit etwa 45000 zeilen feinsten c++ code produziert (kommentare, leerzeilen, einzelne klammerzeilen, und präprozessordirektiven abgezogen). Aufgrund von einer diversen menge von anforderungen würde ich das projekt durchaus als komplex bezeichnen (ein rewrite existierender komponenten ist aufgrund der aufrechtzuerhaltenden kompatibilität nie einfach), und auch in anforderung und konzepte ist ne menge arbeit geflossen. Nach cocomo berechnet sich die arbeitszeit also zu (2.4*45)**1.05 = 136,5 für *einfache* projekte. Also auch hier um eine grössenordnung daneben. selbst wenn ich noch extrem grosszügig die zeit dazurechne die andere kollegen im gepräch mit mir verbracht haben kämen wir vielleicht auf 20-24 PM aber niemals auf über 100... Nehmen wir mal an nur 1/4tel der zeit würde mit code schreiben verbracht, dann würde das bedeuten dass gerade einmal 45000/34/20 = 52 zeilen code pro tag erzeugt würden. Bei punch cards oder assembler mag das ja sein, aber nicht bei modernen hochsprachen (nicht signierter Beitrag von 213.61.9.75 (Diskussion) 16:56, 19. Sep. 2011 (CEST))

KDSI

Und wie wird der Wert KDSI geschätzt? Scheint mir die Quadratur des Kreises zu sein? Klar das ein Zusammenhang zwischen KDSI, PM und TDEV aber im nachhinein dies darzulegen ist irgendwie einfach...-- schmitty. 12:34, 30. Dez. 2009 (CET)

-> Die kann man z.B. mit dem Function-Point-Verfahren abschätzen. Natürlich sind das alles nur Schätzwerte, das Ergebnis ist dementsprechend ungenau. Außerdem kann man heutzutage wegen der moderneren Technik mit ca. 1/4 des bei COCOMO geschätzten Aufwandes rechnen. --Augapfel 19:10, 12.03.2010 (CEST)

Abschnitt Kritik

Die Kritik trifft, so wie sie im Artikel formuliert ist, nur auf Neuentwicklungen zu. Sofern eine Analogieschätzung möglich ist, kann man COCOMO (II) durchaus erfolgreich einsetzen. Gerade in frühen Phasen ist es sehr hilfreich, da andere Methoden, insbesondere die direkte Schätzung des Aufwandes durch Experten, wesentlich aufwändiger ist, da alle Annahmen zu dokumentieren sind. (nicht signierter Beitrag von 62.154.222.235 (Diskussion) 11:34, 27. Aug. 2010 (CEST))

Da es weltweit Leute gibt, die CoCoMo erfolgreich einsetzen und zu relativ genauen Kostenschätzungen kommen, ist die Aussage, dass CoCoMo zur Aufwandsschätzung ungeeignet sei, einfach Unsinn. Auch meine eigenen Erfahrungen zeigen, dass CoCoMo durchaus funktioniert. Man muss es natürlich verstanden haben und sinnvoll einsetzen. -- Jochen.Ludewig (Diskussion) 14:04, 8. Okt. 2014 (CEST)

Parameter für die Berechnung der Projektdauer falsch?

ich habe den Eindruck, die Parameter für die Berechnung der Projektdauer sind falsch.

Hier steht:

   * einfach: TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,32}
   * mittel: TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,35}
   * komplex: TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,38}

Es müsste aber heissen:

   * einfach: TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,38}
   * mittel: TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,35}
   * komplex: TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,32}

Die Formeln in Zeile 1 und 3 wurden offenbar vertauscht, die Exponenten stimmen so nicht.

Damit ist auch die Modellrechnung falsch, statt

  * einfach: 32 KDSI -->   91 PM und TDEV 10,6 Monate.
  * mittel:  32 KDSI -->  145 PM und TDEV 14 Monate.
  * komplex: 32 KDSI -->  230 PM und TDEV 20 Monate.

Müsste es heissen:

  * einfach: 32 KDSI -->   91 PM und TDEV 13,90 Monate.
  * mittel:  32 KDSI -->  146 PM und TDEV 14,29 Monate.
  * komplex: 32 KDSI -->  230 PM und TDEV 14,25 Monate.

Nachzulesen z.B. hier:

 http://en.wikipedia.org/wiki/Cocomo
 http://www.software-kompetenz.de/?4774

Die Idee ist dabei, dass komplexe Projekte mehr Aufwand mit sich bringen (also mehr Personenmonate), aber durch Skaleneffekte dieses "mehr an Personemonaten" schneller abgearbeitet werden kann.

Vielleicht kann das jemand nochmal prüfen um Sicher zu gehen?

-- Schaberlaber 11:40, 21. Nov. 2010 (CET)

Die Parameter erscheinen auf den ersten Blick unlogisch, entsprechen jedoch der COCOMO-Methode wie von Boehm veröffentlich. Aus den Aufwands-Formeln ergeben sich für große Projekte (embedded) auch (überproportional) höhere Aufwände. Diese Werte fließen dann in die Formeln für die Dauer ein. Somit ist die Sache stimmig.

Hier ein paar Beispiel-Zahlen von Boehm:

Projektart	Aufwand [MM]	Dauer [M]
Organic (einfach)	5.0	4.6
Semidetached (mittel)	6.5	4.8
Embedded (komplex)	8.3	4.9

Harry Sneed benutzt in seiner Darstellung von COCOMO (Harry M. Sneed, Software-Projektkalkulation, Hanser-Verlag, 2005) allerdings nur für den Organic Mode den Faktor 2,5; für Semidetached verwendet er 2,8 und für Embedded 3,2. Die Exponenten sind jedoch gleich wie bei Boehm.

(nicht signierter Beitrag von RSchaetzle (Diskussion | Beiträge) 15:18, 9. Aug. 2012 (CEST))