UD - Logo

Leistungsmessung von Software

Dr. Uwe Doetzkies
erzeugt: 21.04.2013
letzte Änderung: 25.09.2014 
Dr. Uwe Doetzkies

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:
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...
...Eingaben346
...Ausgaben457
...Abfragen346
...Verarbeitung71015

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

Kommentar senden