Hochschule Wismar

Volltext

(1)Hochschule Wismar Fakultät für Wirtschaftswissenschaften. Testen von Data Warehouse und Business Intelligence Systemen. Thesis zur Erlangung des Grades Master of Science (M.Sc.). Verfasser: Renke Hegeler Studiengang Wirtschaftsinformatik Betreuer: Prof. Dr. Jürgen Cleve Prof. Dr. Jan Helmke. Hannover, 20. Februar 2012.

(2) Abstract. Abstract In der Literatur finden sich viele Abhandlungen zu den Themenbereichen „Data Warehouse und Business Intelligence“ sowie „Testen von Software“. Die Kombination aus beiden Themen wurde bisher jedoch nur sehr spärlich betrachtet. Ralph Kimball, einer der meist zitierten Autoren zum Thema „Data Warehouse“, beschreibt in seinen Büchern auf hunderten Seiten seine Modelle und Konzepte für ein Data Warehouse, während das Testen nur am Rande erwähnt wird. Diese Master-Thesis widmet sich daher explizit dem Testen von Data Warehouse und Business Intelligence Systemen. Dabei wird analysiert, wie sich diese Systeme von klassischer Software unterscheiden und anhand von Beispielen aus der Praxis gezeigt, welche Besonderheiten zu beachten sind und was für Fehlersituationen bei der Entwicklung auftreten können. Auf Basis der etablierten Softwareprüftechniken wird dann für die jeweiligen Situationen untersucht, welche Techniken sich anwenden lassen. Auch im Betrieb gibt es oftmals Komplikationen und es treten Fehlersituationen auf. Deshalb werden Methoden beschrieben, wie mit diesen alltäglichen Problemstellungen umgegangen werden kann. Da effektive Tests nur mithilfe von Testwerkzeugen durchgeführt werden können, werden zusätzlich einige Werkzeuge vorgestellt..

(3) Inhaltsverzeichnis. Inhaltsverzeichnis 1. Einleitung ............................................................................................................... 1 1.1. Vorstellung des Themas und der Zielsetzung ................................................... 2 1.2. Aufbau der Arbeit .............................................................................................. 2 1.3. Verwandte Arbeiten .......................................................................................... 3 2. Umfeld der Arbeit .................................................................................................. 5 2.1. Data Warehouse und Business Intelligence Systeme....................................... 6 2.1.1. Definitionen ................................................................................................ 6 2.1.2. Ziele und Notwendigkeiten ......................................................................... 8 2.1.3. Architektur und Komponenten .................................................................. 10 2.1.3.1 Quellsysteme ...................................................................................... 10 2.1.3.2 Analysesysteme.................................................................................. 11 2.1.3.3 OLAP-Systeme ................................................................................... 13 2.1.3.4 Data Warehouse ................................................................................. 16 2.1.3.5 Datenintegration ................................................................................. 17 2.1.3.6 Automatisierungssysteme................................................................... 21 2.1.4. Business Intelligence System Big Picture ................................................ 22 2.2. Testen von Software ....................................................................................... 23 2.2.1. Softwareentwicklungsprozess .................................................................. 24 2.2.2. Dynamische Prüftechniken....................................................................... 26 2.2.2.1 Funktionsorientierte Tests .................................................................. 27 2.2.2.2 Strukturorientierte Tests ..................................................................... 30 2.2.2.3 Diversifizierende Tests ....................................................................... 33 2.2.3. Statische Prüftechniken............................................................................ 33 2.2.3.1 Stilanalyse .......................................................................................... 33 2.2.3.2 Visuelle Hilfsmittel............................................................................... 34 2.2.3.3 Anomalieanalyse ................................................................................ 35 2.2.3.4 Slicing ................................................................................................. 37 2.2.3.5 Review ................................................................................................ 37 2.2.3.6 Metriken .............................................................................................. 37 2.2.3.7 Verifizierende Analysen ...................................................................... 38 2.2.4. Testen von Datenbanken ......................................................................... 38 2.2.5. Testen nichtfunktionaler Anforderungen................................................... 39.

(4) Inhaltsverzeichnis. 3. Testen während der Entwicklung ...................................................................... 41 3.1. Allgemeine Besonderheiten bei der Entwicklung ............................................ 42 3.1.1. Softwareentwicklungsprozess .................................................................. 42 3.1.2. Tätigkeiten eines Entwicklers ................................................................... 43 3.1.3. Unterschiede beim Testen ....................................................................... 44 3.2. Multidimensionale Modellierung...................................................................... 44 3.2.1. Besonderheiten der multidimensionalen Modellierung ............................. 44 3.2.2. Prüftechniken für die multidimensionale Modellierung ............................. 45 3.3. Datenintegration ............................................................................................. 50 3.3.1. Besonderheiten der Datenintegration ....................................................... 50 3.3.1.1 Funktionale Besonderheiten der Datenintegration .............................. 50 3.3.1.2 Nichtfunktionale Besonderheiten der Datenintegration ....................... 54 3.3.2. Prüftechniken für die Datenintegration ..................................................... 55 3.3.2.1 Funktionale Prüftechniken für die Datenintegration ............................ 55 3.3.2.2 Nichtfunktionale Prüftechniken für die Datenintegration ..................... 65 3.4. Data Warehouse ............................................................................................. 66 3.4.1. Besonderheiten eines Data Warehouses ................................................. 66 3.4.1.1 Funktionale Besonderheiten eines Data Warehouses ........................ 66 3.4.1.2 Nichtfunktionale Besonderheiten eines Data Warehouses ................. 67 3.4.2. Prüftechniken für ein Data Warehouse..................................................... 68 3.4.2.1 Funktionale Prüftechniken für ein Data Warehouse............................ 68 3.4.2.2 Nichtfunktionale Prüftechniken für ein Data Warehouse..................... 70 3.5. OLAP-System ................................................................................................. 71 3.5.1. Besonderheiten eines OLAP-Systems ..................................................... 71 3.5.1.1 Funktionale Besonderheiten eines OLAP-Systems ............................ 71 3.5.1.2 Nichtfunktionale Besonderheiten eines OLAP-Systems ..................... 74 3.5.2. Prüftechniken für ein OLAP-System ......................................................... 75 3.5.2.1 Funktionale Prüftechniken für ein OLAP-System ................................ 75 3.5.2.2 Nichtfunktionale Prüftechniken für ein OLAP-System ......................... 81 3.6. Reporting Front-End ....................................................................................... 82 3.6.1. Besonderheiten eines Reporting Front-Ends ........................................... 83 3.6.1.1 Nichtfunktionale Besonderheiten eines Reporting Front-Ends ........... 83 3.6.2. Prüftechniken für ein Reporting Front-End ............................................... 85 3.6.2.1 Nichtfunktionale Prüftechniken für ein Reporting Front-End ............... 85.

(5) Inhaltsverzeichnis. 3.7. Automatisierungssystem ................................................................................. 87 3.7.1. Besonderheiten eines Automatisierungssystems ..................................... 88 3.7.1.1 Funktionale Besonderheiten eines Automatisierungssystems ............ 88 3.7.1.2 Nichtfunktionale Besonderheiten eines Automatisierungssystems ..... 89 3.7.2. Prüftechniken für ein Automatisierungssystem ........................................ 89 3.7.2.1 Funktionale Prüftechniken für ein Automatisierungssystem ............... 89 3.7.2.2 Nichtfunktionale Prüftechniken für ein Automatisierungssystem ........ 90 3.8. Bewertung....................................................................................................... 91 4. Testen während des Betriebes........................................................................... 97 4.1. Tätigkeiten während des Betriebes................................................................. 98 4.1.1. Betrieb ...................................................................................................... 98 4.1.2. Anpassungen ........................................................................................... 98 4.2. Fehlersituationen während des Betriebes ....................................................... 99 4.2.1. Falsche Datenlieferungen ........................................................................ 99 4.2.2. Unachtsamkeit ....................................................................................... 101 4.2.3. Infrastruktur ............................................................................................ 101 4.3. Korrektheit der Daten .................................................................................... 102 4.3.1. Validierung von Kennzahlen................................................................... 103 4.3.2. Quality Gates ......................................................................................... 104 5. Testinfrastruktur................................................................................................ 106 5.1. Testwerkzeuge ............................................................................................. 107 5.2. Testsystem, Testteam und Testdaten ........................................................... 112 6. Konklusion ......................................................................................................... 114 Anhang A: Business Intelligence System in der Praxis..................................... 116 Anhang B: ADAPT-Notation ................................................................................. 117 Abkürzungsverzeichnis ............................................................................................. i Abbildungsverzeichnis ............................................................................................. ii Tabellenverzeichnis ................................................................................................. iv Listingverzeichnis ..................................................................................................... v Formelverzeichnis .................................................................................................... vi Literaturverzeichnis ................................................................................................ vii.

(6) Kapitel 1 - Einleitung 1. Einleitung. 1. Kapitel 1. Einleitung. In diesem Kapitel werden das Thema und die Zielsetzung der Master-Thesis vorgestellt, ein Überblick zu verwandten Arbeiten gegeben sowie die Vorgehensweise und der Aufbau der Thesis beschrieben.. Übersicht 1. Einleitung ............................................................................................................... 1 1.1. Vorstellung des Themas und der Zielsetzung ................................................... 2 1.2. Aufbau der Arbeit .............................................................................................. 2 1.3. Verwandte Arbeiten .......................................................................................... 3.

(7) Kapitel 1 - Einleitung. 1.1. Vorstellung des Themas und der Zielsetzung Die Literaturrecherche zu den Stichpunkten „Data Warehouse System + Testen“ oder „Business Intelligence System + Testen“ liefert eine geringe Anzahl an direkten Treffern. Die Suche nach den einzelnen Stichpunkten hingegen zu einer erheblich größeren Trefferanzahl1. Es gibt entweder Fachliteratur entweder zu dem Themenbereich „Data Warehouse“ / „Business Intelligence“ oder für den Themenbereich „Testen von Software“. Zu der Kombination der beiden Themenbereiche gibt es keine spezielle Literatur. Es lassen sich lediglich einige wissenschaftliche Arbeiten sowie kurze Abhandlungen zu der Thematik finden, von denen einige im Abschnitt 1.3 näher erläutert werden. Diese Arbeit widmet sich explizit dem Testen von Data Warehouse und Business Intelligence Systemen. Dabei werden die Besonderheiten und typische Fehlersituationen dieser Systeme beschrieben und darauf basierend analysiert, was demnach getestet werden muss. Da es sich bei Data Warehouse und Business Intelligence Systemen um Software handelt, sollen die etablierten Prüftechniken auf ihre Anwendbarkeit für Data Warehouse und Business Intelligence Systeme untersucht werden. Um den Rahmen dieser Arbeit in Grenzen zu halten, werden die Teilbereiche „Data Mining“ und „formaler Beweis“ nur genannt und nicht weiter vertieft.. 1.2. Aufbau der Arbeit Diese Arbeit ist in fünf Kapitel eingeteilt. Im ersten Kapitel werden einleitend das Thema vorgestellt sowie die Rahmenbedingungen festgelegt. Das zweite Kapitel be-. 1. http://scholar.google.de/scholar?hl=de&q=data+warehouse+system+testing - 66.000 Treffer http://scholar.google.de/scholar?hl=de&q=business+intelligence+system+testing - 619.000 Treffer http://scholar.google.de/scholar?hl=de&q=data+warehouse+system - 238.000 Treffer http://scholar.google.de/scholar?hl=de&q=business+intelligence+system - 1.840.000 Treffer http://scholar.google.de/scholar?hl=de&q=software+testing - 3.230.000 Treffer (Abgerufen 12.12.2011).

(8) Kapitel 1 - Einleitung. schreibt die für das Thema wichtigen theoretischen Grundlagen, also die Bereiche Data Warehouse und Business Intelligence Systeme, und das Testen von Software. Auf den Grundlagen aufbauend wird im dritten Kapitel analysiert, welche der Prüftechniken bei der Entwicklung von Data Warehouse und Business Intelligence Systemen anwendbar sind. Dazu werden zunächst die Unterschiede zu der klassischen Softwareentwicklung gezeigt. Anhand von typischen Fehlersituationen aus der Praxis wird dann anhand von Beispielen gezeigt, welche der etablierten Softwareprüftechniken für die beschriebenen Fehlersituationen verwendet werden können. Abschließend folgt eine Bewertung, inwieweit die vorgestellten Prüftechniken praxistauglich sind. Im vierten Kapitel wird beschrieben, welche Fehlersituationen im alltäglichen Betrieb eines Data Warehouse uns Business Intelligence Systems auftreten können und mit welchen Techniken den Fehlern entgegengewirkt werden kann. Das fünfte Kapitel behandelt den Bereich Testinfrastruktur und stellt einige verfügbare Testwerkzeuge vor. Die Arbeit schließt im sechsten Kapitel mit einer Konklusion ab.. 1.3. Verwandte Arbeiten Die „Literatur-Klassiker“ zum Thema Business Intelligence und Data Warehouse Systeme von Inmon [Inm05] sowie Kimball et al. [Kim02 und Kim04] beschreiben Techniken und Vorgehensmodelle für den Aufbau solcher Systeme. Kimball et al. erwähnen das Testen dabei nur am Rande. Innerhalb der Kapitel finden sich gelegentlich Aussagen nach dem Motto „ist zu testen“. Inmon hingegen schreibt sogar: „Testing in the data warehouse is not the same level of importance as in the operational transaction environment. But occasionally there is a need for testing, especially when new types of data are being loaded and when there are large volumes of data.“ [Inm05, S. 481] Rainardi [Rai08] ist einer der wenigen, der dem Testen in seinem Buch ein eigenes Kapitel widmet. Er beschränkt sich allerdings darauf, was zu testen ist und geht nicht auf Prüftechniken ein: „I will not discuss [...] testing methodology. [...] Instead, I will focus on the content of those tests specific to data warehousing.“ [Rai08, S. 477].

(9) Kapitel 1 - Einleitung. Er unterscheidet dabei folgende fünf Testbereiche: „ETL testing: In the ETL testing stage, you make sure that appropriate changes in the source system are captured properly and propagated correctly into the data warehouse. [...] Functional testing: In the functional testing stage, you make sure all the business requirements are fulfilled. Performance testing: In the performance testing stage, you verify that the data warehouse can handle the required load and volume. Security testing: In the security testing stage, you make sure only the users who should be able to access the resources can actually access them. User acceptance testing: In the user acceptance testing stage, the end users use the data warehouse system to verify the usability. End-to-end testing: In the end-to-end testing stage, you let the system run for a few days to simulate production situations.“ [Rai08, S. 477] Einige weitere Abhandlungen zum Testen finden sich in wissenschaftlichen Arbeiten und Whitepapers. [Bha07], [Bra07], [Coo02], [Inf10], [Moo08] und [The07] behandeln dabei aber auch lediglich, was zu testen ist. Des Weiteren sind sie bei Ihrer Betrachtung sehr fokussiert auf die Datenintegrationsprozesse. In [Kam10] wird zusätzlich etwas detaillierter auf die zu prüfenden Komponenten eingegangen. So nennen die Autoren neben den Datenintegrationsprozessen auch explizit das Testen der multidimensionalen Strukturen sowie der Berichte. Golfarelli und Rizzi beschreiben in ihren Arbeiten [Gol09 und Gol11] ebenfalls, was zu überprüfen ist und stellen zusätzlich Vorgehensmodelle zum Testen auf. Einen besonderen Schwerpunkt haben sie auf das Testen der multidimensionalen Modellierung gelegt. [Sha07] beschreibt zwei Szenarien für die Testautomatisation für Datenintegrationsprozesse. [Sun07] geht weniger auf das Testen an sich ein, sondern mehr auf die allgemeinen Missstände. Genannt werden die fehlende Auswahl an speziellen Testwerkzeugen sowie die mangelnden Qualifikationen der Business Intelligence Entwickler im Fachbereich Testen und umgekehrt der Tester im Fachbereich Business Intelligence..

(10) Kapitel 2 - Umfeld der Arbeit 2. Umfeld der Arbeit. 2. Kapitel 2. Umfeld der Arbeit. In diesem Kapitel werden die theoretischen Grundlagen zu der Master-Thesis vorgestellt. Dazu werden als erstes der Themenbereich Data Warehouse und Business Intelligence und anschließend der Themenbereich Testen von Software beschrieben.. Übersicht 2. Umfeld der Arbeit .................................................................................................. 5 2.1. Data Warehouse und Business Intelligence Systeme....................................... 6 2.2. Testen von Software ....................................................................................... 23.

(11) Kapitel 2 - Umfeld der Arbeit. 2.1. Data Warehouse und Business Intelligence Systeme Damit Führungskräfte eines Unternehmens strategische und operative Entscheidungen treffen können, benötigen sie einen Überblick über ihr Geschäft. Sogenannte entscheidungsunterstützende Systeme2 haben sich daher schon seit der Einführung der elektronischen Datenverarbeitung etabliert, um den Entscheidungsträgern alle relevanten Informationen zur Verfügung zu stellen. [vgl. Koe09, S. 1] Wie in der IT-Branche üblich, haben sich im Laufe der Zeit eine Vielzahl von Begriffen und Abkürzungen im Zusammenhang mit entscheidungsunterstützenden Systemen gebildet. In den letzten Jahren haben sich besonders die Begriffe Data Warehouse (DW) und Business Intelligence (BI) im Fachjargon der Informatik durchgesetzt. Dabei ist zu beachten, dass in der Literatur verschiedene Definitionen und Beschreibungen für die beiden Bezeichnungen zu finden sind. Kimball et al. schreiben dazu passend: „To this day, you can ask ten experts to define a data warehouse, and you are likely to get ten different responses.“ [Kim04, S. 23] Für diese Arbeit werden im Folgenden für die beiden Begriffe zwei Definitionen herangezogen. Danach werden Ziele und Notwendigkeiten von Data Warehouse und Business Intelligence Systemen erläutert sowie deren Architektur und Komponenten beschrieben.. 2.1.1. Definitionen Eine Definition für den Begriff Data Warehouse System (DWS) liefern Kimball et al.: „A data warehouse [..] system [...] extracts, cleans, conforms, and delivers source data into a dimensional data store and then supports [...] querying and analysis for the purpose of decision making.“ [Kim04, S. 23] Zusammengefasst extrahiert ein DWS also Daten aus verschiedenen Quellsystemen, integriert sie in einem speziellen Datenspeicher und stellt sie zu Abfrage- und Analysezwecken bereit. Der Datenspeicher selbst wird dabei häufig als DW bezeich-. 2. Auch engl.: Decision Support Systems (DSS).

(12) Kapitel 2 - Umfeld der Arbeit. net. Das gesamte DWS besteht zusätzlich noch aus einer Datenintegrationskomponente. Der Aspekt der Dimensionalität wird im Abschnitt 2.1.3 weiter erläutert.. Abbildung 2-1: Zusammenhang von BIS und DWS [Eigene Darstellung] Kemper et al. gehen ebenfalls sehr ausführlich auf die Problematik der Definitionsvielfalt für den Begriff Business Intelligence ein und es werden unterschiedliche Definitionen und Sichtweisen genannt. Für diese Arbeit wird die folgende Variante übernommen: „Unter Business Intelligence [...] werden alle direkt und indirekt für die Entscheidungsunterstützung eingesetzten Anwendungen verstanden.“ [Kem10, S. 4] Das Business Intelligence System (BIS) ist also ein abstrakter Oberbegriff, der sowohl das DWS als auch Analysesysteme und weitere Randsysteme (beispielsweise.

(13) Kapitel 2 - Umfeld der Arbeit. eine Job-Steuerung) umfasst. Die Abbildung 2-1 zeigt den groben Zusammenhang der beiden Begriffe. Da das DWS (die Datenbereitstellung) innerhalb des gesamten BIS eine sehr wichtige und zentrale Rolle einnimmt, ist eine gesonderte Benennung gerechtfertigt.. 2.1.2. Ziele und Notwendigkeiten Gerade beim DW ergibt sich die Frage nach der technischen Notwendigkeit. Schließlich ist es, salopp gesagt, nur eine Replizierung von Daten, die ein Unternehmen in seinen Datenverarbeitungssystemen generiert und dort auch speichert. Grundsätzlich ergeben sich zwei unterschiedliche Sichtweisen auf die Daten: operativ und dispositiv. Die operativen Daten haben einen direkten Bezug zu den Tätigkeiten der Leistungserbringung des Unternehmens. Dispositive Daten hingegen haben einen analytischen Charakter und dienen der Leitung und Steuerung des Unternehmens. [vgl. Kem10, S. 13] In der Tabelle 2-1 sind die wichtigsten Unterschiede der beiden Sichtweisen dargestellt. Am Beispiel eines Versicherungsunternehmens lassen sich die Unterschiede verdeutlichen: •. Operative Daten o Detaillierte Informationen zu den einzelnen Versicherungsverträgen o Datenänderungen rund um die Uhr durch das Onlineportal o Speicherung der Verträge in zwei unterschiedlichen Systemen, jeweils ein eigenes für Kraftfahrt- und Lebensversicherungen. •. Dispositive Daten o Summierung der Umsätze und Profite pro Kundengruppe o Darstellung der zeitlichen Veränderungen zum Vorjahr o Gegenüberstellung der Produktsparten Kraftfahrt und Haftpflicht. Eine direkt auf den operativen Daten beruhende Auswertung erfüllt somit nicht die dispositiven Anforderungen. Besonders die heterogene Systemlandschaft erschwert das Gegenüberstellen von Informationen. Zusätzlich verdeutlichen die Aspekte „Abfragen“ und „Transaktionen“ in der Tabelle, dass Analysen direkt auf operativen Daten gefährlich sind: Langläufige und ressourcenintensive Abfragen können das gesamte operative System blockieren und das Tagesgeschäft beeinträchtigen. [vgl. Koe09, S. 14].

(14) Kapitel 2 - Umfeld der Arbeit. Operative Daten. Dispositive Daten. Ziel. Leistungserbringung. Entscheidungsunterstützung. Anwender. viele Sachbearbeiter. wenige Analysten. Detaillierung. feingranulare Geschäftsprozesse. verdichtete (aggregierte) Informationen. Zeitbezug. aktuell (zeitpunktbezogen). historisch (zeitraumbezogen). Implementierung. heterogen (historisch gewachsen). homogen (vereinheitlicht). Aktualisierung. kontinuierlich in Echtzeit. turnusmäßige Fortschreibung. Abfragen. einfach strukturiert. rechenintensiv. Transaktionen. viele kurze. wenige lange. Tabelle 2-1: Operative vs. dispositive Daten [vgl. Hin02, S. 13] In der Regel sind es unternehmerische bzw. wirtschaftliche Gründe, die einen Betrieb dazu veranlassen, ein BIS zur Entscheidungsunterstützung einzuführen. Typische Interessenten für Auswertungen innerhalb des Unternehmens sind zum Beispiel die Vertriebsabteilung, die für eine effektive Steuerung des Außendienstes Umsatz- und Renditeinformationen zu den verschiedenen Absatzgebieten benötigt, oder die Marketingabteilung, die anhand von Informationen zu den verschiedenen Kundengruppen gezielte Werbemaßnahmen durchführt. Mittlerweile existieren allerdings auch einige gesetzliche Regelungen, die ein BIS notwendig machen. [vgl. Kem10, S. 6] Durch das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) wurde im Jahr 1998 das Aktiengesetz (AktG) um Aspekte der Risikokontrolle erweitert: „[Ein Unternehmen hat] geeignete Maßnahmen zu treffen, insbesondere ein Überwachungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende Entwicklungen früh erkannt werden kann.“ [AktG, § 91 Abs. 2] Spätestens durch dieses Gesetz ist ein BIS für ein Unternehmen nahezu unumgänglich..

(15) Kapitel 2 - Umfeld der Arbeit. 2.1.3. Architektur und Komponenten Neben den unterschiedlichen Definitionsansätzen existieren in der Literatur auch entsprechend verschiedene Architekturansätze für DW und BI Systeme. In dieser Arbeit werden neben den Definitionen auch die Architekturansätze von Kimball et al. sowie Kemper et al. übernommen.. 2.1.3.1 Quellsysteme Als Quellsysteme werden alle Systeme bezeichnet, deren Daten im BIS analysiert und ausgewertet werden. Bei diesen Systemen handelt es sich in der Regel um firmeninterne Anwendungen, die im eigenen Rechenzentrum laufen. Es ist aber auch möglich, dass ein Unternehmen externe Daten heranzieht, beispielsweise wenn ein Teil des Tagesgeschäfts durch einen Dienstleister erbracht wird oder wenn allgemeine Marktdaten (Prognosen, Umfragen etc.) abgerufen werden. Die (internen) operativen Anwendungen für das Tagesgeschäft werden oft als Online-Transaction-Processing (OLTP) Anwendungen bezeichnet. Viele Benutzer lesen und bearbeiten gleichzeitig (in Echtzeit) den gleichen Datenbestand. Daneben besitzen Unternehmen auch autarke Anwendungen, die im Hintergrund ohne Benutzerinteraktionen laufen. In einem Versicherungsunternehmen sind das etwa die Antragsprüfung oder die Rechnungsschreibung.. Abbildung 2-2: Heterogenität von Quellsystemen [Eigene Darstellung] Es wird ersichtlich, dass die Arten und Strukturen der Quellsysteme einen starken Hang zur Heterogenität aufweisen (Abbildung 2-2). [vgl. Kem10, S. 28] Bei Versiche-.

(16) Kapitel 2 - Umfeld der Arbeit. rungsunternehmen tritt diese Heterogenität besonders oft auf: Die OLTP Anwendungen stammen dort zum Teil noch aus den 1960er oder 1970er Jahren. Diese Alt3Anwendungen laufen samt Datenhaltung auf einem Großrechner. Seit den 1990er Jahren existieren zusätzlich Client-Server Anwendungen, die objektorientiert implementiert wurden und deren Daten in einem relationalen Datenbanksystem liegen. Im administrativen Bereich wird Standardsoftware wie SAP eingesetzt. Mit externen Dienstleistern und Branchen-Verbänden wird über das Internet und mittels einfacher Text-Dateien oder Webservices kommuniziert. Das DWS steht also bei der Datenintegration der verschiedenen Quellen vor einer großen technischen Herausforderung. Um den Prozess der Datenintegration der dispositiven Daten als auch dessen Speicherung besser verstehen zu können, ist es sinnvoll zunächst das Ziel der Daten zu betrachten: die Analyse Anwendungen.. 2.1.3.2 Analysesysteme Analysesysteme dienen der Darstellung von Daten über ein Reporting Front-End. Das Ziel ist es, die Daten so darzustellen und aufzubereiten, dass daraus verwendbare Informationen abgeleitet werden können. Spreadsheet Reporting Die einfachste Variante der Analyse ist das sogenannte Spreadsheet Reporting. Dabei werden die zu analysierenden Daten auf einem klassischen Tabellenblatt, bestehend aus Zeilen und Spalten, dargestellt. Das wohl bekannteste und am meisten verbreitete Reporting Front-End ist Microsoft Excel (Abbildung 2-3). [vgl. Kem10, S. 102] Mit den von Excel bereitgestellten Funktionen können die wichtigsten Kennzahlen, wie Summen oder Durchschnittswerte, ermittelt werden. Die Daten für die Auswertungen werden dabei in der Regel von einer Informatikabteilung geliefert, die beispielsweise mittels SQL eine Datei für einen Import in Excel bereitstellt. [vgl. Kim02, S. 11] Das Listing 2-1 stellt einen solchen Abzug exemplarisch dar. Soll die Sichtweise verändert werden, ist auch eine Anpassung der SQLStatements nötig. 3. Auch engl.: Legacy.

(17) Kapitel 2 - Umfeld der Arbeit. Abbildung 2-3: Spreadsheet Reporting (Excel) [Eigene Darstellung]. 01 02 03 04. SELECT PRODUKT, MONAT, SUM(BEITRAG) FROM VERKAUFSZAHLEN WHERE PRODUKT IN ('Kfz', 'Haftpflicht') GROUP BY PRODUKT, MONAT; Listing 2-1: SQL für Spreadsheet Reporting [Eigene Darstellung]. Die wesentlichen Nachteile des Spreadsheet Reportings sind Redundanzen und Vervielfältigungen von Daten in ähnlichen Berichten, eine mangelnde Mehrbenutzerfähigkeit sowie die Inflexibilität bei der Sicht auf die Daten durch statische SQLStatements. Data Mining Eine besondere Analysetechnik stellt das sogenannte Data Mining dar. Hierbei steht nicht das Berichten von vorhandenen Informationen im Vordergrund. Stattdessen wird innerhalb der Daten gezielt nach Mustern und Zusammenhängen gesucht und somit neue Erkenntnisse abgeleitet. [vgl. Cle10, S. 11] Da das Data Mining ein sehr spezielles und eigenständiges Verfahren ist, wird es in dieser Arbeit nicht weiter betrachtet..

(18) Kapitel 2 - Umfeld der Arbeit. 2.1.3.3 OLAP-Systeme Eine modernere Analysetechnik ist das sogenannte Online-Analytical-Processing (OLAP). Das Ziel von OLAP ist es, die Nachteile beim Spreadsheet Reporting zu beseitigen. Ein Analyst soll die Möglichkeit erhalten, seine Auswertungen „live“ bzw. „online“ anpassen zu können, um je nach geschäftlicher Anforderung verschiedene Sichten auf die Daten zu erhalten. [vgl. Kem10, S. 93ff] In diesem Zuge hat sich auch der bereits im Abschnitt 2.1.1 erwähnte Begriff der multidimensionalen Analyse durchgesetzt.. Abbildung 2-4: OLAP-Würfel [Eigene Darstellung] Im allgemeinen Sprachgebrauch wird der so entstehende multidimensionale Datenraum auch als OLAP-Würfel4 bezeichnet (Abbildung 2-4), weil sich eine dreidimensionale Betrachtung plastisch am besten darstellen lässt. Ein solcher Würfel besteht immer aus Dimensionen (Kanten des Würfels) und Kennzahlen5 (Werte an den Koordinaten innerhalb des Würfels). Kennzahlen sind die betriebsbedingten Größen wie etwa Umsatz, Kosten oder Stückzahlen. Dimensionen hingegen haben einen beschreibenden Charakter für die Kennzahlen, z.B. die Zeit, der Kunde und das Pro4. Auch engl.: Cube. 5. Auch alternativ: Fakten.

(19) Kapitel 2 - Umfeld der Arbeit. dukt für einen Umsatz. Der Würfel der Abbildung 2-4 zeigt exemplarisch, dass im Jahr 2011 in Norddeutschland für die Sparte Lebensversicherung (Dimensionen Zeit, Region und Sparte) ein Umsatz von 78 Mio. Euro (Kennzahl) erzielt wurde. Die Elemente einer Dimension lassen sich aufgrund funktionaler Abhängigkeiten oft in Hierarchien gruppieren (Abbildung 2-5). So können beispielsweise in der Zeitdimension die Monate zu Quartalen oder in der Produktdimension Produkte zu Produktgruppen zusammengefasst werden. Entlang der Dimensionshierarchie lassen sich die Kennzahlen dann konsolidieren (in der Regel Summenbildung). [vgl. Koe09, S. 9]. Abbildung 2-5: Zeit-Hierarchie [Eigene Darstellung] Ein Würfel kann aus verschiedenen Perspektiven analysiert werden (Abbildung 2-6). Pivoting bezeichnet das Drehen bzw. Kippen des gesamten Würfels, indem die Achsen (Dimensionen) vertauscht werden. Slice bzw. Dice ist die Einschränkung der Sicht auf Teilbereiche, indem nicht relevante Informationen ausgeblendet werden. Ein Slice definiert die Einschränkung auf eine einzige Dimension, ein Dice hingegen auf mehrere Dimensionen. Das Navigieren entlang der Dimensionshierarchien wird auch Roll Up bzw. Drill Down genannt. Ein Roll Up konsolidiert die Kennzahlen auf eine höhere (allgemeinere) Ebene der Dimension, beispielsweise von einzelnen Versicherungssparten auf eine Gesamtsicht. Ein Drill Down ist die Navigation in die entgegengesetzte Richtung, es wird also eine detailliertere Sicht auf die Kennzahlen erzeugt (z.B. die einzelnen Quartale eines Jahres). [vgl. Kem10, S. 96ff].

(20) Kapitel 2 - Umfeld der Arbeit. Abbildung 2-6: OLAP-Würfel Perspektiven [Eigene Darstellung] Für die multidimensionale Datenspeicherung bieten Hersteller von OLAP-Systemen spezielle multidimensionale Datenbankmanagementsysteme (MDBMS) an. Diese sind für die OLAP-spezifischen Anforderungen optimiert und bieten beispielsweise die Möglichkeit zur Berechnung von konsolidierten Kennzahlen direkt beim Laden eines Würfels. So sind für Abfragen zur Laufzeit keine weiteren Berechnungen mehr nötig. Alternativ kann ein OLAP-System auch mittels relationaler Datenbankmanagementsystemen (RDBMS) implementiert sein. Es wird je nach zugrundeliegender Technik zwischen multidimensionalen OLAP (MOLAP), relationalen OLAP (ROLAP) und einer Mischform, dem hybriden OLAP (HOLAP), unterschieden. [vgl. Tot00, S. 65ff] Die analytischen Grundgedanken sind bei allen drei Techniken jedoch gleich. Als Front-End für die Analyse und Berichterstellung bieten OLAP-Systeme mehrere Zugriffsmöglichkeiten. Gängige Praxis sind Erweiterungen für Excel als auch proprietäre Rich-Client-Anwendungen oder Online-Portale. [vgl. Kem10, S. 101].

(21) Kapitel 2 - Umfeld der Arbeit. 2.1.3.4 Data Warehouse Das DW ist das zentrale Lager für dispositive Daten. [vgl. Kem10, S. 17] Da relationale Datenbanken heutzutage sehr weit entwickelt sind, sie mittels SQL umfassende Zugriffs- und Manipulationsoperationen bereitstellen und sie innerhalb von Unternehmen eine starke Verbreitung haben, bieten sie sich auch als einheitliche Speicherform für das DW an. Alternativ kann ein DW aber auch (zum Teil oder komplett) aus einfachen Text- oder XML-Dateien bestehen. [vgl. Kem10, S. 22]. Abbildung 2-7: Operatives Schema und Sternschema [vgl. Tot00, S. 112] Für die Unterstützung der multidimensionalen Anforderungen bietet sich das sogenannte Sternschema als ein einfaches Verfahren an, um Dimensionen und Kennzahlen in relationalen Tabellen zu speichern. Die Faktentabelle in der Mitte referenziert mittels Fremdschlüssel die Dimensionen und speichert für die verschiedenen Kombinationen aus Dimensionselementen die Kennzahlen. Eine Denormalisierung (Abbildung 2-7) wird bei der Erstellung des Sternschemas bewusst in Kauf genommen, um eine möglichst einfache und schnelle Analyseabfrage zu ermöglichen. [vgl. Tot00, S. 111ff] Für die tatsächlichen Auswertungen werden den Analyseanwendern oft verschiedene Sichten bzw. Teilbereiche abgeleitet und bereitgestellt. Diese Teilbereiche werden auch als Data Mart bezeichnet und bieten den Vorteil, dass ein Anwenderkreis nur die für ihn interessanten Daten sieht. So hat eine Vertriebsabteilung in der Regel nur Interesse an Kennzahlen wie Verkaufsstückzahlen, Umsatz oder Provisionen. Eine Fertigungsabteilung hingegen interessiert sich für Produktionsstückzahlen oder Fer-.

(22) Kapitel 2 - Umfeld der Arbeit. tigungszeiten. Ein solcher Data Mart ist die Datengrundlage, aus der ein OLAPWürfel geladen wird. Zu dem DW gehört weiterhin die sogenannte Staging Area. Die Staging Area ist ein (Hilfs-)Speicherbereich, der während der Extraktion und Integration der Daten verwendet wird und zum Beispiel Zwischenergebnisse speichert. [vgl. Kim02, S. 8]. 2.1.3.5 Datenintegration Der Prozess des Übertrages der Daten aus den Quellsystemen in das DW findet in drei Stufen statt: •. Extraktion der benötigten Daten. •. Transformation in ein einheitliches multidimensionales Format. •. Laden in das DW und Bereitstellen für Analysen. Der gesamte Prozess wird in der Literatur häufig abgekürzt als ETL-Prozess bezeichnet. In dieser Arbeit wird der Prozess vereinfacht als Datenintegration (DI) bezeichnet.. Gültiger Wert Richtiger Wert Richtige Darstellung Exakte Daten. Ungültiger Wert. Fehlender Wert. Falscher Wert. Falsche Darstellung Inexakte Daten Abbildung 2-8: Exaktheit von Daten [vgl. Ols03, S. 33]. Das Lesen der Rohdaten aus den Quellsystemen wird als Extraktion bezeichnet. Das Lesen kann aus Sicht des DWS sowohl direkt als auch indirekt erfolgen. Direkt bedeutet, dass der Extraktionsprozess selber aktiv auf die produktiven Quellen zugreift und sich die benötigten Daten holt. Dieses Vorgehen hat jedoch zwei Nachteile. Zum einen muss sich der DW-Entwickler intensiv mit der Struktur des operativen Datenmodells auseinandersetzen und dieses verstehen, um die richtigen Attribute selektieren zu können. Zum anderen ist der Prozess damit vom operativen Datenmodell abhängig und muss bei Änderungen ebenfalls angepasst werden. Für einige geschlossene, proprietäre Anwendungen gibt es darüber hinaus häufig keine Möglichkeit, di-.

(23) Kapitel 2 - Umfeld der Arbeit. rekt auf das zugrundeliegende Datenmodell zuzugreifen. Von daher bietet sich für die Extraktion oftmals ein indirekter Zugriff an. Hierbei stellt der Verantwortliche des operativen Systems eine klar definierte Schnittstelle bereit, auf die der Extraktionsprozess zugreift. Eine Schnittstelle kann beispielsweise eine Tabellen-View oder ein exportierter Tabellen-Abzug als Datei sein. Der Entwickler des Quellsystems hat dann sicherzustellen, dass bei Änderungen des Datenmodells die Schnittstelle weiterhin korrekt beliefert wird. [vgl. Tot00, S. 110] Der Transformationsschritt ist der aufwendigste und komplexeste Teil des Integrationsprozesses. Kimball et al. teilen die Transformation zum besseren Verständnis in zwei Schritte: Säubern6 und Harmonisieren7. [vgl. Kim04, S. 18ff] Das Säubern der Daten dient der Behebung von Mängeln und somit der Erreichung einer definierten Datenqualität. [vgl. Kim04, S. 134ff] Die Säuberung ist deshalb notwendig, weil operative Systeme nicht zwangsweise immer exakte Daten enthalten (Abbildung 2-8). Die Ursachen für inexakte Daten kann sehr vielfältig sein: falsche Eingaben durch die Anwender, Systemfehler oder Evolution der Systeme. [vgl. Ols03, S. 43ff] Bei den zu behebenden Mängeltypen lassen sich syntaktische (technische) und semantische (inhaltliche) Mängel unterscheiden. Syntaktische Mängel sind alphanumerische Werte in einem numerischen Feld, NULL Werte in einem NOT NULL Feld oder Werte außerhalb des Wertebereiches. Semantische Mängel ergeben sich aufgrund von falschen inhaltlichen Beziehungen zwischen mehreren Feldern, etwa zwischen der Postleitzahl und dem Ort. Das Harmonisieren ist notwendig, wenn Daten aus verschiedenen Quellsystemen zusammengespielt werden. In den heterogen gewachsenen Quellsystemen werden für gleiche Sachverhalte bzw. Eigenschaften oftmals unterschiedliche Schlüssel oder Ausprägungen verwendet. Das klassische Beispiel ist der Schlüssel für das Geschlecht, der in drei Systemen unterschiedlich als männlich/weiblich, M/W und als 0/1 dargestellt wird. Ziel ist es also, die gleichen Sachverhalte auf einen gemeinsamen Schlüssel zu bringen. Weiterhin werden unterschiedliche Messgrößen in ein gemeinsames Maß übertragen, beispielsweise werden verschiedene Währungen in eine einheitliche Währung umgerechnet. [vgl. Kim04, S. 148ff]. 6. Auch engl.: Clean. 7. Auch engl.: Conform.

(24) Kapitel 2 - Umfeld der Arbeit. Im finalen Schritt des Integrationsprozesses werden die gesäuberten und harmonisierten Daten in das Sternschema überführt bzw. als Sternschema ausgeliefert8 (Abbildung 2-7). Das bedeutet, dass gemäß dem multidimensionalen Modell die Dimensionstabellen und Faktentabellen gefüllt werden. Abschließend werden aus dem Sternschema die OLAP-Würfel geladen. [vgl. Kim04, S.19] Im Folgenden wird das Vorgehen der Datenintegration exemplarisch veranschaulicht. Die Tabelle 2-1 zeigt die Originaldaten, so wie sie über die Schnittstelle des Quellsystems geliefert werden. Bei den Daten handelt es sich um Versicherungsdaten (Versicherungsschein-ID, Datum des Vertragsbeginns, Geschlecht sowie Postleitzahl/Ort des Versicherungsnehmers, gezahlter Beitrag und verursachte Schäden in Dollar).. Vers.ID. Datum. Geschlecht PLZ. Ort. Beitrag $ Schäden $. 201-38214 13.07.2011. männlich. 10000 Hannover. 207,16. 195,42. 200-92346 28.04.2011. männlich. 30419 Hannover. 186,03. 427,81. 201-19203 08.01.2011. weiblich. 30165 Hannover. 311,40. 84,32. 201-71829 15.10.2011. weiblich. 30657 Hannover. 229,74. 0x2A. Tabelle 2-2: Originaldaten aus Quellsystem [Eigene Darstellung] Das Anwenden von Qualitätsregeln ergibt, dass beim ersten und letzten Datensatz fehlerhafte Informationen vorliegen. Die Postleitzahl 10000 passt nicht zu dem Ort Hannover und 0x2A ist kein gültiger Wert für eine Schadenzahlung.. Vers.ID. Datum. Geschlecht PLZ. Ort. 201-38214 13.07.2011. männlich. 10000 Hannover. 207,16. 195,42. 200-92346 28.04.2011. männlich. 30419 Hannover. 186,03. 427,81. 201-19203 08.01.2011. weiblich. 30165 Hannover. 311,40. 84,32. 201-71829 15.10.2011. weiblich. 30657 Hannover. 229,74. 0x2A. Tabelle 2-3: Gesäuberte Daten [Eigene Darstellung]. 8. Beitrag $ Schäden $. Auch engl.: Deliver.

(25) Kapitel 2 - Umfeld der Arbeit. Die fehlerhaften Datensätze werden ausgesteuert und nur die gültigen Sätze werden weiterverarbeitet. Zur Harmonisierung der Daten werden die Schlüssel für das Geschlecht in das Format M/W umgewandelt und die Beträge von Dollar in Euro umgerechnet:. Vers.ID. Datum. Geschlecht PLZ. Ort. Beitrag € Schäden €. 200-92346 28.04.2011. M. 30419 Hannover. 146,21. 336,25. 201-19203 08.01.2011. W. 30165 Hannover. 244,75. 66,27. Tabelle 2-4: Harmonisierte Daten [Eigene Darstellung] Schließlich werden die Daten in das Sternschema umgeformt. Aus den ersten drei Ziffern der Versicherungsschein-ID wurde das Produkt abgeleitet. Weitere Dimensionen sind die Zeit, das Geschlecht und das Absatzgebiet. Die Faktentabelle in der Mitte referenziert die umliegenden Dimensionstabellen mittels surrogater Fremdschlüssel:. ProduktKey Produktgruppe. Produkt. ZeitKey Jahr Monat. 78. Kraftfahrt. Kraftfahrt-Haftpflicht. 20110128 2011 Januar. 79. Kraftfahrt. Kraftfahrt-Teilkasko. 20110408 2011 April. ProduktKey. ZeitKey Geschl.Key AbsatzgebietKey Beitrag € Schäden €. 78. 20110428. 1. 13. 146,21. 336,25. 79. 20110801. 2. 13. 244,75. 66,27. Geschl.Key Geschl. 1. M. 2. W. AbsatzgebietKey 13. Land. Bundesland. Region. Deutschland Niedersachsen Hannover. Tabelle 2-5: Daten im Sternschema [Eigene Darstellung].

(26) Kapitel 2 - Umfeld der Arbeit. 2.1.3.6 Automatisierungssysteme In der Definition von BI werden auch die indirekt beteiligten Systeme mit eingeschlossen. Als direkt beteiligt können die zuvor vorgestellten Systeme für die Datenbereitstellung, Datenhaltung und Analyse angesehen werden. Indirekt beteiligt sind folglich alle anderen Systeme, die beim Betrieb eines BIS partizipieren. Eines der wichtigsten Systeme, das für den Betrieb eines automatisierten BIS benötigt wird, ist die Job-Steuerung. Allgemein gesprochen sorgt eine Job-Steuerung dafür, dass Programme zur richtigen Zeit am richtigen Ort in der richtigen Art und Weise gestartet und beendet werden. Die Transformation innerhalb eines Datenintegrationsprozesses kann ein solches Programm sein. Der Prozess selber weiß nicht, wann er zu starten hat, weil er mögliche Abhängigkeiten sowie Vorbedingungen nicht kennt. So darf die Transformation natürlich erst dann starten, wenn die Extraktion erfolgreich beendet ist und alle benötigten Daten bereitstehen. Somit werden Programme, die gemeinsam einen Prozess darstellen, in der richtigen Reihenfolge zu einem sogenannten Job zusammengefasst. Soll dieser Job in einem regelmäßigen Intervall laufen (z.B. täglich), dann kann er von der Steuerung in einen Zeitplan9 eingebunden werden. Der „richtige Ort“ ist ein Server innerhalb des Rechenzentrums. Da die Prozesse innerhalb des BIS für gewöhnlich rechenintensiv sind und viele Hardwareressourcen (CPU, RAM, I/O) verbrauchen, müssen sie zur Erzielung der optimalen Gesamtperformance gleichmäßig auf die verschiedenen Server verteilt10 werden. Ein zu startender Prozess wird also immer auf den Server übertragen, der gerade am wenigsten ausgelastet ist. Das Starten und Beenden der Programme „in der richtigen Art und Weise“ bezieht sich zum einen auf die Eingabeparameter und zum anderen auf Rückgabewerte von einem Programm. Beim Start einer Transformation muss beispielsweise die Referenz auf die zu verarbeitenden Daten und beim Beenden die Referenz an den folgenden Lade-Prozess übergeben werden. Falls das Programm aufgrund eines Fehlers abbricht, so muss der Fehler abgefangen und behandelt werden. Etwa indem der gesamte Prozess gestoppt und ein Administrator darüber benachrichtig wird. [vgl. Sco09, S. 3ff] 9. Auch engl.: Schedule. 10. Auch engl.: Load Balancing.

(27) Kapitel 2 - Umfeld der Arbeit. 2.1.4. Business Intelligence System Big Picture Die logische Übersicht zum Zusammenhang von DWS und BIS aus Abbildung 2-1 wurde in der Abbildung 2-9 um die in den vorherigen Abschnitten vorgestellten Komponenten zu einem abschließenden Big Picture erweitert.. Abbildung 2-9: Business Intelligence System Big Picture [Eigene Darstellung] Aufgrund der genannten Definitionsvielfalt gibt es in der Literatur ebenfalls eine entsprechende Vielfalt bei den zusammenfassenden Big Pictures. Diese Bilder neigen dazu, sehr überladen zu wirken, weil sie jeden Aspekt bzw. jede Variation berück-.

(28) Kapitel 2 - Umfeld der Arbeit. sichtigen sollen (Metadaten-Repository, Operational Data Store etc.). Die hier gezeigte Abbildung ist mit Absicht schlicht gehalten und beschränkt sich auf die wesentlichen Punkte eines BIS, die für den weiteren Verlauf dieser Arbeit von Bedeutung sind.. 2.2. Testen von Software Jede Software enthält ab einer bestimmten Komplexität Fehler. [vgl. Lig09, S. 4] Unentdeckte Fehler können im schlimmsten Fall nach Auslieferung der Software schwerwiegende Schäden verursachen. Neben wirtschaftlichen Schäden können auch körperliche Schäden angerichtet werden, beispielsweise bei Software in der Medizin- oder in der Luftfahrttechnik11. Zu den Schadensersatzforderungen hat der Softwarehersteller in einem derartigen Fehlerfall zusätzlich mit einem starken Imageverlust zu rechnen. Da BIS die Grundlagen für unternehmerische Entscheidungen liefern, können Fehler zu falschen Entscheidungen führen und somit wirtschaftliche Schäden innerhalb eines Unternehmens anrichten. Unter dem Testen von Software wird nach Spillner und Linz [vgl. Spi03, S.8ff] das stichprobenartige Ausführen eines Testobjektes mit dem anschließenden Vergleich des Soll- und Ist-Verhaltens verstanden. Daneben gibt es aber auch statische Analysen, bei denen ein Testobjekt geprüft wird, ohne ausgeführt zu werden. Als Hauptziele von Tests ergeben sich: •. Entdeckung von Fehlern bevor ein Schaden entsteht. •. Aufbauen von Vertrauen in die Software. Eine sehr ausführliche Einteilung verschiedener praktischer Softwareprüftechniken wurde in Liggesmeyer [vgl. Lig09, S. 38] vorgenommen. In der Abbildung 2-10 sind die in dieser Arbeit verwendeten Techniken als Übersicht zusammengefasst. In den folgenden Abschnitten werden diese Techniken näher beschrieben.. 11. Hoffmann [Hof08, S. 33ff] liefert in diesem Zusammenhang einige prominente Beispiele von Soft-. warefehlern und deren Auswirkungen bei der US Army, der NASA und der ESA..

(29) Kapitel 2 - Umfeld der Arbeit. Abbildung 2-10: Klassifikation der Softwareprüftechniken [vgl. Lig09, S. 38]. 2.2.1. Softwareentwicklungsprozess Das klassische Vorgehensmodell bei der Softwareentwicklung ist das Wasserfallmodell. [vgl. Han05, S. 267] Die Software durchlebt dabei sechs strikt aufeinanderfolgende Phasen: Anforderungen (Start) à Analyse à Design à Implementierung à Test à Betrieb (Ende). In Abbildung 2-12 auf der linken Hälfte ist dieses Vorgehen dargestellt. Das Testen zum Ende des Entwicklungsprozesses kann jedoch bereits zu spät sein. Liggesmeyer liefert eine anschauliche Darstellung, wie sich die Fehleranzahl und die Fehlerbehebungskosten auf die einzelnen Projektphasen aufteilen (Tabelle 2-6). Etwa die Hälfte aller Fehler entsteht also noch bevor eine Zeile Code geschrieben wurde. Gleichzeitig sind die Fehlerbehebungskosten in den frühen Projektphasen am.

(30) Kapitel 2 - Umfeld der Arbeit. niedrigsten. Von daher empfiehlt es sich, während eines Projektes so früh wie möglich mit dem Testen anzufangen.. Anzahl der entstandenen Fehler. 10%. 40%. 50%. -. -. -. Anzahl der erkannten Fehler. 3%. 5%. 7%. 25%. 50%. 10%. Kosten pro Fehlerbehebung. 250€. 250€. 250€. 1.000€. 3.000€. 12.500€. Analyse. Design. Systemtest. Produktivbetrieb. Implemen- Entwicktierung lertest. Tabelle 2-6: Fehlerkosten [vgl. Lig09, S. 33] Eine Erweiterung des Wasserfallmodells ist das sogenannte V-Modell (Abbildung 2-11). Die Testaktivitäten sind dabei mit der eigentlichen Konstruktion (Analyse, Entwurf, Implementierung) gleichgestellt und jeder Entwicklungsstufe wird eine eigene Teststufe zugeordnet. [vgl. Spi03, S. 39ff]. Abbildung 2-11: V-Modell [vgl. Spi03, S. 40] Moderne Entwicklungsansätze bei Projekten mit unvollständigen oder sich ändernden Anforderungen gehen evolutionär bzw. prototypisch vor. Dabei wird das Gesamtprojekt in kleine Portionen aufgeteilt und zunächst mit der Entwicklung der Kernfunktionen begonnen. Mithilfe eines so entstehenden Prototyps kann ein Auftragge-.

(31) Kapitel 2 - Umfeld der Arbeit. ber sich schneller ein Bild davon verschaffen, ob die Entwicklung in die gewünschte Richtung geht oder ob die Anforderungen überhaupt realisierbar sind. Auf Basis des Prototyps wird das System nach und nach erweitert. Die einzelnen Ausbaustufen durchlaufen jeweils die Entwicklungs- und Testphasen (Abbildung 2-12, rechte Hälfte). [vgl. Spi03, S. 68]. Abbildung 2-12: Wasserfallmodell vs. Prototyp [vgl. Koe07, S. 7]. 2.2.2. Dynamische Prüftechniken Ein dynamischer Test liegt dann vor, wenn die Software mit konkreten Eingabedaten zur Ausführung gebracht wird. Die dynamischen Tests besitzen zusammengefasst die folgenden Merkmale: •. Die übersetzte, ausführbare Software wird mit konkreten Eingabewerten versehen und ausgeführt.. •. Es kann in der realen Betriebsumgebung getestet werden.. •. Es handelt sich um ein Stichprobenverfahren.. Der wesentliche Nachteil ist, dass sie nur einen Stichprobencharakter aufweisen, weil nicht alle möglichen Situationen (Eingabewerte) getestet werden können. Ein vollständiger Test aller möglichen Eingaben wird auch als erschöpfender Test bezeichnet. Die Durchführung eines erschöpfenden Tests ist in der Regel nicht möglich, weil die Anzahl an Testfällen gegen unendlich gehen kann. Das Ziel der dynami-.

(32) Kapitel 2 - Umfeld der Arbeit. schen Prüftechniken ist daher die Erzeugung effektiver und sinnvoller Testfälle. [vgl. Lig09, S. 39] Eine weitere Unterteilung der dynamischen Prüftechniken erfolgt in funktionsorientierte und in strukturorientierte Testtechniken. Die funktionsorientierten Techniken leiten anhand der in der Spezifikation beschriebenen Funktionen die Testfälle ab und bewerten die Testvollständigkeit und -ergebnisse auch an der Spezifikation. [vgl. Lig09, S. 40] Die strukturorientierten Techniken hingegen liefern keine Regeln für die Testfallerstellung. Im Vordergrund steht die Bewertung der Abdeckungen der Strukturelemente des Quellcodes (Anweisungen, Zweige, Datenzugriffe etc.) durch die (wie auch immer) erzeugten Testfälle. [vgl. Lig09, S. 84]. 2.2.2.1 Funktionsorientierte Tests Der Ausgangspunkt für funktionsorientierte Tests ist die Spezifikation, die das SollVerhalten der Software definiert. Aus der Spezifikation werden entsprechend die Testfälle abgeleitet. Durch die Testausführung entstehen Reaktionen der Software, welche mit den vorgegebenen Reaktionen übereinstimmen müssen. Der Vorteil des funktionsorientierten Testens liegt in der Verifikation des vorgegebenen Verhaltens. Somit können erfolgreich durchgeführte Tests ein grundsätzliches Vertrauen in die Software liefern. Nachteilig ist allerdings, dass aufgrund der Vielzahl an theoretischen Eingabekombinationen die Struktur der Software (der Quellcode) unter Umständen nicht vollständig getestet wird und so die Möglichkeit besteht, dass verdeckte Fehler nach dem Testen weiterhin bestehen bleiben. Der Erfolg des Testens steht und fällt mit der Stichprobenauswahl. Als Zielsetzung der funktionsorientierten Prüftechniken ergibt sich die Erstellung von Testfällen, die repräsentativ, fehlersensitiv, redundanzarm und ökonomisch sind. [vgl. Lig09, S. 39] Äquivalenzklassenbildung Eine einfache Testfallermittlung kann mittels Grenzwertanalyse und der daraus resultierenden Äquivalenzklassenbildung erfolgen. Dafür werden alle Eingabedaten, die zu demselben Ergebnis führen, als eine Äquivalenzklasse zusammengefasst. Aus dieser Klasse wird dann nur ein Testfall stellvertretend für die ganze Gruppe zur Ausführung gebracht. [vgl. Lig09, S. 52ff].

(33) Kapitel 2 - Umfeld der Arbeit. Grenzwerte. -1. Gratifikation Fehler. 0. 4. 5. 250€. 250€. 500€. 9. 10. 60. 61. 500€ 1.000€ 1.000€ Fehler. Tabelle 2-7: Grenzwerte [Eigene Darstellung] Das folgende Beispiel soll die Testfallermittlung mittels Äquivalenzklassenbildung verdeutlichen: In Abhängigkeit der Firmenzugehörigkeit soll ein Programm die Weihnachtsgratifikation für die Mitarbeiter berechnen. Für 0 bis 4 Jahre Zugehörigkeit 250€, für 5 bis 9 Jahre 500€ und für 10 oder mehr Jahre 1.000€. Die Firmenzugehörigkeit ist immer eine ganze Zahl. Ein Mitarbeiter kann maximal 60 Jahre dem Betrieb zugehören. [vgl. Spi03, S. 24f] Aus diesen Informationen ergeben sich die Grenzwerte in der Tabelle 2-7. Mit den Grenzwerten lassen sich die möglichen Eingabewerte in insgesamt sechs Äquivalenzklassen aufteilen, aus denen dann jeweils ein Repräsentant ausgewählt und getestet wird:. Äquivalenzklassen (Werte) Repräsentant Gratifikation (Ergebnis) Ä" = {0,1,2,3,4}. 3. 250€. Ä- = {5,6,7,8,9}. 7. 500€. Ä3 = {10, … ,60}. 37. 1.000€. Ä5 = {−1, −2, … }. -9. Fehler. Ä7 = {60,61, … }. 73. Fehler. Tabelle 2-8: Äquivalenzklassen [Eigene Darstellung] Ursache-Wirkungs-Analyse Während die Äquivalenzklassenbildung lediglich einzelne Eingaben und Ergebnisse betrachtet, stellt die Ursachen-Wirkungs-Analyse auch Zusammenwirkungen von Eingaben dar. Bei vielen Eingabemöglichkeiten existiert auch eine hohe Anzahl von Kombinationsmöglichkeiten. Deshalb ist es ein Ziel der Ursache-Wirkungs-Analyse, diese Anzahl auf ein überschaubares und sinnvolles Maß zu reduzieren. [vgl. Lig09, S. 66ff].

(34) Kapitel 2 - Umfeld der Arbeit. Bei Ursachen handelt es sich um logische Eingangsbedingungen des Systems, die als Wahrheitswerte dargestellt werden (z.B. Schadenszahlung > 10.000€). Eine Wirkung ist die aus einer oder mehreren Ursachen hervorgerufene Ausgangsbedingung des Systems. Die Ursachen und Wirkungen werden mit ihren Beziehungen in einen Ursache-Wirkungs-Graphen übertragen. Bei einer Identität gilt: U ist wahr à W, bei der Negation gilt: U ist falsch à W. Die Kombination zweier Ursachen für eine gemeinsame Wirkung wird mittels logischer Operatoren (∧ = UND, ∨ = ODER) gekennzeichnet. Eine R-Abhängigkeit zwischen zwei Ursachen zeigt die Voraussetzung12 von U1 für U2. In der folgenden Abbildung sind die in dieser Arbeit verwendeten Notationen des Ursache-Wirkungs-Graphen zusammengefasst. Eine vollständige Übersicht samt Erläuterungen kann bei Liggesmeyer [vgl. Lig09, S. 68f] nachgeschlagen werden.. Abbildung 2-13: Ursache-Wirkungs-Graph Notation [vgl. Lig09, S. 68f] Der aufgestellte Graph bildet die Grundlage für eine Entscheidungstabelle. Die Ursachen sowie die Wirkungen bilden die Zeilen der Tabelle. Für alle Kombinationen von Ursachen werden die daraus resultierenden Wirkungen eingetragen. Um die gewünschte Reduzierung von Testfällen zu erreichen, werden Ursachen, die einen gleichen Sachverhalt darstellen, komprimiert. In der Tabelle 2-9 ist beispielsweise die Ausprägung von U2 irrelevant, sobald U1 falsch ist. Die Irrelevanz wird in einer komprimierten Entscheidungstabelle durch ein „-“ gekennzeichnet. Die Testfälle T1 bis T3 ergeben sich aus den Spalten der komprimierten Entscheidungstabelle.. 12. Auch engl.: Requires.

(35) Kapitel 2 - Umfeld der Arbeit. Ursachen. Ursachen. U1. N. N. J. J. U1. N. J. J. U2. J. N. J. N. U2. -. J. N. Wirkungen. Wirkungen. W1. J. J. N. N. W1. J. N. N. W2. N. N. J. N. W2. N. J. N. W3. N. N. N. J. W3. N. N. J. T2. T3. T1. T2. T3. T1. Tabelle 2-9: Entscheidungstabelle [Eigene Darstellung]. 2.2.2.2 Strukturorientierte Tests Strukturorientierte Tests ermitteln keine Testfälle gemäß der vorgegebenen Funktionalität laut Spezifikation, sondern sie bewerten die Abdeckung des Quellcodes durch zuvor aufgestellte Testfälle. Die Bewertung erfolgt entweder anhand des Kontrollflusses oder anhand des Datenflusses eines Programms. [vgl. Lig09, S. 40] Kontrollflussorientierte Tests Der Begriff Kontrollfluss bezeichnet die Verarbeitungslogik bzw. die Steuerung einer Software (Anweisungen, Zweige, Bedingungen oder Schleifen). Die Vollständigkeit des Testens wird anhand der Abdeckung der einzelnen Strukturen bewertet. Der Kontrollflussgraph ist eine gängige Darstellungsform für den Zusammenhang der Strukturen. In der Abbildung 2-14 ist ein Kontrollflussgraph zu einer Methode gegeben, die den Betrag aus einer Zahl ermittelt. [vgl. Lig09, S. 84] Die einfachste Form des kontrollflussorientierten Testens ist der Anweisungsüberdeckungstest. Dabei soll jede Anweisung in einem Programm mindestens einmal ausgeführt werden (alle Knoten im Graphen). Es wird sichergestellt, dass alle Anweisungen für sich korrekt sind. Zusätzlich lassen sich Anweisungen aufspüren, die niemals ausgeführt werden (sogenannter toter Code). [vgl. Lig09, S. 85ff] Eine Steigerung des Anweisungsüberdeckungstests ist der Zweigüberdeckungstest. Dieser fordert zusätzlich, dass jeder Programmzweig (alle Kanten im Graphen) min-.

(36) Kapitel 2 - Umfeld der Arbeit. destens einmal durchlaufen wird. Das bedeutet, dass zum Beispiel alle Entscheidungen sowohl für true als auch für false ausgeführt werden müssen. [vgl. Lig09, S. 88ff] Eine weitere Steigerung ist der Bedingungsüberdeckungstest, bei dem zusätzlich alle möglichen Kombinationen für verschachtelte bzw. zusammengesetzte Entscheidungen getestet werden. Damit lassen sich auch Fehler aufdecken, die nur aufgrund spezieller Testdatenkonstellationen hervorgerufen werden. [vgl. Lig09, S. 93ff] Die höchste Steigerung des kontrollflussorientierten Testens ist der erschöpfende Test. Dabei werden alle möglichen Eingaben zu allen möglichen Betriebssituationen getestet. Da diese Anzahl allerdings gegen unendlich gehen kann, ist der erschöpfende Test nicht praktikabel. [vgl. Lig09, S. 511]. Abbildung 2-14: Kontrollflussgraph [Eigene Darstellung] Datenflussorientierte Tests Jede Software enthält neben den Kontrollstrukturen auch Daten, die verarbeitet werden. Diese Datenverarbeitung (Lesen und Schreiben) innerhalb der Software wird auch als Datenfluss bezeichnet. Das datenflussorientierte Testen beurteilt die Testvollständigkeit daher anhand der Abdeckung der getesteten Datenzugriffe. [vgl. Lig09, S. 142f] Auf Variablen im Speicher kann wie folgt zugegriffen werden:.

(37) Kapitel 2 - Umfeld der Arbeit. Zugriff. Beschreibung. def. Schreibend13, z.B. x=1. c-use Lesend für eine Berechnung14, z.B. y=x+1 oder p-use. Lesend für eine Entscheidung15, z.B. if(x>0). Tabelle 2-10: Variablenzugriffe (Datenflussgraph) [Eigene Darstellung] Ein zuvor aufgestellter Kontrollflussgraph kann mit diesen drei Datenzugriffarten erweitert werden (def und c-use an den Knoten, p-use an den Kanten). [vgl. Lig09, S. 143] Die folgende Abbildung zeigt einen so entstehenden Datenflussgraphen zu der Betrag-Methode:. Abbildung 2-15: Datenflussgraph [Eigene Darstellung]. 13. Auch engl.: definition. 14. Auch engl.: computaional use. 15. Auch engl.: predicate use.

(38) Kapitel 2 - Umfeld der Arbeit. Die Beurteilung der Testvollständigkeit kann nun anhand der Abdeckung der drei Datenzugriffarten auf die Attribute erfolgen. Dabei gibt es unterschiedlich scharfe Kriterien, etwa ob alle defs, alle p-uses, alle c-uses oder die Kombinationen der Zugriffe abgedeckt sind. [vgl. Lig09, S. 147ff]. 2.2.2.3 Diversifizierende Tests Die diversifizierenden Tests beziehen sich auf verschiedene Versionen einer Software, welche beispielsweise durch mehrfache Realisierung oder durch Weiterentwicklung entstanden sind. Eine sehr bekannte und verbreitete Variante davon ist der Regressionstest. Dieser gleicht das Verhalten einer neuen Softwareversion gegen das Verhalten der vorherigen Version ab, indem alte Testfälle bei der neuen Version erneut ausgeführt werden. [vgl. Lig09, S. 42]. 2.2.3. Statische Prüftechniken Bei den statischen Analysen wird die zu prüfende Software nicht zur Ausführung gebracht. Von daher ist es auch nicht nötig, dass Testfälle erstellt bzw. ausgewählt werden. [vgl. Lig09, S. 43]. 2.2.3.1 Stilanalyse Bei der Stilanalyse wird der Quellcode einer Software auf die Einhaltung von Programmierkonventionen überprüft. Solche Konventionen haben die Absicht, die Lesbarkeit des Quellcodes zu gewährleisten sowie fehleranfällige Codekonstrukte im Vorfeld zu vermeiden. Inhaltlich werden syntaktische und semantische Programmierkonventionen unterschieden. [vgl. Lig09, S. 271] Syntaktische Programmierkonventionen Syntaktische Konventionen sind in der Regel Einschränkungen der zur Verfügung stehenden Programmiersyntax. Programmiersprachen bieten für Variablendefinitionen und -zuweisungen unterschiedliche Möglichkeiten an, diese in einer verkürzten Schreibweise zu implementieren. Die Verkürzung erschwert jedoch deutlich die Lesbarkeit, sodass viele Unternehmen diese Konstrukte in ihren Konventionen nicht erlauben. [vgl. Lig09, S. 272] Im folgenden Listing sind einige Beispiele gegeben:.

(39) Kapitel 2 - Umfeld der Arbeit. 01 02 03 04 05 06 07 08 09 10. // Verbotene Zuweisungen int x = 1, y = 2; y++; x += y; // Erlaubte Zuweisungen int x = 1, int y = 2; y = y + 1; x = x + y; Listing 2-2: Syntaktische Programmierkonventionen [Eigene Darstellung]. Ebenfalls zu den syntaktischen Konventionen zählen Vorschriften zum Formatieren des Quellcodes, wie etwa das Setzen von Klammern oder das Einrücken von Anweisungen. Eine Prüfung der syntaktischen Konventionen ist mit geringem Aufwand verbunden, da entsprechende Testwerkzeuge lediglich Symbole im Quellcode aufspüren müssen. [vgl. Lig09, S. 272] Semantische Programmierkonventionen Semantische Konventionen fordern die Nutzung von aussagekräftigen Benennungen sowie von Kommentaren. Gerade die Wartbarkeit des Programmcodes soll mit diesen Konventionen erhöht werden. So kann eine Vorschrift lauten, dass Methoden immer mit einem Verb anfangen. Eine Methode zum Suchen nach Kunden muss dann exemplarisch sucheKunde() benannt sein und nicht kundeSuchen(). Da ein Programm über seinen Lebenszeitraum von verschiedenen Entwicklern bearbeitet wird, sind Kommentare notwendig. Ein neuer Entwickler kann sich in ein kommentiertes Programm schneller einarbeiten. Die Prüfung von semantischen Konventionen kann nicht durch ein Testwerkzeug durchgeführt werden. Hier ist stets ein Mensch erforderlich, der den Inhalt bewerten kann. [vgl. Lig09, S. 272]. 2.2.3.2 Visuelle Hilfsmittel Ein Bild sagt mehr als tausend Worte. Diese Lebensweisheit gilt natürlich auch für die Softwareentwicklung, sodass die Verwendung von Grafiken, Diagrammen und Tabellen schon lange als unverzichtbare Hilfsmittel für Visualisierungen genutzt wer-.

(40) Kapitel 2 - Umfeld der Arbeit. den. Für die Entwicklung objektorientierter Software hat sich die Unified Modeling Language (UML) mit seiner Vielzahl an Diagrammtypen beispielsweise als de-facto Standard durchgesetzt. Auch die im Abschnitt 2.2.2.2 vorgestellten Kontroll- und Datenflussgraphen zählen zu den visuellen Hilfsmitteln. [vgl. Lig09, S. 276] Aus Sicht eines Entwicklers gibt es gleich zwei Gründe, welche die Verwendung von visuellen Hilfsmitteln zwingend notwendig machen. Zum einen erleichtern Diagramme und Grafiken die Kommunikation mit den (fachlichen) Auftraggebern. Selbst wenn beide Seiten - Informatik und Fachabteilung - dieselbe Sprache sprechen, können die jeweils verstandenen Inhalte stark voneinander abweichen. Die fachlichen und technischen Denkweisen sind einfach zu unterschiedlich. Daher ist es essentiell wichtig, bei der Zusammenarbeit eine Symbolik zu verwenden, die für beide Parteien dieselbe Semantik besitzt. Der zweite Grund ist der Wissenserhalt bzw. die Dokumentationsfunktion für Wartungs- und Weiterentwicklungsarbeiten. Ein Entwickler kann sich schneller in die Geschäftslogik und die Implementierung einarbeiten, wenn diese übersichtlich visualisiert ist. [vgl. Lig09, S. 276]. 2.2.3.3 Anomalieanalyse Eine Anomalie ist eine Abweichung vom Normalen. Im Bereich der Softwareentwicklung können Anomalien im Quellcode auftauchen. Doch nicht jede Softwareanomalie ist tatsächlich ein Softwarefehler. Die abweichenden Stellen enthalten zunächst nur ungewöhnliche bzw. auffällige Anweisungssequenzen, die auf einen Fehler hindeuten. Diese auffälligen Anweisungssequenzen aufzuspüren, ist das Ziel der Anomalieanalyse. Unterteilen lassen sich die Softwareanomalien in Kontrollfluss- und Datenflussanomalien. [vgl. Lig09, S. 292f] Kontrollflussanomalien Kontrollflussanomalien entstehen durch Bedingungen oder Schleifen. Die häufigste und wohl bekannteste Anomalie ist der unerreichbare Programmcode, der durch ifelse Konstrukte entstehen kann. In diesem Fall führt der unerreichbare Code zwar nicht zu Programmabbrüchen, es kann sich jedoch um einen Fehler handeln, weil der Entwickler entweder die Bedingungen falsch implementiert hat oder den unerreichbaren Code an einer falschen Stelle platziert hat. Moderne Entwicklungsumge-.

(41) Kapitel 2 - Umfeld der Arbeit. bungen beinhalten oft Funktionalitäten zur Aufdeckung von Kontrollflussanomalien und warnen den Entwickler etwa bei unerreichbarem Code. [vgl. Hof08, S. 313f]. Abbildung 2-16: Zustandsautomat Datenflussanomalien [vgl. Lig09, S. 295] Datenflussanomalien Bei der Datenflussanomalieanalyse werden die Variablenzugriffe etwas anders als bei dem Datenflussgraphen betrachtet. Die Verwendung einer Variablen wird, egal ob es sich um eine Berechnung oder einer Entscheidung handelt, zusammengefasst. Dafür wird die Undefinition als neue Zugriffsart aufgenommen (Tabelle 2-11). Die drei Zugriffsarten tauchen in einem Programm in verschiedenen Reihenfolgen auf. Ein konsistenter Datenfluss muss immer gemäß dem Zustandsautomaten in Abbildung 2-16 aufgebaut sein. In drei Fällen kann es demnach zu einer Anomalie kommen. Die dd-Anomalie (Variable wird zweimal hintereinander geschrieben) und duAnomalie (Variable wird geschrieben und dann gelöscht) deuten auf eine unsachgemäße Verwendung der Variablen hin. Die ur-Anomalie (undefinierte Variable wird verwendet) hingegen führt zu einem harten Programmabbruch. [vgl. Lig09, S. 292ff]. Zugriff. Beschreibung. d(x). Eine Variable wird mit jeder Wertzuweisung definiert, z.B. x=1. r(x). Der Wert einer Variablen wird verwendet, z.B. y=x+1 oder if(x>0). u(x). Die Variable wird undefiniert, z.B. Betreten oder Verlassen der Methode Tabelle 2-11: Variablenzugriffe (Datenflussanomalieanalyse) [Eigene Darstellung].

(42) Kapitel 2 - Umfeld der Arbeit. 2.2.3.4 Slicing Slicing ist vergleichbar mit dem Debugging, also der manuellen Fehlersuche nach dem Auftreten eines Fehlverhaltens. Ein Programmslice ist ein Ausschnitt aus dem Programmcode und hat das Ziel, alle Anweisungen zu identifizieren, die auf die Ausprägung eines betrachteten Attributs einwirken. Dieses Analysieren erfolgt rückwärts von der Stelle, an der die Ausprägung eines Attributes nachvollzogen werden soll. Ein Datenflussgraph ist hierbei der Ausgangspunkt. Von einer beliebig gewählten Variablen werden anschließend alle Knoten herausgesucht, die Einfluss auf die Variable haben. [vgl. Lig09, S. 285ff]. 2.2.3.5 Review Das manuelle Durchsehen und Prüfen vom Quellcode sowie aller für die Entwicklung einer Software relevanten Dokumente wird als Review bezeichnet. Die Grundidee ist dabei, dass eine Inspektion nicht vom Autor des zu prüfenden Objektes durchgeführt wird, sondern von unabhängigen Teilnehmern bzw. Kollegen. Neben der Qualitätssicherung ergeben sich außerdem noch die Vorteile des Wissensaustausches und der Verantwortungsteilung unter den Teilnehmern. [vgl. Lig09, S. 307] Die manuelle Durchführung ergibt gegenüber Testwerkzeugen einen immensen Vorteil. Ein Mensch kann die Semantik bzw. die inhaltlichen Aspekte des geprüften Objektes verstehen und bewerten. Die Nachteile von Inspektionen liegen allerdings ebenfalls in der Natur der manuellen Durchführung. Die Arbeit eines Menschen ist zum einen langsamer und teurer als die eines Werkzeuges und zum anderen neigt ein Mensch zur Unachtsamkeit. Das bedeutet, dass selbst wenn mehrere Menschen ein Dokument oder einen Quellcode inspiziert haben, trotzdem Fehler übersehen werden können. [vgl. Lig09, S. 306]. 2.2.3.6 Metriken Die Softwaremessung hat zum Ziel, die Eigenschaften einer Software zu quantifizieren. Anhand der so ermittelten Zahlen können dann qualitative Aussagen abgeleitet werden. Zwei bekannte und sehr einfache Maße für Software sind die Anzahl der Programmzeilen16 und die Anzahl der Funktionen. Mögliche Qualitätsaussagen anhand dieser beiden Maße sind beispielsweise die „Anzahl der Fehler pro Programm16. Auch engl.: Lines of Code.

(43) Kapitel 2 - Umfeld der Arbeit. zeilen“ oder aber das Prädikat „ausreichend getestet“, welches aus der prozentualen Testabdeckung abgeleitet wurde. [vgl. Lig09, S. 232f]. 2.2.3.7 Verifizierende Analysen Zu den verifizierenden Analysen gehören der symbolische Test und der formale Korrektheitsbeweis. Der symbolische Test ist eine Verallgemeinerung des dynamischen Tests. Dabei wird die Software auf einem abstrakten Niveau geprüft, indem symbolische Stellvertreter für konkrete Variablen aufgestellt werden. Die Anzahl der Testfälle wird gegenüber dem dynamischen Test drastisch verringert. Beim formalen Korrektheitsbeweis wird die Konsistenz zwischen Spezifikation und Implementierung ermittelt. Das setzt voraus, dass die Spezifikation in einer formalen Sprache vorliegt. [vgl. Lig09, S. 44f] Aufgrund mangelnder praktischer Bedeutung [vgl. Lig09, S. 358f] werden die formalen Analysen in dieser Arbeit nicht weiter berücksichtigt.. 2.2.4. Testen von Datenbanken Software besteht neben dem Programm an sich auch aus Daten und der entsprechenden Datenhaltung. Die bisher genannten (funktionalen) Prüftechniken beziehen sich allesamt auf das Testen von Programmen. Relationale Datenbanken sind bei der heutigen Softwareentwicklung der de-facto Standard für die Datenhaltung. Zum Testen von Datenbanken findet sie ähnlich wie zum Testen von DWS und BIS wenig Literatur. Ambler und Sadalage [vgl. Amb06, S. 29ff] gehen etwa kurz auf das Testen von Datenbankobjekten ein, benennen aber nur, was zu testen ist und geben keine praktischen Testtechniken an. Sneed et al. [vgl. Sne09, S. 123ff] beschreiben Techniken zum Prüfen von Datenbanktabellen. Die Idee hierbei ist, dass in eine Tabelle Testdaten eingetragen werden und somit ihre Struktur (Datentypen und Längen der Attribute) geprüft wird. Dabei ergeben sich gemessen an der Anzahl von Testdatensätzen vier Überdeckungstests: •. Satzüberdeckungstest o Für eine Tabelle existiert eine Datensatzausprägung.. •. Attributüberdeckungstest o Für jedes einzelne Attribut in einer Tabelle existieren mindestens zwei Datensatzausprägungen..