ing im BI-Umfeld Business Intelligence seit 1992 als (Senior) Consultant, Business Analyst Projekt Leiter, Teamleiter, BI Architekt Dozent HSLU Leiter TDWI Roundtable ZH seit 2009 Ausbildungen 1992 eidg. Fachausweis als Analytiker-Programmierer 1994 eidg. Fachausweis als Organisator 1998 eidg. Dipl. als Organisator 2004 ITIL Foundation Certificate V2 2005 ITIL Service Manager V2 2006 Prince2 Foundation Certificate 2010 ITIL Service Expert V3 2012 Erwachsenenbildner SVEB1 Projektleiter / BI Architekt T +41 56 200 4240 M +41 76 340 35 16 Herbert.stauffer@axpo.com 1
Inhalt Einführung + Grundlagen Ursachen und Auswirkungen von Fehlern Wirtschaftlichkeit Unterschiede des ens in DWH- und BI-Projekten Vorbereitung Wann sind cases vollständig? strategie betrieb und Organisation Aufbau von umgebungen Umgang mit Defects Abschluss Die menschliche Seite Rollen und Rollenkonflikte Die emotionale Seite des ens Zusammenfassung Hilfsmittel Typische Fehler Hinweise zum Buch EINFÜHRUNG + GRUNDLAGEN Praxisbeispiel, Grundsätze, ing in BI, 2
Kosten Zitate Debugging ist twice as hard as writing the code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian Wilson Kernighan Ich habe noch anderes zu tun als meinen Code zu testen. Software-Entwickler einer Lebensversicherung (nach einer grösseren Produktionsstörung durch ein von ihm ungetestes Modul) Wieso soll ich mir die ganze Mühe für das en machen, wenn ich für die Eröffnung eines Störungstickets bedeutend weniger Zeit benötige. Business-Analystin einer Grossbank Wirtschaftlichkeit von ing Kosten von Fehlern versus Kosten fürs ing Gesamtkosten kosten Fehlerkosten Zeit Gesamtkosten = kosten + Fehlerkosten Ariane 5 Bildherkunft: http://www.capcomespace.net 3
Gegenüberstellung BI- und klassischen Projekte (1/2) Traditional projects start with requirements and end with data. Data Warehousing projects start with data and end with requirements Bill Inmon, in Data Warehousing Projektmethodik Requirements Code Klassisches Projekt Meist traditionelle Modelle (Wasserfall, V-Modell, ) Klar definiert Business Intelligence ETL Speicherung Frontend Iterativ Prototyping Agil, z.b. Scrum Konsistent mit referentieller Integrität, Relational 3NF Heterogene Quellen Multidimensional, temporär Inkonsistent Unscharf definiert Dynamisches SQL oder MDX Gegenüberstellung BI- und klassischen Projekte (2/2) Statisches SQL in Dynamisches Code SQL oder MDX Ausprogrammierte Interaktive Code- Funktionen Generierung Datenmodelle Datenzugriff Daten und daten Schwerpunkte Klassisches Projekt Update einzelner Datensätze Zeilenweise lesend (alle Attribute einer einzelnen Zeile) Nicht vorhanden, entstehen durch Erfassung im system Use cases driven Function based Business Intelligence Projekte ETL Speicherung Frontend Massenupdates (Bulkload) Spaltenweise lesend (einzelne Attribute aus allen Zeilen einer Tabelle In den operativen Source-Systemen vorhanden. Wie können diese genutzt werden? (Security) Neue Daten entstehen in der Regel nicht Data driven Datenqualität Funktionale s Integrations- + Regressionstests bei Beschaffung oder Rel.Wechsel Performance Datenqualität Vollständigkeit und Richtigkeit Performance Integrations- und Regressionstests bei Beschaffung oder Rel.Wechsel Performance 4
ein fehlerhaftes Dashboard A B C D E F 1 Vortag heute Differenzen in % in % gerundet 2 Erdoel 117.74 112.95-4.79-4.06829-4.1 3 Erdgas 16.96 16.84-0.12-0.70755-0.7 4 Kohle 124.3 123.5-0.8-0.64360-0.6 5 CO2 23.17 23.18 0.01 0.04316 0.0 6 SPI 6021.84 6050.83 28.99 0.48141 0.5 =C2-B2 =100/(B2/D2) =RUNDEN(E2;1) Korrekte Formel für Spalte E: =WENN(B2=C2;0;100/(B2/D2) Ursachen von Fehlern über den Verlauf (in %) % 60 50 40 sonstige/unbekannt Tool Spezifikation Datenqualität Implementierungsfehler Datenverständnis 30 20 10 0 beginn ende t 5
PLANUNG UND VORBEREITUNG Definition von geeigneten cases, Fehlerkategorien, datengetriebene s, Dokumentation, Referenzmodell Informationsempfänger (Benutzer und Rollen) Anwender Administrator Informationsbereitstellung Persistente Datenhaltung Data Warehouse Power User Data Steward Techn. Plattform Reporting Analyse Data Mining Portale Dashboard / Cockpits Data Marts Externe Systeme und Prozesse Mobile Planung Plattform Meta Data Log s Data Dictionary Daten Integration Staging Area Data Sources und Schnittstellen <XML> csv strukturiert Semistrukturiert unstrukturiert Master Data ETL Externe Daten 6
cases definiert in drei Schritten Sales- Report META-Layer P_DIM T_DIM BI K_DIM SALES_ Fact S_DIM PGM48TXT PGM4711 KDB CRM Neu Geändert Betroffen Deaktiviert Schritt 1: Übersicht cases definiert in drei Schritten case 2 Sales- Report case 5 P_DIM T_DIM META-Layer case 3 BI case K_DIM 1 SALES_ Fact S_DIM case 4 PGM48TXT PGM4711 KDB CRM Neu Geändert Betroffen Deaktiviert Schritt 1: Übersicht Schritt 2: Farblich kennzeichnen Schritt 3: Definieren von cases 7
Arten von cases nach ISO 9126 / FURPS Functionality Funktionalität Usability Benutzbarkeit Reliability Zuverlässigkeit Performance Effizienz Supportability Änderbarkeit Portability Übertragbarkeit Security FURPS ISO9126 Richtiges Reaktionen in allen Szenarien X X Bedienbarkeit aus Sicht des X X Anwenders Konsistenz und Aussagekraft. X X Robustheit Verhalten unter X X durchschnittlicher und maximaler Last Wartbarkeit X X Sicherheit X Struktur ISO 9126 ISO 9126 Funktionalität Benutzbarkeit Zuverlässigkeit Effizienz Änderbarkeit Übertragbarkeit Tauglichkeit Verständlichkeit Reife Antwortzeiten Analysierbarkeit Anpassbarkeit Erlernbarkeit Fehlertoleranz Ordnungsmäßigkeit Ressourcenverbrauch Modifizierbarkeit Installierbarkeit Interoperabilität Bedienbarkeit Robustheit Stabilität Koexistenz Konformität Attraktivität Wiederherstellbarkeit barkeit Austauschbarkeit Sicherheit 8
ETL Daten- Speicherung Frontend Reports/ Dashboards Plattform/ Infrastruktur Master- und Metadaten Externe Systeme + PRozesse cases in BusinessIntelligence Functionality X (x) X X X X Usability X X X X X X Performance X X X X X X Stress (reliability) X X X X Maintainability X X (x) X X X (supportability/ Portability) Security (x) X X X X X (x) Beschreibung von cases Eindeutige Identifikation, Bezeichnung und Kurzbeschreibung Voraussetzungen/Vorbereitungen Szenario daten Ausgangssituation (Zustand vor ) Schritte zur Durchführung abschluss Ziel Akzeptanzkriterien (erwartetes Ergebnis) Weitere Informationen Referenzierte Dokumente Zuständigkeiten Termine Autor 9
Referenzmodell management Strategie, Policies + phasenplan datenund Szenario- Management Abschlussbericht operations case Definition s durch + Defect log nachführen Lessons learned und Transfer Phasen des prozesses Planung Durchführung Abschluss Referenzmodell Phase Planung Start management manager Erstellen strategie policies grobplanung operations manager operations Analyst Durchführung detailplanung Ablauf Anforderung Umgebung und daten Definition cases 10
Durchführung Dokumentation nach IEEE 829-1998 Projekt Dokumen. Dokumen. der Elemente Elemente plan Design Design Spez. Sepz. fall fall Spez. Spez. ablauf ablauf Spez. Spez. Element Übertragungsbericht log log Vorfall Vorfall Bericht Bericht Schlussbericht Spezifikation bericht Objekte ohne Füllung sind nicht Teil von IEEE829-1998 Datengeriebene fälle Fehlende Quelldaten Unvollständige Quelldaten Alte oder veraltete Quelldaten Veränderungen im Quellsystem Syntaktische Richtigkeit Semantische Fehler in den Quelldaten Datenvolumen und Laufzeiten Berechtigungen auf Dateninhalte (rowlevel security) Starke Schwankungen im Datenvolumen unterschiedliche Laufzeitverhalten Interpretierbarkeit der Daten (Datenverständnis) 11
en mit Checklisten (Beispielsweise Reporte) Priorisierung der Defects Stufe Beschreibung/Auswirkung Beispiel 1 - emergency Sofortige Behebung notwendig, da gesamtes weitere Vorgehen hochgradig gefährdet. Ohne sofortige Behebung muss der betrieb abgebrochen und neu geplant werden. Diese Priorität führt fast zwingend zu einer Terminverschiebung. 2 hoch Produktionsbetrieb nicht sinnvoll. s von anderen Komponenten kann weiter geführt. Ohne Behebung ist ein golive nicht möglich! 3 mittel Produktionsbetrieb mit Einschränkungen möglich. Fehlerhafte Daten haben eine untergeordnete Bedeutung oder es existiert ein Workaround. Behebung ist erwünscht. Trotzdem ist ein golive möglich. 4 tief Der Produktionsbetrieb ist möglich. Die Behebung des Fehlers hat nur einen kosmetischen Charakter. Behebung kann zu irgendwann erfolgen. fehlerhafter Ladeprozess zerstört Daten von anderen Ladeprozessen im Data Mart sämtliche Summen eines Hauptladeprozesses werden falsch oder gar nicht geladen. Das Beschreibungstext wird nicht vollständig geladen, Das heisst, bei überlangen Texten, gehen die letzten paar Stellen verloren. Die Schriftart in der Fusszeile ist kursiv. 12
Referenzmodell Werkzeuge und Hilfsmittel Menschen und Rollen Aktivitäten management Strategie, Policies + phasenplan datenund Szenario- Management Abschlussbericht operations case Definition s durch + Defect log nachführen Lessons learned und Transfer Phasen des prozesses Planung Durchführung Abschluss TESTBETRIEB UND ORGANISATION Unterschiede nach Projektmodell und Architektur, Aufbau und Betrieb der umgebung, Fehlerbehandlung, Reporting 13
Detailierung en in verschiedenen Varianten des Phasenmodells «klassisches» Phasenmodell A D B T G t V-Modell A D1 D2 D.. B T T T t G Phasenmodell mit integriertem en A T D T B T G t A = D = B = T = G = Analyse Design Build go Live and Run definition und -planung durchführung en in nicht-linearen Projektmodellen Iteratives Vorgehen spec goals Scrum Product backlog build review Sprint backlog Sprint Inkrement Evolutionäres Prototyping V3 V2.1 V2.2 V1.1 V1.2 V0 V2.3 definition und -planung durchführung 14
operation management Architekturvarianten mit unterschiedlichen Anzahl Systemen 1-System 2-Systeme 3-Systeme 4-Systeme 5-Systeme D/T/P P P P P D/T T T2 T1 T2 D T1 D1 D2 D Bugfix Release D=Delevopment / T= / P=Production Defectbearbeitung mgmt. HB Steuern der Szenarions daten bereitstellen Überwachen des fortschrittes case log case ing Kommunikation Motivation Defect log Priorisieren der Defects Bundle er Check in Dispatcher Organisation IT Professional Disposition New New Module Package Codefix 15
case Stati Waiting Open Started Passed Failed Ready for retest Defect Stati Open Accepted Analyzed On Work Ready for retest Rejected closed reopen 16
Reporting fortschritt nach Status und Termin Anzahl Fehler nach Auftreten Anzahl offene Fehler Unregelmässige Fehlerverteilung (Fehlerhäufung nach Modul) Fehler mit Status «reopen» 30 25 20 15 10 5 0 2 3 4 5 1 2 7 passed 2 failed 8 2 3 waiting 4 ready for retest 8 2 18 started 12 6 open 7 3 18.6. 19.6. 20.6. 21.6. 15 15 Level 4 12 14 Level 3 12 Level 2 8 11 Level 1 6 5 8 10 6 8 8 6 4 3 1 1 KW1 KW2 KW3 KW4 KW5 Problem: Fehlerverteilung Prio 1 Modul A Modul B Prio 3 Modul E Prio 2 Phase 1: cases für «Rasterfandung» Phase 2: neue cases für «kritische Kandidaten» 17
Manager Business Analyst IT Analyst operations Manager IT Business er IT er Projektleiter Auftraggeber DIE MENSCHLICHE SEITE Rollen und Zuständigkeiten, Rollenkonflikte, die emotionale Seite des ens Rollen und Zuständigkeiten (Beispiel eines RACI Matrix für den prozess) Phase Planung Definition strategie und policies A R R Spezifikation fachliche cases (funktionale s, Usability,...) R A C C I I Spezifikation techn. cases (Performance, Security, ) R A C C I I ablaufplanung (Termine, Szenarions) R C C A C C C I Planung daten R C C A C C C I Phase betrieb Bereitstellen umgebung R A R C Bereitstellen daten R A C Durchführung fachl. cases I C R C A Durchführung IT cases I C R C A Defect-Bearbeitung (inkl. Owner Defectlog) I A R R R Betrieb umgebung (inkl. case log) R A R I Phase Abschluss Review ergebnisse, Schlussbericht mit Empfehlung A C C R C C R R Bereinigen umgebung I A R Lessons Learned und Transfer-Workshop A C C R C C C R I 18
Rollenkonflikt 1 Grundhaltung Auftrag Ziel Erfolg, wenn SW-Entwickler er Konstruktiv, Kreativ, Destruktiv «Schöpferisch» Bereitstellen der im Überprüfen der im Projektauftrag vereinbarten Projektauftrag vereinbarten Lieferobjekte Akzeptanzkriterien will eine neue gute Lösung will beweisen, dass die schaffen Lösung schlecht ist das Programm möglichst viele Fehler abgenommen und möglichst gefunden und fehlerfrei im produktiven (mangelhaftes) Programm Einsatz zurück gewiesen. Rollenkonflikt 2 Grundhaltung Auftrag Ziel Erfolg, wenn Projektleiter manager Konstruktiv in Abwägung mit Destruktiv Zeit und Geld «Qualitätsorientiert» Bereitstellen eines Systems Sicherstellen der Qualität des bis zum Zeitpunkt X unter Systems Einhaltung des Budgets Y Einhaltung Termin und Fehler finden und Beheben Budget lassen termingerechter golive und Fehler gefunden werden Projekt abgenommen 19
rationaler Bereich Emotionaler Bereich Aufgabenorientiert menschenorienteirt zwei Risikotypen in der phase Lange Entwicklungsphase jetzt läuft gar nichts wird das Projekt scheitern? Vertrauensverlust Erste greifbare Objekte sieht toll aus, aber ich hätte da noch eine Verbesserungsidee, Neue Requirements Motive S Sicherheit G Gewinnstreben P Prestige B Bequemlichkeit Reaktion Verhalten Motivation Karrierepläne Jobängste Bonusziele Was steuert die Verhaltensweise? D extrovertiert I Dominant Initiativ Requirements Kosten, Zeitpläne Herr A Motive Frau B Gewissenhaft stetig G introvertiert S Motive und Motivation nach Rudolf A. Schnappauf, «Verkaufspraxis», ISBN 3-478-23733-5 DISG nach F. Gay, «DISG-Persönlichkeitsprofil, ISBN 3-923984-44-8 L. Seiwert & F. Gay, «Das 1x1 der Persönlichkeit, ISBN 978-3936292619 20
ZUSAMMENFASSUNG Beispiele, Fazit, Fragen Session Based ing Planung Einführung 10-15 Session 90 Debriefing 20 Erstellen brief (Charta: zu testende Komponenten, erwarteten Resultate, er) report: Getestete Komponenten Buglist open Issues (untested components, open questions) PROOF Past Results Obstacles Outlook Feelings Dauer 90 120 min. 21
Grundsätze (nach SAQ/ISTQB) Grundsatz 1: en zeigt die Anwesenheit von Fehlern Grundsatz 2: Vollständiges en ist nicht möglich Grundsatz 3: Mit dem en frühzeitig beginnen Grundsatz 4: Häufung von Fehlern Grundsatz 5: Wiederholungen haben keine Wirksamkeit Grundsatz 6: en ist abhängig vom Umfeld Grundsatz 7: Trugschluss: Keine Fehler bedeutet ein brauchbares System http://www.software-tester.ch Checkliste von vermeidbaren Fehlern Fehler 1 Fehler 2 Fehler 3 Fehler 4 Fehler 5 Fehler 6 Fehler 7 Fehler 8 Fehler 9 Fehler 10 Fehler 11 Nur einfache funktionale s en nur als Vorgang im Projektplan Projektplan ohne Fehlerbearbeitung Keine planung über den gesamten Projektverlauf Aufbau umgebung und Bereitstellen von daten wird nicht geplant s werden nur durch Entwickler durchgeführt Ungenügende Vorbereitung der er Keine Fehlerkategorien definiert Fehlerdichte wird ignoriert Kein Transfer am Ende der phase Zu hohe Erwartungen an das en 22
Buch Beschreibung und Vergleich von methoden (V-Modell IEEE 1008, IEEE 1012, ISO 29119, ITIL, Cobit, Conct, FURPS, RUP, etc.) en nach unterschiedlichen Projektmethoden (Phasenmodell, iterative, Prototyping, agile) Bibliothek von cases Toolübersicht für Automatisation, Dokumentation und Logging, Debugger Dokumentenvorlagen Praxisbeispiele Erscheint im August 2013 ca. 300 Seiten, Gebunden ISBN: 978-3-86490-072-3 ca. 69,90 Euro ing can only show the presence of bugs, but not their absence. Edsger Wybe Dijkstra (1930-2002) Good testing works best on good code and good design. An no testing technique can ever change garbage into gold. Dr. Boris Beizer 23
Fragen? Danke fürs zuhören 24