CCM - Kennzahlen berechnen

Inhaltsverzeichnis

• Einleitung
• Grundlage
• Berechnung
• Einstellung
• Methode
• Abweichung
• Ergebnis
• Objektliste
• Objekt
• Bearbeitung
• GitHub
• Fazit

In diesem Artikel schauen wir uns die Berechnung der Kennzahlen für das Clean Core Dashboard an, machen einige Beispiele und schauen uns mögliche Abweichungen einmal im Detail an.

 

Einleitung

Für die Berechnung der verschiedenen Kennzahlen stellt bereits das Standard-Dashboard (RISE Methodology) oder das Projekt Kernseife verschiedene Berechnungsmethoden zur Verfügung. Dabei soll aus den Meldungen für ein Objekt ein Technical Debt Score abgeleitet werden, der beschreibt, wie viele technische Schulden in einem Objekt stecken. Damit lässt sich in Zukunft besser ablesen, wenn Veränderungen im System passieren, die nicht auf dem eigentlichen Objekt basieren, sondern kleinere Änderungen innerhalb des Codes sind. Nur ein einzelnes Objekt zu tracken, ist deshalb relativ grob, weil bereits kleine Änderungen in den verwendeten APIs innerhalb des Objektes zwar die Klassifizierung des Objektes nicht ändern, aber trotzdem den Technical Debt Score reduzieren können, sodass man sieht, dass etwas im System passiert. Die gleiche Berechnungsmethode verwenden wir ebenfalls bei uns.

 

Grundlage

Die Grundlage für die Berechnung ist deshalb der ABAP Test Cockpit (ATC) Check: ABAP_CLEAN_CORE_READINESS. Diese Prüfung validiert alle kundeneigenen Objekte und sucht nach entsprechenden APIs, die genutzt werden, oder nach Statements, die nicht mehr genutzt werden sollten, und klassifiziert diese in verschiedene Grade wie Classic APIs, Internal APIs oder APIs, die man nicht mehr nutzen sollte. Das Ergebnis ist eine große Sammlung von Meldungen, die dann gebündelt und klassifiziert werden kann, um so ein Ergebnis auszurechnen und Objekte zu klassifizieren.

 

Berechnung

Wie entsteht also aus den verschiedenen Meldungen eine Kennzahl und wie wird ein Objekt klassifiziert? Schauen wir uns dazu die Details in diesem Kapitel an.

 

Einstellung

Dabei setzen wir auf eine sogenannte Gewichtung und halten uns hier an das Projekt Kernseife, welches bereits Referenzvorschläge macht, um die verschiedenen Level zu klassifizieren. Dabei gehen wir von den Leveln B bis D aus, die wir noch entsprechend berechnen müssen, um eine Kennzahl zu ermitteln. Das Level B ist dabei schon Clean Core, aber noch nicht Cloud-Ready. Deshalb bekommt es zum Beispiel noch einen Punkt, damit es immernoch sichtbar bleibt, aber keinen zu großen Einfluss hat. Das Level C bekommt 3 Punkte und der schwerste Grad, ein Level-D-Finding, bekommt deshalb 10 Punkte. Die verschiedenen Einstellungen der Klassifizierung kannst du über die Business Configuration vornehmen und die Zahlen entsprechend anpassen, wie du sie benötigst. Grundsätzlich kannst du dich aber auch an den Standard für die Gewichtung halten.

 

Methode

Nun zählen wir die verschiedenen Meldungen durch, die wir zu einem Objekt erhalten haben, bilden daraus eine Anzahl und multiplizieren diese mit den entsprechenden Punkten für die Fehlerklassifizierung. Dies ergibt am Ende den Technical Debt Score, die technische Schuld des Objektes innerhalb des Systems. Dabei ergibt sich die Klassifizierung des Objektes vor allem aus der höchsten Meldungsklasse, die für dieses Objekt vorhanden ist.

Schauen wir einmal auf das nachfolgende Beispiel, sehen wir, dass wir zum Beispiel 10 Warnmeldungen haben und eine Fehlermeldung, was insgesamt einen Technical Debt Score von 60 ergibt. Das Objekt ist insgesamt als Level D klassifiziert. Dies ergibt sich aus der Fehlermeldung, auch wenn nur eine vorhanden ist.

 

Schauen wir dazu auf ein zweites Objekt. Dieses Objekt hat insgesamt einen höheren Technical Debt Score als unser erstes Objekt, nämlich 75, ist aber insgesamt nur als Level B klassifiziert. Das liegt daran, dass wir nur 75 Info-Meldungen haben, aber keine Warnungen und keine Fehler.

 

Abweichung

Wo kann so eine Berechnung aber in Zukunft abweichen? Hierfür gibt es verschiedene Gründe, Kennzahlen anders zu berechnen oder Findings anders zu bewerten. Dazu gibt es aktuell verschiedene Prozesse, wie zum Beispiel den Exemption-Prozess im ABAP Test Cockpit, um Findings zu beantragen, diese vielleicht auch dauerhaft freizugeben und mit in die Kalkulation einzubeziehen. Weiterhin kann es Dokumentationen geben, wenn wir Anwendungen umsetzen und entsprechende APIs nutzen, die es im Standard nicht freigegeben gibt, diese aber für unseren Prozess relevant sind. Ein dritter Fall kann aber auch sein, dass wir zum Beispiel in einem Modul arbeiten, wo es keine freigegebenen APIs gibt, hier aber gewisse APIs vorhanden sind, die wir dokumentieren und verwenden wollen, dazu aber keine Findings in unserer Kennzahl sehen möchten. Für solche Abweichungen wird es in Zukunft weitere Kennzahlen im Projekt geben, die neben der Standardkennzahl berechnet werden können, um so den aktuellen Stand im System auszuweisen.

 

Ergebnis

Wie sieht es eigentlich mit der Visualisierung innerhalb des Frameworks aus? Hier haben wir uns zwei verschiedene Beispiele angeschaut: einmal die Objektliste, die uns einen Einstieg in das System gibt, und einmal die Details innerhalb des Objektes, welche die Klassifizierung vorgeben.

 

Objektliste

Beim Einstieg ist die Objektliste vor allem nach dem Technical Debt Score sortiert. Das heißt, Objekte mit der höchsten technischen Schuld stehen ganz oben, ganz unten befinden sich die leichtesten Objekte. Grundsätzlich sind alle Objekt-Provider, also die verschiedenen Systeme, hier gemischt. Du kannst über die Filter Einstellungen vornehmen, um dir zum Beispiel ein spezifisches System anzuschauen. Gleichzeitig wirst du alle Objektklassifizierungen vorfinden – das heißt zum Beispiel in diesem Fall Level C für das erste Objekt, welches die höchsten technischen Schulden hat. Hier kannst du mit weiteren Filtern bestimmen, ob du erst einmal nur Level-D-Objekte angehen möchtest.

 

Objekt

Steigen wir dann etwas tiefer in die Details ein, gehen wir von der Objektliste auf das einzelne Objekt. Hier erhältst du Informationen zu der Anzahl der verschiedenen Meldungen, die zu einem Objekt erzeugt wurden, sowie die Klassifizierung des Objektes. Darunter findest du eine Liste aller Meldungen, die es zu diesem Objekt gibt. Hier kannst du ableiten, ob es gewisse TODOs gibt oder welche APIs zum Beispiel am häufigsten verwendet werden. Diese werden als Referenzobjekte hinter der Meldung mit angezeigt. Dies ist aber abhängig von der Meldung, da nicht jede Meldung auf ein Referenzobjekt verweist.

 

Bearbeitung

Für die Bearbeitung gibt es nun verschiedene Referenzszenarien, welche du je nach Situation verwenden kannst. Du könntest so zum Beispiel anfangen, die Objekte mit dem höchsten Technical Debt Score im System zu bearbeiten. Hier würdest du aber iterativ einzelne Objekte überarbeiten. Die zweite Möglichkeit ist, erst einmal alle Level-D-Objekte anzugehen und vor allem die Level-D-Findings aus dem System zu entfernen. Hierbei handelt es sich um die Best Practice beim Umgang mit den Findings und zur schnellen Erreichung von Clean Core. Eine weitere relativ einfache Möglichkeit ist, alle Findings zu bearbeiten, wo es bereits Nachfolgerobjekte gibt. So kannst du zum Beispiel über die App für die verschiedenen Checks schauen, wie viele Objekte du in einem System hast, die bereits ein Nachfolgerobjekt haben, und diese relativ einfach und normalerweise mit wenig Testaufwand dann auch austauschen. Hier ist die Suche nach der passenden API einfach, allerdings werden hier auch sehr viele Objekte gleichzeitig angepasst.

 

GitHub

Hier findest du das Open Source Projekt und weitere Informationen auf GitHub. Weitere Informationen zur Installation und zur Verwendung des Projekts findest du im Projekt und den verlinkten Ressourcen.

 

Fazit

Die Berechnung der verschiedenen Kennzahlen innerhalb des Clean-Core Dashboards ist relativ einfach umsetzbar, und es kann einfach nachvollzogen werden, wie sich die Kennzahlen zusammensetzen und auch die Klassifizierung entsteht. Diese verschiedenen Kennzahlen sollen die Möglichkeit geben, selbst aktiv zu werden, Objekte anzupassen und auch einen Überblick über die technischen Schulden im System zu haben. So kannst du jeden Monat aufs Neue ableiten, wie sich die technischen Schulden innerhalb des Systems verändert haben, wenn du regelmäßige Messungen durchführst.

 

Weiterführende Infos:
YouTube - CCM Preview