Was war das Problem des Kunden?

Das ursprüngliche Problem war die hohe Anzahl der unterschiedlichen Datenquellen sowie die unterschiedlichen Formate, aus denen sich die Grundlage der täglichen Arbeit zusammensetzte. Im Laufe der letzten Jahre sind außerdem nicht nur die Daten und deren Strukturen, sondern auch die internen, manuellen Workflows historisch gewachsen.

Die Herausforderung bestand also darin, dass

• die Daten analysiert und neu strukturiert werden mussten
• die manuellen Workflows analysiert und von unseren Mitarbeitern verstanden werden mussten
• die manuellen Workflows neu konzipiert und programmiert werden mussten
• die Qualitätssicherung zu jedem Zeitpunkt gewährleistet werden musste, weil der operative Betrieb weiterlaufen musste

Eine zusätzlich Herausforderung bestand außerdem im Management des Projekts u.a. aufgrund der örtlichen Distanz zwischen dem Kunden in Arnstadt [Thüringen] und parsQube in Karlsruhe [Baden-Württemberg]. Dies führte dazu, dass sowohl der Austausch der Anforderungen, die Entwicklung als auch die Abnahme der Meilensteine und die Abnahme der fertigen Releases neu konzipiert und umgesetzt werden mussten.

Warum wurde parsQube gefragt?

Eine der Hauptdatenquellen war im Allgemeinen im XML-Format vorliegend. Im Speziellen handelte es sich um das Datenbanksystem eXist-db, das im Jahre 2000 von Wolfgang Meier entwickelt wurde. Neben der eXist Solutions GmbH in Lenzkirch, die Support und Services für exist-db anbieten, zählt die parsQube GmbH mit ihrer langjährigen Erfahrung im Umgang mit eXist-db zu den wenigen eXist-db Experten in Deutschland.

Unser Ansprechpartner ist also bei der Recherche sehr schnell auf uns aufmerksam geworden, da wir uns seit 2013 intensiv mit der Datenanalyse auseinandersetzen. Darüber hinaus können wir Referenzen über zahlreiche XML-Großprojekte vorweisen (hier geht es zu unseren Referenzen).

Wie sind wir methodisch vorgegangen?

Kommunikation

Unsere Kommunikation mit dem Kunden stützte sich auf drei Säulen:

• Persönliches Treffen beim Kunden vor Ort zum gemeinsamen Kick-Off
• Regelmäßige telefonische Abstimmungen zwischen Kunden und Entwicklerteam
• Gemeinsames Ticketsystem u.a. zur Verwaltung der Anforderungen sowie zur Protokollierung der telefonschen Abstimmungen und getroffenen Commitments

Planung und Vorgehen

Gemeinsam mit dem Kunden haben wir uns auf ein iteratives Vorgehen geinigt. Im Folgenden werden die einzelnen Schritte dieses Vorgehens genauer beleuchtet:

Ausgangspunkt war eine vom Kunden vorgelegte schriftliche Spezifikation in Form einer pdf, die alle funktionalen und nicht funktionalen Anforderungen des gewünschten Produkts beschrieb sowie eine Priorisierung ebendieser Anforderungen. Priorisierung und Spezifikation bildeten die Grundlage für unsere internen Planungsrunden.

In den Planungsrunden unserer Entwickler wurden die jeweils vom Kunden gewünschten Anforderungen gesichtet und ausführlich besprochen. Dabei konnten bereits erste Ideen für die Umsetzung ausgetauscht, potenzielle Herausforderungen identifizert sowie mögliche Unklarheiten in der Spezifikation transparent gemacht werden. Anschließend wurden die Anforderungen als Tickets in das Ticketsystem eingepflegt und einer sogenannten Zielversion (ein digitaler Backlog, der alle gewünschten Anforderungen des Kunden enthielt) zugeordnet. Zu guter letzt wurde eine Schätzung des Aufwands vorgenommen.

Im nächsten Schritt vereinbarten wir einen telefonischen Termin mit unserem Ansprechpartner auf Kundenseite. Über das gemeinsame Ticketsystem wurden die erstellten Tickets gesichtet und ggf. in der Planungsrunde identifizierte Unklarheiten geklärt. Des Weiteren wurde an dieser Stelle gelegentlich auch eine weitere Detaillierung der Tickets vorgenommen in Form von (weiteren) Akzeptanzkriterien, Screenshots oder präziseren Formulierungen. Die gemeinsame Abstimmung mit dem Kunden schuf somit die perfekte Basis für die anschließende Umsetzung der bestellten Tickets. Um absolute Transparenz zu gewährleisten wurden außerdem besprochene Punkte, Ergebnisse, Commitments und vereinbarte Termine in einem Wiki in unserem Ticketssystem protokolliert.

Nachdem die Lieferung der Zielversion erfolgt war, wurde ein telefonischer Termin zur Abnahme vereinbart. In diesem Rahmen konnte der Kunde uns live Feedback geben. Anschließend begann der Prozess erneut: Mit der Spezifikation und einer Priorisierung. Dieses Vorgehen ermöglichte eine flexible und genaue Umsetzung der Kundenanforderungen.

Was war die Idee/das Konzept?

Die erste Herausforderung bestand darin:

• die hohe Anzahl an Datenquellen und
• die heterogene „Datenlandschaft“ (Datenformate)

unter Kontrolle zu bekommen. Die Idee war die Erschaffung einer Art „Daten-Drehscheibe“, welche sämtliche Daten in ein einheitliches Datenformat überführt. Da auf Kundenseite bereits mit einer XML-Datenbank gearbeitet wurde, lag die Idee sehr nah, ein XML-Datenformat als Basis zu wählen.

Bei der Überführung diverser Datenformate in das einheitliche Datenformat (Datentransformationen mit XQuery und XSLT) haben wir neue Prozessschritte eingeführt, die während der Datentransformation eine Qualitätssicherung mithilfe von Schema & Schematron der Gesamtdaten vorgenommen haben. Hierbei wurde auf mögliche Redundanz der Daten, aber auch auf die Plausibilität der Gesamtdaten geachtet.

Wie wurde die Idee/das Konzept umgesetzt?

Der Datenimporter wurde in Python geschrieben. Außerdem wurde eine XML-Datenbank (eXist-db) und eine SQL-Datenbank (Maria-db) im Projekt eingesetzt. Das Backend der Analytik-Anwendung wurde in XQuery programmiert und das Frontend mit HTML und TypeScript gebaut.

Bei weiteren Fragen zur technischen Umsetzung können Sie sich gerne an uns wenden. Dabei erkären wir keine Geheimnisse des Kunden, sondern werden Ihre Fragen in Bezug auf den Einsatz der Technologien beantworten. Rufen Sie uns gerne an.

Hier geht es zu unserer Team-Seite.

zurück