Wir zeigen auf, wie wir bei der Entwicklung von Reports vorgehen. Es handelt sich um eine Art Checkliste, welche für uns verbindlich ist. Diese soll unseren Qualitätsanspruch dokumentieren.
Hier werden die ersten Fehler gemacht. Fakt ist, je besser die Anforderung definiert wurde, um so besser wird das Resultat sein. Jeder Report sollte auf einem Blatt Papier beginnen. Die Anforderung ist auch Bestandteil der Dokumentation..
Beispiel folgtAuf Basis der Anforderung wird der Report geplant. Hier wird
festgelegt:
- Ziel des Reports
- kompletter, verbindlicher Zeitplan
- Datenquelle (Entwicklung, Test und Produktion)
- alle Parameter
- die Abfrage der Daten
- Design festlegen
- Formatierung
- Konvertierung der Daten
- Automatisierung
- Tests (wer testet wann und was?)
- Verantwortlichkeiten (wer, und für was?)
- Abnahmekriterien festlegen (für Prototyp und fertiges Ergebnis)
- Empfänger des Reports
- Berechtigungen festlegen
- Art der Verteilung der Reports
--> hier ist professionelles Vorgehen gefragt. Es geht hier nicht darum,
einen Roman zu schreiben, die ganannten Punkte sollten aber entsprechend
gewürdigt werden.
- Wenn notwendig: Abstimmung des Zugriffs mit dem Besitzer der Datenquelle
- Einrichten der Verbindung
- Prüfen und Dokumentieren der Aktualität der Quelldaten
- Vorgelagerte Prozesse (wurden die Daten für die Quelle aufbereitet?)
- Test der Qualität der Quelldaten
- Passt die Qualität für die Reports?
- Müssen Prozesse eingerichtet werden, um die Daten eventuell passend aufzubereiten?
(Data Warehouse?)
- Sind eventuell ETL Prozesse (Extract Transform Load) notwendig?
- Entscheidung: Passt die Datenquelle? Können die angeforderten Ziele
erreicht werden?
--> Auch hier gilt: Wenn unsauber gearbeitet wird, darf man kein korrektes
Endergebnis erwarten.
- Aufbau und Ausführen der Abfragen, Aufbau und testen von weiteren Abfragen
zur Überprüfung
- Prüfen der Ergebnisse und Dokumentation
- Abfrage wird freigegeben und darf ab dann in den Reports verwendet werden
- Es wird ein Prototyp erstellt, welcher soweit funktionieren soll, dass wesentliche Teile der Anforderung funktionieren und geprüft werden können.
Beispiel folgt- Die Abnahme ist ein formeller Prozess, bei welcher entschieden wird, ob der Report fertiggestellt wird, um eventuell produktiv gehen kann. Solange die Abnahme verweigert wird, sollte der Report niemals produktiv gehen.
Beispiel folgt- Der Report wird weiterentwickelt bis er getestet werden kann
Beispiel folgt- Vorbereitung der Testphase. Der Entwickler bestätigt die aus seiner Sicht erfolgreiche Fertigstellung des Reports. Dieses Statement sichert die Funktionsweise zu.
Beispiel folgt- Der Test erfolgt nach vorher festgelegten Kriterien und sollte nicht von Entwickler durchgeführt werden. In der Regel sollten die Tests von Personen des anfordernten Fachbereiches durchgeführt und dokumentiert werden. Die Länge der Testphase wurde vorher definiert.
Beispiel folgt- Vor dem GoLive findet eine finale Abnahme als Vorstufe zur Produktion statt. Hier bestätigt ein definierter Personenkreis, daß der Report in Produktion gehen kann. Idealerweise wird hier eine Checkliste abgearbeitet.
Beispiel folgt- Der GoLive ist nun relativ unspektakulär. In der Regel kann ein berechtigter Personenkreis den Report ab diesen Zeitpunkt ausführen.
Beispiel folgt- Dieser Punkt wird meist übersehen. Hier ist sicherzustellen, daß der Report entsprechend der Anforderung ausgeführt wird. Die Ausführung ist zu überwachen. Fehlerverhalten ist zu dokumentieren. Fehlverhalten löst Prozesse aus, welche vorher definiert werden müssen.
Beispiel folgt- Es ist sehr zu empfehlen, den Report permanent auf Korrektheit zu kontrollieren. Auch sollte das Laufzeitverhalten regelmäßig geprüft werden.
Beispiel folgt