Ist Qualität nachrüstbar? Testen, Dokumentation und Code Qualität von Anfang an

Transkript

1 Ist Qualität nachrüstbar? Testen, Dokumentation und Code Qualität von Anfang an

2 Was ist Qualität? Definition laut EN ISO 9000:2005 Qualität wird definiert als "Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt". Die Qualität gibt damit an, in welchem Maße ein Produkt (Ware oder Dienstleistung) den bestehenden Anforderungen entspricht. 3

3 Wann ist Qualität gut? Nicht immer ist schlechte Qualität sofort erkennbar 4

4 Klassische Ebenen im BI-Projekt ETL Meta Data Warehouse Data Marts Operationale Systeme Data Warehouse Präsentationsebene 5

5 Wann ist Qualität gut? High Level Anforderungen bei BI-Projekten Das "System" muss zuverlässig zur Verfügung stehen Die Datenbereitstellungs-Jobs müssen im Hintergrund laufen und dürfen nicht den normalen Betrieb stören Die bereitgestellten Berichte müssen leicht und intuitiv bedienbar sein Die Berichte müssen schnell zur Verfügung stehen 6

6 Schnell zu guter Qualität kommen (1) Zuverlässiges System Marktvergleich durchführen Sind Serverkomponenten integrierbar in eigene IT- Landschaft? Updatezyklen der Software? Kundensupport? 7

7 Schnell zu guter Qualität kommen (2) Datenbereitstellung Tägliches Laden der Daten aus den Operativen Systemen Man braucht gute Tools und gute Entwickler, die diese bedienen können Ein Ladejob ist relativ schnell entwickelt 8

8 Schnell zu guter Qualität kommen (3) Berichtswesen Berichtsgeneratoren sparen Entwicklungsaufwand Man braucht ein Framework zum Aufrufen der Berichte, so dass kein Aufwand für die Eigenentwicklung einer Benutzeroberfläche anfällt Gute Laufzeit ist darüber hinaus das A und O für die Berichtskonsumenten Ein Bericht ist relativ schnell entwickelt 9

9 Sind schnelle Ergebnisse wirklich gut? 10

10 Qualitätsaspekte der Datenaufbereitung Ein Blick hinter die Kulissen Was passiert, wenn der Ladeprozess einmal ausfällt oder fehlerhaft läuft? Wie geht das System mit ungültigen Datensätzen um? Lassen sich Prozesse datengetrieben entwickeln? Wie aufwändig sind spätere Änderungen am Datenbank- Design? 11

11 Risiko: Fehler bei Datenbereitstellung Was muss berücksichtigt werden? Ladeprozesse müssen wiederholbar sein für bestimmte Zeiträume Man braucht eine solide und passende Metadatenstruktur Rohdaten müssen verlässlich auf Korrektheit geprüft werden Evtl. separate Datenbasis für Fehlerfälle vorsehen (inkl. separatem Berichtswesen) Änderungen am Datenmodell sind immer aufwändig! 12

12 Qualitätsaspekte der Berichterstellung Noch ein Blick hinter die Kulissen Werden gleiche Kennzahlen in unterschiedlichen Berichten unterschiedlich ermittelt? Was tun, wenn die Möglich- keiten des Berichtsgenerators nicht ausreichen? Sind die Berichte fachlich/inhaltlich mit den Empfängern abgestimmt? 13

13 Risiken bei der Berichterstellung Was muss berücksichtigt werden? Kennzahlberechnung vorverlagern und entsprechende Data Marts erstellen Das ist die Voraussetzung dafür, dass Fachanwender eigene Berichte erstellen! Es gibt Systeme, die mit speziellen Business-Schichten arbeiten Eingesetztes System muss Schnittstelle haben, um eigene Berichte zu programmieren Ggf. Einarbeitungsaufwand einplanen Möglichst früh das Feedback der Berichtsempfänger einholen Oft kommen weitere Wünsche hinzu 14

14 Wo wir nun stehen Datenbank + Berichtswesen 15

15 Erst das Design, dann die Arbeit Sammeln der Anforderungen, so präzise wie möglich Planung des Gesamtablaufs und der wesentlichen Prozesse Globale Festlegungen für Fehlerbehandlung, Meldungswesen, Mehrsprachigkeit, Schichtentrennung, Registrieren der Anforderungen und Planung der Umsetzung über Arbeitspakete mit geeignetem Tool Die Realisierung der wesentlichen Anforderungen erfordert meistens die Implementierung von Hilfsprogrammen 16

16 Beim Entwickeln eigener Programme Programmierrichtlinien und ausführliche Dokumentation Programmierrichtlinien erleichtern den Zugang für andere Kollegen Programme müssen sich selbst dokumentieren Auf Knopfdruck soll die komplette Programm-Doku erzeugt werden /* Knackpunkte verständlich im Code dokumentieren */ 17

17 Beim Entwickeln eigener Programme So ist's richtig Programmierrichtlinien erleichtern den Zugang für andere Kollegen /* Knackpunkte verständlich im Code dokumentieren */ Programme müssen sich selbst dokumentieren Auf Knopfdruck soll die komplette Programm-Doku erzeugt werden Wie war das bloß gewesen? 18

18 Dokumentationssystem für Programmcode Von HMS initiierte Adaption Doxygen 19

19 Verwalten von Programmen und Dokumenten Einsatz eines Versionsverwaltungssystems muss obligatorisch sein Check Out Arbeitskopie Commit Beim Einchecken sollen Aktionen dokumentiert werden Repository 20

20 Testen, testen, testen Einsatz eines Testing Frameworks obligatorisch Test-Suiten definieren Auch kleine Einheiten ausreichend testen Wenn möglich, immer autarke Tests generieren Tests sollen sich selbst mit (unveränderlichen) Daten versorgen Testabdeckung überprüfen 21

21 Vorteile des Testens und 'Nachteile' des Testens Vorteile von Testsuiten Tests sind reproduzierbar Man sieht, was getestet ist. Alle anderen Fälle sind somit nicht getestet! Nachteile von Testsuiten Sind selbst Programme und kosten Zeit und Aufwand Ein kleines Hilfsprogramm ist evtl. in 3 Stunden geschrieben Man braucht weitere 2 bis 3 Stunden, um die Testfälle geschrieben zu haben 22

22 Was tun, wenn es kein passendes Testing Framework gibt? HMS entwickelt eines SASUnit 23

23 Testen Die Vollendung Continuous Integration Ein Continuous Integration Server überwacht das Projekt-Repository des Versions-Verwaltungs-Systems und erkennt neu eingecheckte Programme Diese werden abgeholt und anschließend werden sämtliche Testsuites automatisch ausgeführt Im Fehlerfall gibt es eine und man muss kontrollieren, wo man den Fehler übersehen hat Nebenläufigkeiten werden aufgedeckt Entwickler kann in dieser Zeit weiterarbeiten 24

24 Was kann es noch geben? Einige SAS-spezifische Beispiele Nachweis der Programmversionen, die zu einem Ergebnis / Bericht geführt haben HMS Callstack-Framework Mehrsprachigkeit, wo diese eigentlich gar nicht unterstützt wird HMS Message-Framework Parametergesteuerte Überprüfung von Parameter- Werten HMS Parameter-Framework 25

25 Was nicht vergessen werden darf Qualität geht alle an! Die zuvor beschriebenen Aspekte müssen von allen beachtet und gelebt werden Ziel muss sein, das bestmögliche Ergebnis mit der vorhandenen Zeit und dem vorhandenen Budget zu erreichen Zusätzliche, organisatorische Richtlinien müssen eingehalten werden z.b. Zuordnung der Tätigkeiten zu den Arbeitspaketen (und damit zu den Anforderungen) 26

26 Fazit (1) ad-hoc ist gut Qualität ist länger besser Man kann ad-hoc schnell zu guten Ergebnissen kommen Sobald aber Prozesse für andere bereitgestellt werden, müssen andere Maßstäbe angelegt werden Da wesentlich mehr Themenbereiche abzudecken sind, erhöhen sich die Entwicklungsaufwände Es muss von Anfang an geregelt sein, welche Maßnahmen zur Erreichung von guter Qualität zum Einsatz kommen 27

27 Fazit (2) Qualität ist nicht (oder nur sehr teuer) nachrüstbar 28

28 Ist Qualität nachrüstbar? Andreas Bachert Projektleiter / Software-Architekt Andreas.bachert@analytical-software.de HMS Analytical Software GmbH Rohrbacher Str Heidelberg info@analytical-software.de HMS auf XING: 29