Dr. Uwe Doetzkies erzeugt: 21.04.2013 letzte Änderung: 25.09.2014
Ergebnis (Zusammenfassung)
Zu
jedem Anwendungsfall wird ein Betrag ermittelt, der den Aufwand für die
einmalige Ausführung des Anwendungsfalls, ausgedrückt in "Action
Points" angibt. Die Summe der Aufwände aller in einer betrachteten Zeit
ausgeführten Anwendungsfälle dividiert durch die Länge der Zeit ergibt
die (durchschnittliche) Systemleistung während dieser Zeit, gemessen in
"Action Points per Second" (aps). SI-Einheitenvorsätze (kaps, Maps)
sind genauso möglich wie eine auf andere Zeiteinheiten bezogene
Definition (pro Minute, pro Stunde, pro Tag).
Einleitung
Noch
eine Leistungsmessung für Software? Gibt es nicht schon genug:
Instructions per cycle, Instructions per second, FLOPS, Durchsatz,
Antwortzeit, Takt, Latenzzeit u.s.w. (vgl. Wikipedia)? Alle diese
Kennzahlen sind leicht zu messen, es existieren Verfahren und Werkzeuge
zu ihrer Messung, Beobachtung, Protokollierung und Auswertung. Und
dennoch sagen sie nur wenig darüber aus, was das System wirklich
leistet. Woran liegt das? Diese Kenngrößen sind so allgemein
definiert um in allen betrachteten Systemen bestimmt werden zu können.
Das muss so sein, sonst wären die Werte nicht miteinander vergleichbar.
Erst die Vergleichbarkeit ermöglicht es, verschiedene Systeme zu
verschiedenen Zeiten zu bewerten. Gleichzeitig aber beschränkt uns die
Vergleichbarkeit, denn wir können eben nur die Kenngrößen benutzen, die
wir in jedem System messen können. Doch den Anwender interessiert
nicht, wie viele Gleitkommaoperationen seine Anlage in einer Sekunde
durchführen kann, ihn interessiert, wie viele der Aufgaben, die seine
Anlage erhält, in einer Sekunde gelöst werden.
Anwenderorientierte Leistung
Den
Anwender interessiert, wie viele Produktionsdaten abgespeichert werden,
wie viele Aufträge vom System bearbeitet werden, wie viele
Statusanfragen beantwortet werden. Kurz: die Leistungsfähigkeit seines
Systems zeigt sich daran, welche und wie viele Anwendungsfälle (Use
Cases) unter welchen Bedingungen ausgeführt werden. Use Cases per
Minute? Sollte es das sein? Sicher nicht, denn selbst dem Anwender, der
nichts mit Software am Hut hat, müsste klar sein, dass es aufwändigere
und weniger aufwändigere Anwendungsfälle gibt. In der Physik ist die
Leistung der Quotient aus der für einen Prozess benötigten Energie und
der Zeitdauer desselben. Analog kann die Leistung in der Informatik als
Quotient aus der für einen Use Case, eine Operation, eine
Anweisungsfolge benötigten "Energie" und der dafür notwendigen Zeit
betrachtet werden. Das Problem besteht nur darin, dass noch niemand
diese "Energie" gesehen hat, dass Begriffe wie "Komplexität",
"Abstraktionsgrad", "Umfang" ... zwar etwas damit zu tun haben könnten,
aber nur eine (willkürliche) Definition durch eine andere, ebenso
willkürliche ersetzen.
Function Points
Das
hat noch niemand gemacht, und wozu auch. Wirklich? Hat wirklich noch
niemand versucht, einen energetischen Betrag zu einem
informationsverarbeitenden Prozess zu bestimmen? Nein, es gibt einen
Ansatz: Mit der Function Point Analyse
wird versucht, mit Regeln und Erfahrung einem Prozess einen Wert
zuzuordnen, der ein Maß für den zur Implementierung notwendigen Aufwand
ist. Und Aufwand ist eine Form von Energie. Dieses Maß wird in
"Function Points" ausgedrückt, ein Prozess enthält also mehr oder
weniger Function Points als ein anderer - und damit ist der Aufwand für
seine Implementierung größer oder geringer als der für die
Implementierung des anderen. Schwierig ist es, sich etwas Konkretes
unter einem Function Point vorzustellen. Der Entwickler arbeitet an
einer Funktion und irgendwann ist sie fertig, aber sie erforderte
gerade einen Aufwand von 0,4 Function Points. Eine andere Funktion, an
der er wesentlich länger gearbeitet hatte, die aber am Ende auch nicht
mehr Lines Of Code als die erste erforderte, besitzt vielleicht 1,1
Function Points. Und genau dieser Effekt wird durch die Function Points
beschrieben. Aber wenn man im Code nach diesen Punkten sucht, wird man
sie nicht finden. Auch wenn die Methode in der Praxis nicht häufig
angewendet wird, dort, wo sie angewendet wurde, ergaben sich fast immer
gute Schätzungen für den Projektverlauf. Für weitere Informationen zu den Function Points sei auf die üblichen Quellen verwiesen.
Action Points
Zur
Bestimmung der "Energie eines Use Cases" habe ich einfach eine Anleihe
bei der Ermittlung der Function Points genommen. Die Anleihe geht so
weit, dass ich diese Werte "Action Points" nennen möchte. Auch diese
dürften hauptsächlich von der Komplexität der Eingangsdaten, der Art
der Verarbeitung und der Komplexität der Ausgangsdaten abhängen. Für
die in der Function Point Analysis auftretenden Korrekturfaktoren für
besondere Anforderungen (Echtzeit, Sicherheit, etc.) sehe ich hier
keine Notwendigkeit, was erwartet man denn mehr als die Verarbeitung
des Inputs und die Generierung des Outputs? Dennoch soll das Action
Point-Konzept die Möglichkeit von Korrekturfaktoren nicht ausschließen,
denkbar wären solche z.B. für besondere Anforderungen an den
auszuführenden Use Case wie Nachvollziehbarkeit oder Unterbrechbarkeit.
Für den Anfang sollen die Action Points jedoch lediglich auf der
anwenderbezogenen(!) Analyse von Input, Output und Prozess basieren.
Daraus ergibt sich, dass die Action Point schon früh, sehr früh in der
Systementwicklung bestimmt werden können: sobald ein Anwendungsfall
definiert wurde lassen sich die für seine Ausführung benötigten Action
Points berechnen. Damit wird eine messbare Leistungsdefinition bereits
zum Bestandteil der Anforderungsanalyse. Wenn das Speichern des
Zustandes einer Werkstücks 12 Action Points erfordert, dann lässt sich
die Anforderung, pro Minute 500 Werkstückzustände speichern zu können
mit einer Leistung von 6.000 appm (Action Points per Minute)
definieren. Für sich allein betrachtet, bringt diese Aussage wenig
- ihre Kraft entfaltet sie erst wenn sie gemeinsam mit anderen
Anwendungsfällen im System betrachtet wird: Testszenarien können so
bewertet und selbst die aktuelle Leistung eines produktiven
Systems kann so quantifiziert werden. Und das aus der Sicht des
Anwenders ("sooo kompliziert kann das doch nicht sein") und nicht aus
der Entwicklersicht.
Bestimmung der Action Points
Nun
wird es spannend: Wie bestimmt man zu einem gegebenen Anwendungsfall
die Anzahl der Action Points? Der Anwendungsfall selbst ist in der
Regel entweder als Use Case Diagramm gegeben oder als verbale
Beschreibung oder in einer Mischform von beidem. Wichtig ist vor allem,
dass die Anwendungsfälle aus der Sicht des Anwenders beschrieben
wurden, nicht aus der des Modellierers oder des Programmierers. Auf
dieser Ebene sollten sie die häufigsten Anwendungsfälle möglichst
vollständig beschreiben. Zu einem gegebenen Anwendungsfall wird nun
beschrieben, welcher Art dieser Anwendungsfall ist und welche
Informationen durch ihn beeinflusst werden. Arten von Anwendungsfällen sind:
Eingabe
- durch den Anwendungsfall kommen Informationen ins System, z.B.
Auslesen von Sensoren, Eingabe durch Fachabteilungen oder über
Web-Seiten.
Ausgabe
- durch den Anwendungsfall werden Informationen berechnet und
ausgegeben, z.B. Steuerung von Motoren, Übertragen von
Zusammenfassungen, Konvertierung in externe Formate.
Abfrage
- durch den Anwendungsfall werden Informationen ohne vorherige
Verarbeitung ausgegeben, z.B. Anzeige von Tabellen, Ausgabe
vordefinierter Texte. Abfragen sind vereinfachte Ausgaben.
Verarbeitung
- interne Informationen werden verarbeitet und gespeichert, z.B.
Auswertung von Statusinformationen, Konvertierungen in interne Formate,
Fortschreiben über die Zeit. Die Verarbeitung stellt eine Kombination
von interner Ein- und Ausgabe dar.
Zusätzlich
wird für jeden Anwendungsfall die Komplexität eingeschätzt, wie
sie sich aus Anwendersicht darstellt. Dabei werden lediglich drei
Stufen unterschieden: trivial (einfach) wenn Informationen im
wesentlichen unbesehen übernommen werden können, normal wenn einfache
übliche Prüfungen und Manipulationen mit den Informationen durchgeführt
werden müssen (in der Regel mit jeweils zwei Informationen), und
komplex wenn die Prüfungen und/oder Manipulationen mehr als zwei
Informationen berücksichtigen müssen.
Action Points für...
...triviale...
...normale...
...komplexe...
...Eingaben
3
4
6
...Ausgaben
4
5
7
...Abfragen
3
4
6
...Verarbeitung
7
10
15
In
der Regel lässt sich für einen Anwendungsfall ("Auftrag erfassen")
eindeutig die Information angeben, mit der der Anwendungsfall arbeitet
("Auftrag") und die Art desselben feststellen ("erfassen" = Eingabe).
Es sind jedoch, gerade bei den verarbeitenden Prozessen Anwendungsfälle
denkbar, die mit mehr als einer Information arbeiten. So arbeitet
"Auftrag disponieren" mit der aktuellen Auftragsliste und dem
gegenwärtigen Lagerbestand. Diese Anwendungsfälle sind oft dadurch
gekennzeichnet, dass der Anwender bereits ein Bild davon hat, wie diese
vom System behandelt werden müssen. (Anm.: Man muss sich nicht darüber
streiten, ob solche Use Cases in elementarere Use Cases zerlegt werden
müssen, man kann dies machen, aber auch lassen - es sollte auf das
Gesamtergebnis keinen wesentlichen Einfluss haben). Für diese
Anwendungsfälle müssen dann natürlich alle Informationen berücksichtigt
werden.
Ergebnis
Zu
jedem Anwendungsfall wird ein Betrag ermittelt, der den Aufwand für die
einmalige Ausführung des Anwendungsfalls, ausgedrückt in "Action
Points" angibt. Die Summe der Aufwände aller in einer betrachteten Zeit
ausgeführten Anwendungsfälle dividiert durch die Länge der Zeit ergibt
die (durchschnittliche) Systemleistung während dieser Zeit, gemessen in
"Action Points per Second" (aps). SI-Einheitenvorsätze (kaps, Maps)
sind genauso möglich wie eine auf andere Zeiteinheiten bezogene
Definition (pro Minute, pro Stunde, pro Tag).
Ausblick
In
einem weiteren Beitrag zeige ich, wie man diese Messungen praktisch
definiert und die Werte im laufenden Betrieb der Software-Systeme
bestimmt.
Quellen
B. Poensgen, B. Bock: Function-Point-Analyse. dpunkt.verlag Heidelberg 2005