Metriken zur Schätzung des Umfangs von Software

Veröffentlicht auf 7. Juni 2010

Den Umfang einer Software zu schätzen ist außerst schwer. Es ist wie im Chemielabor, wenn man mal wieder zwei neue Substanzen mischt, man weiß nie was passiert, es sei denn man hat vielleicht schon mal ähnliche Substanzen miteinander gemischt.

 

Folgende Methoden werden gerne in der Softwareentwicklung eingesetzt:

 

* Lines of Code (LOC)

Bottom-Up Schätzung, pessimistisch/realistisch/optimistisch. Eine Konvertierung zwischen einzelnen Programmiersprachen und zu anderen Metriken ist möglich. Einfach anzuwenden für technische Anwender, aber sehr ungenau. Zudem kann der Projektfortschritt daran nur sehr schlecht gemessen werden, die Qualität von Software (z.B. Defects pro LOC) sollte gemessen werden, nicht das Volumen.
http://de.wikipedia.org/wiki/Lines_of_Code


* Functions Points

Berechnungsformeln für End-User Business Functions. Bewertet die Komplexität von In-/Output, Datenverarbeitung, Strukturen und Interfaces. Einfach anzuwenden, auch für nichttechnische Anwender. Projektfortschritt kann halbwegs sinnvoll gemessen werden.
http://de.wikipedia.org/wiki/Function-Point-Verfahren
http://www.devdaily.com/FunctionPoints/


* Features Points

Erweiterung der Function Points für hardwarenahe oder Echtzeit Systeme. Bewertung der Komplexität von Alghorithmen.


* Anzahl Entitäten, Zustände, Objekte in Entity Relationship, Data Flow oder Class Diagrams

Eine unersetzliche Grundlage ist aber immer noch eine eigene Projektdatenbank mit Erfahrungswerten für bestimmte Metriken, um halbwegs realistische Annahmen machen zu können. Dies gilt ebenfalls für bekannte Methoden wie z.B. das COCOMO-Modell, die unerfahrenen Anwendern relativ ungenaue Ergebnisse liefern, die zum Teil sehr weit voneinander abweichen können.

Beispielwerte für eine mögliche Konvertierung (Sprache * Faktor = Anzahl Source LOC in Assembler oder Durchschnittliche SLOC pro Function Point):
Sprache            SLOC        FP
Assembler        1                320
C                         2,5            150
BASIC                5                  64
C++/Java           6                  53
DB Sprachen    8                 40
Unix/Perl          15                 21
C#                     16                 20       

 

Geschrieben von Robert Bullinger

Veröffentlicht in #Projektmanagement

Repost0
Um über die neuesten Artikel informiert zu werden, abonnieren:
Kommentiere diesen Post
S
<br /> <br /> Hallo,<br /> <br /> <br /> der Umfang der Software (Source Code) ist meiner Meinung nach eher zweitrangig. Viel mehr muss abgeschätzt werden wie lange die Entwicklung und das Testen dauern. Für eine homogene<br /> Projektlandschaft ist eine Projektdatenbank wirklich hilfreich. Bei heterogener Projektlandschaft muss es klare Bewertungsfaktoren geben. Da ist die Function Point Methode sehr hilfreich.<br /> <br /> <br /> <br />
Antworten
R
<br /> <br /> Ich persönlich tendiere auch eher zu FP.<br /> <br /> <br /> <br />
S
<br /> <br /> Interessanter Artikel. Vor allem ist dein Niveau sehr hoch, man kann immer was lernen. :)<br /> <br /> <br /> <br />
Antworten
R
<br /> <br /> Hallo Stefan,<br /> <br /> <br /> vielen Dank für das Kompliment. Ich bemühe mich :)<br /> <br /> <br /> <br />