Releasespezifisches Verwalten von betreiberInnenspezifschen Steuerungsdaten auf Basis von...

FACHHOCHSCHULE DES BFI WIEN BACHELORSTUDIENGANG

Projektmanagement und Informationstechnik

LEHRVERANSTALTUNG: SEMINAR IT

B A C H E L O R A R B E I T

Releasespezifisches Verwalten von betreiberInnenspezifschen Steuerungsdaten auf Basis von Klartext-Datenspeichern

Fachbereich: Informationstechnologie Eingereicht von: Sebastian Kopf Personenkennzeichen: 1110387012 Anschrift: Rabensburgerstrasse 17/3, 1020 Wien Betreuer: Dipl. Ing. Thomas Havelka Erhalter: Fachhochschule des BFI Wien GmbH Wohlmutstraße 22 1020 Wien Wien, 29.06.2014

1110387012– Sebastian Kopf

I

Eidesstattliche Erklärung Ich versichere,

dass ich die Regeln des wissenschaftlichen Arbeitens eingehalten habe, insbe-

sondere, dass ich die Diplomarbeit selbständig verfasst und mich anderer als der

im beigefügten Literaturverzeichnis angegebenen Quellen nicht bedient habe. Alle

Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen entnommen wurden,

sind als solche kenntlich gemacht. Ich versichere weiters, dass ich diese Diplom-

arbeit bisher weder im Inland noch im Ausland in irgendeiner Form als Prüfungs-

arbeit vorgelegt habe.

Mir ist bewusst, dass auch nach positiver Beurteilung der Diplomarbeit die Aufde-

ckung eines Verstoßes gegen die Regeln des wissenschaftlichen Arbeitens (ins-

besondere bei Vorliegen eines Plagiats) die Einleitung eines Verfahrens zur Nich-

tigerklärung der Beurteilung sowie des akademischen Grades zur Folge hat.

________________ ___________________ Datum Unterschrift


II

Einverständniserklärung

Mit meiner Unterschrift räume ich der FH des bfi Wien GmbH das weltweite, zeitlich und örtlich unbegrenzte Nutzungsrecht ein, meine Bachelor-/Diplomarbeit auf einer Internetplattform zur Verfügung zu stellen (iSd § 18a UrhG) und für Lehrzwecke zu vervielfältigen.

Ich bin weiters damit einverstanden, dass meine Bachelor-/Diplomarbeit von der FH des bfi Wien GmbH bei Prämierungsveranstaltungen bzw. –bewerben (wie z.B. „Best-paper-Award“) nach Rücksprache mit dem Autor/der Autorin bzw. den AutorInnen eingereicht wird.

_____________________________ Unterschrift des/der Autors/in

Wien, _________________


III

Inhaltsverzeichnis

1 Einleitung .............................................................................................................. 11.1 Relevanz der Themenstellung ......................................................................... 11.2 Forschungsfrage ............................................................................................. 41.3 Stand und kritische Reflexion der Literatur ..................................................... 41.4 Methodische Vorgangsweise .......................................................................... 51.5 Aufbau der Arbeit ............................................................................................ 51.6 Definitionen ..................................................................................................... 5

2 Konfigurationsmanagement ............................................................................... 82.1 Grundlagen von Konfigurationsmanagement .................................................. 82.2 Artefakte der Softwareentwicklung unter Konfigurationsmanagement ........... 92.3 Gründe für den Einsatz von Konfigurationsmanagement ............................. 102.4 Tätigkeiten im Konfigurationsmanagement ................................................... 12

2.4.1 Baselines etablieren ............................................................................... 122.4.2 Änderungen verfolgen und lenken .......................................................... 142.4.3 Integrität etablieren ................................................................................. 14

2.5 Herausforderungen im Einsatz von Konfigurationsmanagement .................. 153 Versionsverwaltungssysteme .......................................................................... 174 Datenbankbasierte Verwaltung von BetreiberInnen-spezifischen

Steuerungsdaten .............................................................................................. 214.1 Grundlagen Datenbanken ............................................................................. 214.2 Funktionsweise von Datenbanken ................................................................ 224.3 Konventionelle Datenbanken ........................................................................ 234.4 Temporale Datenbanken ............................................................................... 234.5 Anforderungen des Konfigurationsmanagements von betreiberInnenspezifischer Software an datenbankbasierte Verwaltungen von Steuerungsdaten .................................................................................................... 244.6 Erfüllung der Anforderungen des Konfigurationsmanagements von Steuerungsdaten in datenbankbasierten Applikationen ........................................ 26

5 Alternative Verwaltungsmöglichkeiten von betreiberInnen-spezifischen Steuerungsdaten .............................................................................................. 27

5.1 Auszeichnungssprache Extensible Markup Language (XML) ....................... 275.1.1 Grundlagen von XML .............................................................................. 275.1.2 Aufbau von XML ..................................................................................... 285.1.3 XML Dokumenttyp Definition und XML-Schema .................................... 295.1.4 XML-Daten ............................................................................................. 305.1.5 Anwendungsgebiete von XML ................................................................ 315.1.6 Erfüllung der Konfigurationsmanagement-Anforderungen von Steuerungsdaten in datenbankbasierten Applikationen verwaltet in XML ......... 32

5.2 Domain Specific Language ........................................................................... 335.2.1 Grundlagen von DSL .............................................................................. 33


IV

5.2.2 Anwendungsgebiete von DSL ................................................................ 355.2.3 Erfüllung der Konfigurationsmanagement-Anforderungen von Steuerungsdaten in datenbankbasierten Applikationen verwaltet in DSL .......... 36

5.3 Vergleich von DSL und XML als Grundlage für die Verwaltung von Steuerungsdaten .................................................................................................... 36

6 Conclusio ............................................................................................................ 387 Literaturverzeichnis ........................................................................................... 40


V

Darstellungsverzeichnis Nr. Bezeichnung Seite Darstellung 1: Durch Konfigurationsmanagement verwaltete Softwarebestandteile................................................................................................................................. 2Darstellung 2: Versions/Release-Entwicklung SoftwareherstellerIn versus BetreiberIn ............................................................................................................... 3Darstellung 3: Überblick Aktivitäten des Konfigurationsmanagements ................. 9Darstellung 4: Einfache Darstellung einer versionierten Datei ............................ 17Darstellung 5: Vereinfachter Änderungsworkflow von Steuerungsdaten mit Git . 20Darstellung 6: Applikationsarchitektur einer datenbankbasierten Software ........ 25Darstellung 7: Beispiel eines XML ....................................................................... 28Darstellung 8: Beispiel eines DTD von Projektdaten ........................................... 29Darstellung 9: XML-Schema der Projektdaten .................................................... 30Darstellung 10: Baumstruktur eines XML-Kontaktdokuments ............................. 31


VI

Tabellenverzeichnis Nr. Bezeichnung Seite Tabelle 1: Operationen von Versionsverwaltungssystemen ................................. 19


VII

Abkürzungsverzeichnis CMMI Capability Maturity Model Integration DBMS Datenbankmanagementsystem HTML Hypertext Markup Language IEC International Electrotechnical Commission ISO International Organization for Standardization ITIL Information Technology Infrastructure Library SACM Service Asset and Configuration Management SGML Standard Generalized Markup Language SPICE Software Process Improvement and Capability Determination SQL Structured Query Language UML Unified Modeling Language XHTML Extensible HyperText Markup Language XML Extensible Markup Language


VIII

Abstract

Configuration Management is the discipline to manage and control assets needed to de-

liver software or services. Configuration data, which changes the runtime behaviour of an

application during its operation, is part of the assets controlled via configuration manage-

ment. Changing the runtime behaviour in a running application is risky because of possi-

ble unwanted effects. It is therefore necessary to reduce the risk of such effects happen-

ing in a production environment. Configuration data in database-based applications is

difficult to manage in respect to the requirements of formal configuration management.

Without various processes to support the management of configuration data, instead of

just changing it, these applications are not capable to properly administer changing con-

figuration data. This thesis analysis the effects of database managed configuration data in

respect to the requirements of configuration management. In addition it investigates text-

based alternatives to manage the configuration data in collaboration with version control

software. The research is done in published literature, different papers and various web

based sources. Results show that XML-based management of configuration data with

support of version control software is able to fulfil the requirements of formal configuration

management. Database managed configuration data is either flawed or requires additional

effort to implement the necessary features. These outcomes can be used to study the

needs for an integrated software solution which supports the management of configuration

data for external database based applications.


1

1 Einleitung 1.1 Relevanz der Themenstellung In den letzten Jahren haben sich die Möglichkeiten und die Innovationsfähigkeiten

der Softwaretechnologie schneller entwickelt als die Fähigkeiten von Softwareent-

wicklungsfirmen, die Komplexität der Probleme in der Entwicklung und im Betrieb

zu managen. Dadurch wird ihr Vermögen, zuverlässige und verwendbare Software

innerhalb des vorgegebenen Budgets und den vorgegebenen Termin zu entwi-ckeln, weiter beeinträchtigt. 1

Hinzu kommt die Schwierigkeit, komplexe Software auf die unterschiedlichen Be-

dürfnisse eines/einer BetreiberIn zuzuschneiden. Anstatt die Software je nach Be-

treiberIn mit unterschiedlichen Funktionen im Quellcode auszustatten, wird die

gleiche Funktionalität an alle BetreiberInnen ausgeliefert. Die unterschiedlichen

Bedürfnisse werden mittels vom/von der BetreiberIn setzbaren Steuerungsdaten

(in einer Datenbank gespeichert) zufriedengestellt. Diese Steuerungsdaten ändern

das Verhalten der Applikation während der Laufzeit entsprechend den Bedürfnis-sen des/der BetreiberIn.

Durch diese Variabilität der Applikation treten verschiedene Schwierigkeiten auf.

Zum einen sind Änderungen an den Steuerungsdaten einer Software während des

Betriebes ein großes Risiko. Dabei muss sichergestellt werden, dass nur qualifi-

ziertes und autorisiertes Personal in der Lage ist, solche Änderungen durchzufüh-

ren. Zum anderen besteht die Notwendigkeit, die Veränderungen dieser Steue-

rungsdaten zu dokumentieren, um im Falle von Softwarefehlern oder anderen An-

lässen (z.B. risikoreiche Konfigurationsänderungen) die Nachvollziehbarkeit zu gewährleisten.

In Darstellung 1 wird ein schematischer Überblick eines Softwareprodukts abgebil-

det. Dabei unterteilt sich die Software auf oberster Ebene in die unterschiedlichen Module sowie den Datenspeicher für Steuerungsdaten.

1 Vgl. Keyes (2004) o.S.


2

Darstellung 1: Durch Konfigurationsmanagement verwaltete Softwarebestandteile2

Innerhalb der Module wird in unterschiedliche Code-Arten weiter unterteilt. Diese

sind:

• Quell-Code,

• kompilierter Code (Resultat der Übersetzung aus dem Quell-Code in ein

maschinenlesbares Ergebnis)3 und

• ausführbarer Datei (durch Verlinken der kompilierten Module erzeugte aus-führbare Datei) 4

Weiters werden die Abhängigkeiten zwischen den Modulen und die Verwendung

von Steuerungsdaten in den Modulen dargestellt. Im Rahmen des Lebenszyklus

einer Software sind alle diese Bestandteile einer fortlaufenden Veränderung unter-

zogen. Mit Ausnahme der Steuerungsdaten sind alle diese Bestandteile dem

Softwareentwicklungsprozess unterworfen. Die durch die KundInnen veränderba-

ren Daten sind vom regulären Entwicklungsvorgehen und dessen Verwaltung

2 Eigene Darstellung nach Quelle: Conrardi/Westfechtel (1998) S. 237. 3 WhatIs (2014) online. 4 Allain (2014) online.


3

ausgenommen, da das Laufzeitverhalten der Software im Rahmen des Betriebes

angepasst und verändert werden kann.

Um diese Problemstellung/Thematik besser zu illustrieren, ist in Fehler! Verweis-quelle konnte nicht gefunden werden. ein beispielhaftes Versions- bzw. Relea-

sediagramm abgebildet. Im Rahmen des Entwicklungsprozesses wird angenom-

men, dass der/die HerstellerIn verschiedene Versionen der Software und des

Quellcode-Standes hält. Das konkrete Beispiel zeigt, dass von der HerstellerIn-

nen-Version 2.1.0 die Baseline (Ausgangsversion) der Betriebsinstallation erstellt

wird. Diese Version beinhaltet einen vom/von der HerstellerIn definierten Zustand

der Steuerungsdaten. Veränderungen in der Betriebsinstallation (z.B. Version 3.0

der BetreiberIn) werden durch Anpassungen in den Steuerungsdaten hervorgeru-

fen.

Darstellung 2: Versions/Release-Entwicklung SoftwareherstellerIn versus BetreiberIn5

5 Eigene Darstellung


4

Als weiteren Anwendungsfall kann das Auftreten eines Fehlers im Test der Be-

triebsinstallation Version 3.0 dargestellt werden. Damit der/die HerstellerIn den

konkreten Zustand der Software beim Auftreten des Fehlers beurteilen kann, wer-

den die Steuerungsdaten an den/die Hersteller übermittelt. Durch diesen Informa-

tionstransfer ist es dem/der HerstellerIn möglich, eine betriebsspezifische Version

2.1.0.K in der eigenen Versions/Release-Verwaltung zu erstellen.

Die Verwaltung dieser Art von kritischen Daten ist Aufgabe des Konfigurations-managements. Konfigurationsmanagement definiert die Aufgaben und Anforde-rungen, die an die Administration solcher Daten gestellt werden.

Diese Arbeit untersucht die Anforderungen die Konfigurationsmanagement an die

Verwaltung der Steuerungsdaten von datenbankbasierten Applikationen hat und

versucht Lösungsmodelle aufzuzeigen, um diese Anforderungen zu erfüllen.

1.2 Forschungsfrage Die in der Einleitung beschriebenen Problemstellungen konnte der Autor in der

Praxis häufig beobachten. Der Wunsch, dieses Problem besser zu strukturieren

sowie das Bedürfnis zu einer Besserung beizutragen, haben zu den folgenden

Forschungsfragen geführt:

Forschungsfrage 1:

Wie kann eine releasespezifische Verwaltung datenbankbasierter Steuerungsda-

ten durch den Einsatz eines Klartext-Datenspeichers im Hinblick auf die Anforde-

rungen aus Software-Konfigurationsmanagement abgelöst werden?

Unterfrage 1:

Welche Probleme treten im Zusammenhang mit dem releasespezifischen Verwal-

ten von datenbankbasierten Steuerungsdaten auf?

1.3 Stand und kritische Reflexion der Literatur Konfigurationsmanagement als Methode wird in verschiedenen Management

Standards und Reife-Grad Modellen beschrieben. Im Hinblick auf Konfigurations-management weichen die Standards nur sehr gering von einander ab.


5

1.4 Methodische Vorgangsweise Die Auswahl der Literatur erfolgt nach Relevanz im Bezug auf die gestellten For-

schungsfragen. Die Relevanz wird anhand des Abstracts oder der Volltexte beur-

teilt. Verwendet werden Artikel aus verschiedenen Publikation und Werken zu den

Themen Domain Specific Language, Configuration Management und Software

Configuration Management.

Um die Forschungsfragen zu klären, wird eine qualitative Inhaltsanalyse der aus-

gewählten Literatur durchgeführt. Dabei wird nur Primärliteratur verwendet.

Die Literaturrecherche wird sowohl online als auch in Bibliotheken durchgeführt.

Die Onlinerecherche wird für die Erhebung aller Artikel und Webseiten durchge-

führt. Hierfür werden die Suchmaschinen von Google Scholar, Emerald, Science-

Direct, Wiley Online Libary sowie Google verwendet. Die Recherche der weiteren

Werke erfolgt in den Bibliotheken der Wirtschaftsuniversität Wien, der Fachhoch-

schule des bfi Wien und der technischen Universität Wien.

1.5 Aufbau der Arbeit Nach der Einleitung und den allgemeinen Definitionen in Kapitel 1 werden in die-

ser Arbeit in Kapitel 2 zuerst die Grundlagen und Anforderungen von Konfigurati-

onsmanagement dargelegt. Im Anschluss wird in Kapitel 3 die Funktionalität und

Funktionsweise von Versionsverwaltungssoftware erläutert und den Bezug zu

Konfigurationsmanagement hergestellt. Das Kapitel 4 erläutert die Ausgangslage

der datenbankbasierten Verwaltung von Steuerungsdaten. In Kapitel 5 wird auf

die alternativen Verwaltungsmöglichkeiten von Steuerungsdaten eingegangen und

auf ihre Eignung im Hinblick auf die Anforderungen aus Konfigurationsmanage-ment untersucht. Die Conclusio erfolgt abschließend in Kapitel 6.

1.6 Definitionen Konfigurationsmanagement: Für Konfigurationsmanagement gibt es viele Definitionen in Managementstan-

dards oder Reifegrad-Modellen. In dieser Arbeit werden aufgrund des Software

Fokus die weit verbreiteten Reifegrad-Modelle Capability Maturity Model Integrati-

on (CMMI) und Software Process Improvement and Capability Determination

(SPICE) verwendet. Für den Betrieb wird teilweise noch das Service-Framework

der Information Technology Infrastructure Library (ITIL) verwendet.

CMMI definiert Software Konfigurationsmanagement wie folgt:


6

„Disziplin der technischen und administrativen Leitung und Aufsicht für (1) Identifikation und Dokumentation der funktionalen und physi-kalischen Eigenschaften von Konfigurationseinheiten, (2) Steuerung der Änderungen dieser Eigenschaften, (3) Aufzeichnung und Be-richterstattung zur Änderungsbearbeitung und des Umsetzungssta-tus und (4) Verifizierung der Erfüllung der festgelegten Anforderun-gen.“6

Nach SPICE ist Konfigurationsmanagement definiert:

„The purpose of the Configuration management process is to estab-lish and maintain the integrity of all the work products of a process or project and make them available to concerned parties.“7

Die Information Technology Infrastructure Library definiert Konfigurationsma-nagement folgendermaßen:

„The purpose of the SACM process is to ensure that the assets re-quired to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the as-sets have been configured and the relationships between assets.“8

Steuerungsdaten: „Daten, die das [..] System benötigt, um die verschiedenen Verarbeitungen ent-

sprechend den Anforderungen des Anwenders [sic!] durchführen zu können.“9

Software Process Improvement and Capability Determination (SPICE): SPICE ist ein Reifegrad-Modell des Verbands der Automobilindustrie zur Bewer-

tung von Softwarezulieferern. Das Modell basiert auf dem ISO-Standard ISO/IEC 15504-2. 10

Capability Maturity Model Integration (CMMI): CMMI ist ein Reifegrad-Modell des Software Engineering Institute zur Bewertung

von Softwareentwicklungsorganisationen.

Das Software Engineering Institute definiert CMMI wie folgt:

„CMMI für Entwicklung umfasst gute Praktiken für die Entwicklung und Pflege von Produkten und Dienstleistungen sowie Praktiken, die den gesamten Lebenszyklus eines Produkts von der Konzeption über die Lieferung bis hin zur Pflege abdecken. Dabei liegt der

6 Software Engineering Institute (2010) S. 454. 7 Verband der Automobilindustrie (2007) S. 62. 8 Cabinet Office (2011) S. 89 f. 9 SAP Knowledge Warehouse (2014) online. 10 Vgl. Verband der Automobilindustrie (2010) S. 8.


7

Schwerpunkt auf der Arbeit, die in die Entwicklung und Instandhal-tung des Endprodukts fließt.“11

Versionsverwaltung: Versionsverwaltung ist ein System, das Änderungen an einer Datei oder einem

Satz von Dateien im Zeitablauf aufzeichnet, um später auf spezifische Version der Datei(en) zugreifen zu können.12

Baseline: „Baselines stellen eine stabile Basis für die kontinuierliche Weiterentwicklung von

Konfigurationseinheiten dar.“13

11 Software Engineering Institute (2010) S. 15. 12 Vgl. Chacon (2009) S. 1. 13 Software Engineering Institute (2010) S. 151.


8

2 Konfigurationsmanagement In diesem Kapitel werden die Grundlagen des Konfigurationsmanagements ausge-

führt und die Anforderungen in Bezug auf die Verwaltung von Arbeitsergebnissen der Softwareentwicklung und dem Betrieb von Software aufgezeigt.

2.1 Grundlagen von Konfigurationsmanagement Konfigurationsmanagement betrachtet die einzelnen Teile des Systems sowie das

System als Ganzes. Es wird sichergestellt, dass alle Informationen über eine

Software in Teilen oder als Ganzes vollständig, korrekt und zuverlässig sind. Wei-

ters wird die Verfügbarkeit dieser Informationen gewährleistet. Die Informationen

beschreiben die Details der Teile und des Ganzen sowie deren Konfigurations-

stand und deren Beziehungen untereinander.14 Das Konfigurationsmanagement dient dadurch der Etablierung der Integrität von Arbeitsergebnissen.15

Die Bestandteile von Konfigurationsmanagement sind in der betrachteten Literatur

zu großen Teilen übereinstimmend. Sie werden in unterschiedlichen Detailie-

rungsgraden ausgeführt. Die Hauptbestandteile sind jedoch übergreifend einheit-

lich. In den Reifegrad-Modellen Capability Maturity Model Integration (CMMI) und

Software Process Improvement and Capability Determination (SPICE) werden die folgenden Bestandteile aufgelistet:16

• Definition der Konfiguration ausgewählter Arbeitsergebnisse zur Erstellung der Baselines zu definierten Zeitpunkten.

• Steuerung von Anpassungen an Konfigurationseinheiten

• Bereitstellung von Spezifikationen zur Erstellung von Arbeitsergebnissen

aus dem Konfigurationsmanagementsystem

• Erhaltung der Baslineintegrität

• Statusreporting der Konfigurationsdaten für bestimmte Abnehmer wie Ent-

wicklerInnen, EndanwenderInnen und KundInnen.

Darstellung 3 zeigt einen Überblick über die Aktivitäten des Konfigurationsmana-gements und seine Zusammenhänge: 14 Vgl. Cabinet Office (2011) S. 89 f.; anders Software Engineering Institute (2010) S. 150; anders

Hass (2003) o.S. 15 Vgl. Software Engineering Institute (2010) S. 150; anders Cabinet Office (2011) S. 90 16 Vgl. Software Engineering Institute (2010) S. 151; übereinstimmend Verband der Automobilin-

dustrie (2010) S. 63 f.


9

Darstellung 3: Überblick Aktivitäten des Konfigurationsmanagements17

2.2 Artefakte der Softwareentwicklung unter Konfigurationsma-nagement

Im Rahmen des Konfigurationsmanagements können verschiedene Konfigurati-onselemente unter die Verwaltung gestellt werden.

Ein Konfigurationselement ist jeder mögliche Bestandteil der Entwicklung oder

Lieferung eines Systems oder Produkts, für den es notwendig ist, ihn zu identifizie-

ren, herzustellen, zu speichern, zu verwenden und individuell zu ändern.18

Ein Software Objekt als Element von Konfigurationsmanagement enthält das Re-

sultat einer Entwicklungs- oder Wartungsaktivität.19 Dabei wird aber nicht nur der

17 Hass (2003) o.S. 18 Vgl. Hass (2003) o.S.

Chapter 1. Definition of Configuration Management Used in This Book

There are many definitions of configuration management and many opinions on what it really is. This chapter describes the definition on which this book is based. In short:

Configuration management is unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components, and products during the life of a system.

Figure 1-1 shows the activity areas included in the definition of configuration management used in this book. It also shows their relations to each other, to common data, and to elements outside the configuration management process area.

Figure 1-1. Overview of Configuration Management Activities

When you work professionally with configuration management (as with anything else) it's important to have the fundamental concepts in place. If all else fails, you can go back and seek a solution there.

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.


10

Programm-Quellcode als relevant betrachtet.20 Die Arten von Software Objekten

unter Konfigurationsmanagement beinhalten auch unter anderem: 21

• die Anforderungs-Spezifikation

• Designs

• Dokumentation

• Programm-Quellcode

• Testpläne

• Testfälle

• Benutzerhandbücher

• Projektpläne

• Steuerungsdaten22

Es werden aber nicht nur diese Elemente überwacht, sondern auch deren Bezie-

hungen zueinander.23

2.3 Gründe für den Einsatz von Konfigurationsmanagement Konfigurationsmanagement kann existenziell im Softwareentwicklungsprozess eingesetzt werden.24 Das Reifegrad-Modell CMMI führt hierzu an:

„Konfigurationsmanagement ist auf die rigorose Lenkung von betrieb-lichen und technischen Aspekten von Arbeitsergebnissen, ein-schließlich des gelieferten Produkts oder der Dienstleistung, gerich-tet.“25

Damit sich MitarbeiterInnen speziell in agilen Umgebungen nicht festfahren, ent-

steht die Anforderung häufiger Änderungen und Produktionsläufe, sowie verschie-

de Baselines und vielfältige Arbeitsräume (z.B. für Einzelpersonen oder Teams)

unterstützen zu können.26 Agile Umgebungen bezieht sich auf die Projektabwick-

lung beim Softwareerstellungsprozess und legen den Schwerpunkt auf kurze Ent-

19 Vgl. Conrardi/Westfechtel (1998) S. 235. 20 Vgl. Hass (2003) o.S. 21 Vgl. Conrardi/Westfechtel (1998) S. 235; anders Verband der Automobilindustrie (2010) S. 63. 22 Vgl. Verband der Automobilindustrie (2010): S. 63. 23 Vgl. Conrardi/Westfechtel (1998) S. 236. 24 Vgl. Hass (2003) o.S. 25 Software Engineering Institute (2010) S. 152. 26 Vgl. Software Engineering Institute (2010) S. 152.


11

wicklungszyklen und die inkrementelle Lieferung der Ergebnisse, basierend auf

veränderbare Anforderungen der KundInnen. 27

Konfigurationsmanagement beantwortet somit folgende Fragen für individuelle

Komponenten oder ganze Produkte:28

• Wer bin ich?

• Warum bin ich hier?

• Warum bin ich, wer ich bin?

• Wo gehöre ich dazu?

Die Möglichkeit, diese Fragen über den gesamten Lebenszyklus eines Software-produktes zu beantworten, erhöht die Qualität des Produktes.29

A. M. J. Hass fasst konkret die folgenden Vorteile aus dem Einsatz von Konfigura-tionsmanagement zusammen:30

• Ermöglicht die Behebung des gleichen Fehlers an mehreren Stellen

• Keine Entwicklung auf Basis einer falschen Grundlage durchführen (z.B.

veraltete Anforderungen)

• Kein Wiederauftreten bereits behobene Fehler

• Keine Einführung unerwünschter Funktionalität

• Ausschließen von Unwissen über die an KundInnen verteilte Produktversi-

on

• Keine unerwünschten Kosten bei der Aktualisierung aufgrund von Inkompa-tibilitäten mit alter Infrastruktur

• Keine Redundanzen bei der Programmierung

• Keine Probleme beim Wissenstransfer zu neuen MitarbeiterInnen

J. Keyes ergänzt diese Vorteile noch um die folgenden Punkte:31

• Nachvollziehbarkeit der Anforderungen bis zum Produkt

• Beschränkung der Haftbarkeit durch die Aufzeichnung aller Daten

27 Vgl. eHow (2014) online. 28 Vgl. Hass (2003) o.S. 29 Vgl. Hass (2003) o.S. 30 Vgl. Hass (2003) o.S. 31 Vgl. Keyes (2004) o.S.


12

• Hilft bei der Reduktion der Lebenszyklus Kosten der Softwarewartung

• Erlaubt Verantwortlichkeiten zur Quellen zurückzuverfolgen

• Bietet einen konstante Übereinstimmung mit den Anforderungen von Kun-dInnen

• Bietet eine stabile Umgebung, um den Softwareentwicklungsprozess zu de-

finieren, zu wiederholen und zu verbessern

• Erweitert die Einhaltung von angewendeten Standards

• Bietet eine Umgebung, in der sinnvolle Messungen durchgeführt und ver-

wendet werden können

• Erweitert die Möglichkeiten der Statusauswertung

• Bietet einfache Möglichkeiten zur Berichtsgenerierung

• Erlaubt ein schnelles und einfaches Auditing

• Schafft die Möglichkeit, die Umstände zu reproduzieren, unter welchen ein

Produkt erstellt wurde

• Fördert die Fähigkeit zur Verbesserung ohne Schuldzuweisungen

• Bietet die Fähigkeit festzustellen, wann ein Produkt fertig zum Release ist.

2.4 Tätigkeiten im Konfigurationsmanagement In diesem Kapitel werden die einzelnen Tätigkeiten des Konfigurationsmanage-

ments nach CMMI und SPICE behandelt.

2.4.1 Baselines etablieren Im Rahmen der Etablierung der Baseline werden die Tätigkeiten „Änderungen verfolgen und lenken“ und „Integrität etablieren“ durchgeführt. „Änderungen

verfolgen und lenken“ (Kapitel 2.4.2) dient dazu, die Baseline an Änderungen an-

zupassen. „Integrität etablieren“ (Kapitel 2.4.3) dient dazu, die Integrität der Base-line zu dokumentieren und auditieren.32

Das Einfügen der Baselines in das Konfigurationsmanagementsystem erfolgt ent-

sprechend dem Entwicklungsfortschritt. Veränderungen an Baselines und das er-

stellen von Auswertung werden systematisch gelenkt und überwacht. Beispiele für

32 Vgl. Software Engineering Institute (2010) S. 153.


13

eine Baseline sind Nachverfolgbarkeitsmatrizen von Arbeitsergebnissen, wider-

spruchsfreie Anforderungen oder auch AnwenderInnendokumentationen. 33

Im Zuge der Tätigkeit „Baselines etablieren“ fallen folgende Aufgaben an:

• Konfigurationseinheiten festlegen Bei der Etablierung der Baseline müssen die Konfigurationseinheiten fest-

gelegt werden. Dies zielt darauf ab, die Bestandteile und zugehörigen Ar-

beitsergebnisse festzusetzen, die unter Konfigurationsmanagement gestellt

werden sollen.34

Ergänzend zu dem unter Kapitel 2.2 aufgeführten Punkte werden noch wei-

ters ausgewählt und spezifiziert:35

- die ausgelieferten Produkte

- ausgewiesene interne Arbeitsergebnisse

- zugekaufte Produkte

- Werkzeuge und Investitionsgüter der Projektarbeitsumgebung

- Andere Gegenstände, die zur Erzeugung und Dokumentation der Arbeits-

ergebnisse verwendet werden.

• Konfigurationsmanagementsysteme etablieren Im Zuge der Festlegung von Konfigurationseinheiten ist es auch notwendig

ein System zu definieren, in dem die Artefakte verwaltet werden. Hier wer-

den sowohl die Speichermedien als auch die Verfahren und Werkzeuge für

den Zugriff definiert.36

• Baselines erstellen und freigeben Die Baseline wird durch die Vergabe eines eindeutigen Bezeichners (an

einzelne Konfigurationseinheiten oder an eine Gruppe) zu einem definierten

Zeitpunkt dargestellt.37 Die erstellten Baselines können sowohl intern ver-

wendet werden, als auch an den KundInnen ausgeliefert werden.38

33 Vgl. Software Engineering Institute (2010) S. 151. 34 Vgl. Software Engineering Institute (2010) S. 153; anders Verband der Automobilindustrie (2010)

S. 63. 35 Vgl. Software Engineering Institute (2010) S. 153 f.; anders Verband der Automobilindustrie

(2010) S. 63. 36 Vgl. Vgl. Software Engineering Institute (2010) S. 155; übereinstimmend Verband der Automobil-

industrie (2010) S. 64. 37 Vgl. Software Engineering Institute (2010) S. 156. 38 Vgl. Software Engineering Institute (2010) S. 156; übereinstimmend Verband der Automobilin-

dustrie (2010) S. 64.


14

2.4.2 Änderungen verfolgen und lenken Die hier durchgeführten Tätigkeiten verfolgen und lenken die Arbeitsergebnisse

unter Konfigurationsmanagement.39 Es werden hier die folgenden Aufgaben wahr-

genommen:

• Änderungsanträge verfolgen

Bei der Verfolgung von Änderungsanträgen werden nicht nur neue oder an-

gepasste Anforderungen berücksichtigt, sondern auch Fehler in Arbeitser-

gebnissen. Die Änderungsanträge werden beurteilt, um Folgen der Ände-

rung auf die Ergebnisse, das Budget und den Projektplan zu ermitteln.40

• Änderungsanträge lenken

Die Lenkung der Änderungsanträge bezieht sich auf die dauerhafte Verfol-

gung der Konfigurationen sowie allenfalls der Freigabe einer neuen Version

und damit die Aktualisierung der Baseline.41

2.4.3 Integrität etablieren Bei der Etablierung der Integrität der Baseline wird sichergestellt, dass die Integri-

tät der Baseline auch durch die in Kapitel 2.4.1 und 2.4.2 angeführten Tätigkeiten erhalten bleibt.42 Hierfür fallen folgende Schritte an:

• Aufzeichnungen zum Konfigurationsmanagement etablieren

Hierbei wird sichergestellt, dass die durchgeführten Änderungen auch do-

kumentiert und verfügbar sind.43

• Konfigurations-Audits durchführen

Konfigurations-Audits belegen die Einhaltung von spezifizierten Standards

oder Anforderungen, der Baselines und deren Dokumentation.44 Es über-

39 Vgl. Software Engineering Institute (2010) S. 157. 40 Vgl. Software Engineering Institute (2010) S. 157; übereinstimmend Verband der Automobilin-

dustrie (2010) S. 64. 41 Vgl. Software Engineering Institute (2010) S. 158; übereinstimmend Verband der Automobilin-




dustrie (2010) S. 64.


15

prüft, ob die Baseline und die Dokumentation den Anforderungen entspre-

chen oder einen definierten Standard einhalten.45

2.5 Herausforderungen im Einsatz von Konfigurationsmanage-ment

Wenn sich eine Organisation dazu entscheidet Konfigurationsmanagement einzu-

setzen, entstehen hierbei eine Reihe von Herausforderungen. Häufig wird davon

ausgegangen, dass Konfigurationsmanagement sowohl alle Ressourcen ver-

braucht als auch die Kreativität der MitarbeiterInnen unterdrückt. Es ist somit bei jedem Einsatz von Konfigurationsmanagement die Angemessenheit zu prüfen.46

Im Speziellen sind folgende Punkte bei der Definition des Umfangs von Konfigura-tionsmanagement zu beachten:47

• Granularität Bei der Granularität gilt es zu beachten, auf welcher Ebene Änderungen an

den Artefakten erfolgen. Ein Beispiel hierfür wäre die Granularität von An-

forderungen. Wird eine Anforderungsspezifikation verfasst, so ist es nicht

sinnvoll, das gesamte Dokument als einzelnes Konfigurationselement zu

definieren, wenn sich einzelne Anforderungen unabhängig von einander

ändern können. Ein weiteres Beispiel ist das Unterstellen eines gesamten

Subsystems als einzelnes Konfigurationselement, obwohl die zugehörigen Quellcode-Module einzeln geändert werden können.

• Grenzen Das Festlegen der Konfigurationseinheiten sollte mittels einer bewusst er-

stellen Liste erfolgen. Damit wird das Problem umgangen, dass z.B. sämtli-

che Erzeugnisse der Arbeitsabläufe (wie Emails, Protokolle,...) oder auch gar keine Artefakte unter Konfigurationsmanagement gesetzt werden.

• Zeitpunkt Es ist wichtig, den richtigen Zeitpunkt auszuwählen, um ein Artefakt unter

Konfigurationsmanagement zu stellen. Ab dem Zeitpunkt, an dem ein Arte-

fakt unter Konfigurationsmanagement steht, müssen sämtliche Änderungen

durch die Tätigkeiten des Konfigurationsmanagements (siehe Kapitel 2.4)

45 Vgl. Software Engineering Institute (2010) S. 159. 46 Vgl. Hass (2003) o.S. 47 Vgl. Hass (2003) o.S.


16

überwacht werden. Aufgrund dessen sollten die Bedürfnisse nach Sicher-

heit und Information, welche durch Konfigurationsmanagement gestillt wer-den, gegen den Aufwand abgewogen werden.

Bei der Beurteilung der Aufwände und auch der Vorteile sollte berücksichtigt wer-

den, dass diese häufig ungleich verteilt sind. Die Vorteile treten oft an anderen Stellen zu Tage, als an denen, wo die Aufwände anfallen.48

Insgesamt kann gesagt werden, dass eine angemessene Implementierung von

Konfigurationsmanagement, in einem sinnvollen Umfang, Aufgaben für alle Betei-ligten erleichtert.49

48 Vgl. Hass (2003) o.S. 49 Vgl. Hass (2003) o.S.


17

3 Versionsverwaltungssysteme Wie in Kapitel 1.6 erwähnt, behandelt die Versionsverwaltung das Verwalten aller

Versionen der im Versionsverwaltungssystem abgelegten Artefakte (z.B. Dateien).

Versionsverwaltungssysteme sind meist darauf ausgelegt, Klartext-Dateien zu

verarbeiten. Dabei werden in jeder neuen Klartext-Dateiversion Zeilen hinzugefügt

oder entfernt. Binäre Dateien haben keine Klartext-Zeilen, wodurch diese Art der

Verarbeitung nicht möglich ist. Werden binäre Dateien mit Klartext basierten Ver-

sionsverwaltungstools verwaltet, so wird für jede neue Version die komplette Datei

neu gespeichert. Auch viele andere Funktionalitäten eines Klartext-

Versionsverwaltungssystems sind für Binäre Dateien nicht verfügbar.50

Darstellung 4: Einfache Darstellung einer versionierten Datei51

Darstellung 4 zeigt eine einfache Abbildung einer versionierten Datei. Hierbei

wird die Versionsdatenbank gezeigt, in welcher alle bisherigen Versionen der Da-

tei gespeichert sind. Der Checkout bezeichnet die außerhalb der Versionsdaten-

bank vorhandene Datei. Diese „lokale“ Datei kann, im Gegensatz zu den ver-schiedenen Versionen in der Versionsdatenbank, beliebig editiert werden.

50 Vgl. Berlin/Rooney (2006) S. 15. 51 Chacon (2009) S. 2.

CHAPTER 1 GETTING STARTED2

Local Version Control SystemsMany people’s version-control method of choice is to copy files into another directory (per-haps a time-stamped directory, if they’re clever). This approach is very common because it’s so simple, but it’s also incredibly error prone. It’s easy to forget which directory you’re in and accidentally write to the wrong file or copy over files when you don’t mean to.

To deal with this issue, programmers long ago developed local VCSs that had a simpledatabase that kept all the changes to files under revision control (see Figure 1-1).

One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the com-mand when you install the Developer Tools. This tool basically works by keeping patch sets(that is, the differences between files) from one change to another in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.

Figure 1-1. Local version control diagram


18

Funktionalität von Versionsverwaltungssystemen Ein Versionsverwaltungssystem verwaltet alle darin gespeicherten Artefakte (z.B.

Dateien) und ermöglicht es, auf alle verfügbaren Versionen zuzugreifen. Diese

zentrale Verwaltung, in der die Originalkopie aller Versionen abgelegt ist, wird auch Repository genannt.52 Im Speziellen sind folgende Operationen möglich:

Operation Beschreibung

Sicherung und Wiederherstellung Dateien werden zu einem bestimmten

Zeitpunkt gespeichert und es ist mög-

lich, zu jedem gespeicherten Zeitpunkt

zurück zu gehen.

Synchronisation AnwenderInnen können Dateien ge-

meinsam benutzen und dabei auf dem aktuellsten Stand bleiben.

Kurzfristiges Rücksetzen Wurde eine Datei beispielsweise ge-

löscht oder fehlerhaft verändert, kann

mittels Versionsverwaltung auf die letzt-

bekannte korrekte Version zurückge-

stiegen werden.

Langfristiges Rücksetzen Im Falle eines länger zurückliegenden

Fehlers kann mittels Versionsverwal-

tung die alte Version wieder hergestellt

und gleichzeitig überprüft werden, wel-

che Änderungen zum damaligen Zeit-punkt erfolgten.

Änderungen nachverfolgen Alle Änderungen an Dateien können mit

einer „Änderungsmeldung“ versehen

werden. Diese Meldung wird im Versi-

onsverwaltungssystem abgelegt. Damit

wird es möglich, die Entwicklung der

Datei zu überprüfen.

52 Vgl. Mason (2006) S. 9.


19

Operation Beschreibung

EigentümerInnenschaft festhalten Jede durchgeführte Änderung wird mit

der durchführenden Person verknüpft.

Dabei ist auch eine Zugriffskontrolle für die BenutzerInnensteuerung möglich.

Selbstversicherung Im Falle von größeren Anpassungen an

Dateien können vorläufige Änderungen

in einer isolierten Umgebung durchge-

führt werden. Erst nach Überprüfung

der Richtigkeit werden die Änderungen

mit dem zentralen Repository zusam-mengeführt.

Versionsvergleich Durch Vergleich können die Unter-

schiede zwischen zwei Versionen (Da-

tei, Verzeichnis) gefunden und ange-zeigt werden.

Konfliktanzeige Wird ein Artefakt von verschiedenen

BenutzerInnen gleichzeitig geändert,

können bei der Zusammenführung Kon-

flikte auftreten. Dabei wird angezeigt,

falls an der selben Stelle nicht de-

ckungsgleiche Änderung durchgeführt

werden.

Sperre Um Konflikte zu vermeiden oder nur

bestimmten Personen Zugriff zu gewäh-

ren, können Artefakte gesperrt (und

entsperrt) werden.

Tabelle 1: Operationen von Versionsverwaltungssystemen53

In Fehler! Verweisquelle konnte nicht gefunden werden. wird beispielhaft ein ver-

einfachter Änderungsworkflow des Versionsmanagementtools Git gezeigt. Dabei

53 Vgl. Azad (2007) online.


20

wird durch den/die VerwalterIn der Steuerungsdaten eine Änderungen im lokalen

Repository vorgenommen. Diese Änderung wird zum Review an eine Genehmi-

gungsstelle gesendet. Wird die Änderung akzeptiert, erfolgt eine Übernahme in

das zentrale Repository. Wird die Änderung abgelehnt, wird dies an die anfor-dernde Stelle zurückgesendet.

Darstellung 5: Vereinfachter Änderungsworkflow von Steuerungsdaten mit Git54

Im Kontext des Konfigurationsmanagements ist ein Versionsverwaltungssystem

damit dazu in der Lage, die Anforderungen bezüglich der Änderungsverfolgung abzudecken.

54 Eigene Darstellung nach Quelle: Chacon (2009) S. 108.


21

4 Datenbankbasierte Verwaltung von BetreiberInnen-spezifischen Steuerungsdaten

Dieses Kapitel gibt einen Überblick über die Ausgangssituation bezüglich der Ver-

waltung von Steuerungsdaten innerhalb einer Datenbank. Es werden die Grundla-

gen von Datenbanken erklärt und in Folge dargelegt, wie die datenbankbasierte

Verwaltung von Steuerungsdaten die Anforderungen des Konfigurationsmanage-ments erfüllt.

4.1 Grundlagen Datenbanken R. A. Elmasri und S. B. Navathe definieren eine Datenbank als:

„[...] eine Sammlung von Daten, die einen Ausschnitt der realen Welt beschreiben. Unter Daten verstehen wir bekannte Tatsachen, die aufgezeichnet werden können und eine implizite Bedeutung ha-ben.“55

Dabei beschreibt eine Datenbank einen definierten Ausschnitt der realen Welt. Auf

diese Daten zugreifen bzw. sie zu verändern ist für einen bestimmten Personen-

kreis von Interesse.56

Werden diese Datenbanken computergestützt verwaltet, so spricht man von einem

Datenbankmanagementsystem (DBMS). In diesem DBMS werden die Datentypen,

die Struktur und Einschränkungen der Daten definiert. Ein DBMS bietet weiters die Möglichkeit der Manipulation und Abfrage dieser Daten. 57

Das Resultat dieser Definitionen ist ein Datenmodell.58 Bei der Art von Datenmo-dellen gibt es folgende Unterscheidungen:59

• Ein Relationales Datenmodell repräsentiert das Modell als Sammlung von

Relationen zwischen den Daten.60

• Satzbasiertes Datenmodelle stellen ausschließlich Datenstrukturen dar

• Ein Objektdatenmodell bietet Eigenschaften wie Objektidentitäten, benut-

zerdefinierte Datentypen, Vererbung, Klassen und komplexe Objekte.61

55 Elmasri/Navathe (2009) S. 18. 56 Vgl. Elmasri/Navathe (2009) S. 18. 57 Vgl. Elmasri/Navathe (2009) S. 19. 58 Vgl. Elmasri/Navathe (2009) S. 41. 59 Vgl. Elmasri/Navathe (2009) S. 41. 60 Vgl. Elmasri/Navathe (2009) S. 134.


22

Weiters gibt es in älteren Systemen noch Netzwerk- und hierarchische Datenmo-

delle. 62

4.2 Funktionsweise von Datenbanken Eine Datenbank kann eine Reihe von Operation ausführen. In der Folge werden

einige Operationen erklärt, um die Begriffe Commit und Transaktion erläutern zu können:

• Die Select-Operation ist die Operation, mit der eine Teilmenge der in der

Datenbank verwalteten Daten ausgewählt werden.63

• Eine Insert-Operation erzeugt einen neuen Datensatz in den angegeben Datenbanktabellen.64

• Update-Operationen dienen der Veränderung von bereits bestehenden Da-

ten.65

• Eine Delete-Operation führt die Löschung von verwalteten Daten durch.66

Die aufgelisteten Operationen führen Änderungen auf der Datenbank durch. Zur

Sichtbarmachung dieser Änderungen ist es notwendig, ein DBMS explizit dazu

aufzufordern. Dies bedeutet, dass die Änderungen in der Datenbank persistent festgeschrieben werden. Diese Operation wird als Commit bezeichnet.67

Im Rahmen eines Commits gibt es bei DBMS ein sogenanntes Transaktions-

Konzept. Als Transaktion werden eine Sammlung von Anweisungen (z.B. ein In-

sert und ein Update) bezeichnet, die gemeinsam durchgeführt werden.68 Diese

Transaktionen erfüllen die folgenden Eigenschaften: 69

• Atomarität: Es wird sichergestellt, dass alle Anweisungen innerhalb einer

Transaktion erfolgreich ausgeführt werden. Schlägt dies fehl, so wird die

Transaktion abgebrochen. Alle bis zu diesem Zeitpunkt durchgeführten Än-

derungen werden wieder in ihren Ursprungszustand (vor dem Beginn der 61 Vgl. Günther (1998) S. 111. 62 Vgl. Elmasri/Navathe (2009) S. 41. 63 Vgl. Elmasri/Navathe (2009) S. 150. 64 Vgl. Elmasri/Navathe (2009) S. 212. 65 Vgl. Elmasri/Navathe (2009) S. 214. 66 Vgl. Elmasri/Navathe (2009) S. 214. 67 Vgl. tutorialpoint (2014) online. 68 Vgl. tutorialpoint (2014) online. 69 Vgl. tutorialpoint (2014) online.


23

Transaktion) zurückgesetzt. Dieser Rücksetzungsvorgang wird auch Roll-

back genannt.

• Konsistenz: Es wird sichergestellt, dass die innerhalb der Datenbank defi-

nierten Regeln bzw. Relationen nach einem Commit erhalten bleiben.

• Isolation: Ist die Fähigkeit, dass Transaktionen unabhängig und transparent von einander durchgeführt werden können.

• Dauerhaftigkeit: Stellt sicher, dass die Ergebnisse der Transaktion die

commitiert wurde, auch persistent bleiben.

4.3 Konventionelle Datenbanken Eine konventionelle Datenbank (im Unterschied zu temporalen Datenbanken, sie-

he Kapitel 4.4) bieten keinen natürlichen Mechanismus, um die darin gespeicher-

ten Daten zu versionieren. Die Datenbank verändert sich durch eine Transaktion

von einem konsistenten Zustand zum nächsten, während der bisherige Zustand, nach dem Commit der Transaktion, verworfen wird.70

Es ist jedoch auch in einer konventionellen Datenbank möglich, eine zeitsensitive

Darstellung der Daten durchzuführen. Um dies umzusetzen ist es notwendig, im

Design und der Umsetzung sowohl in der Applikation, welche die Datenbank ver-

wendet, als auch der Zugriffsschicht, welche die Daten zur Verfügung stellt (siehe

Fehler! Verweisquelle konnte nicht gefunden werden.), die Versionierung von

Steuerungsdaten zu berücksichtigen. Eine solche Implementierung von zeitsensi-

tiven Daten führt, aufgrund der speziellen Designs und Umsetzungen im Rahmen der Entwicklung, zu erhöhten Aufwänden.

4.4 Temporale Datenbanken Temporale Datenbanken sind Datenbanken, die in der Lage sind, zeitveränderli-

che Daten zu verwalten.71 Hierbei gibt es zwei unterschiedliche Interpretationen von Zeit:72

• „Valid Time“ ist jene Zeitperiode, innerhalb derer die gespeicherten Fakten

im Bezug auf die echte Welt gültig sind.

70 Vgl. Salzberg/Tsotras (1999) S. 158. 71 Vgl. Salzberg/Tsotras (1999) S. 159. 72 Vgl. TimeConsult (2005) online.


24

• Transaktionszeit ist jene Zeitperiode, innerhalb derer die Fakten in der Da-

tenbank gespeichert werden.

Aus diesen Sichtweisen auf Zeit ergeben sich unterschiedliche Formen von tem-poralen Datenbanken:73

• Historische Datenbanken speichern Daten im Hinblick auf die echte Durch-führungszeit.

• Eine Rollback-Datenbank speichert die Daten im Hinblick auf die Transakti-

onszeit (der Datenbank).

• Eine bitemporale Datenbank berücksichtigt bei der Verarbeitung der Daten

sowohl die Transaktionszeit als auch die echte Durchführungszeit.

Um diese zeitsensitiven Datensätze abzufragen, sind spezielle Mechanismen not-wendig, die auch in den SQL-Standard 2011 Eingang gefunden haben.74

Wie bereits bei konventionellen relationalen Datenbanken ist es auch bei tempora-

len Datenbanken notwendig, spezielle Implementierungen in der Zugriffsschicht

und den Applikationen durchzuführen, um diese zeitsensitiven Daten abzufragen.

Durch die in Bordmittel vorhandenen Möglichkeiten der Berücksichtigung von zeit-

sensitiven Daten ist der Aufwand bei temporalen Datenbanken im Vergleich zu konventionellen relationalen Datenbanken geringer.

4.5 Anforderungen des Konfigurationsmanagements von be-treiberInnenspezifischer Software an datenbankbasierte Verwaltungen von Steuerungsdaten

BetreiberInnenspezifische Steuerungsdaten sind Daten, die das Verhalten einer

Software steuern und verändern. Sie können in einer BetreiberInnen-Installation

der Software von einem/einer AnwenderIn verändert werden. Bei datenbankba-

sierter Software (oder Datenbanksystemen) werden die Daten über die Funktionen

der Applikation in einer Datenbank gespeichert (siehe Fehler! Verweisquelle konn-

te nicht gefunden werden.).75

73 Vgl. TimeConsult (2005) online. 74 Vgl. Kulkarni/Michels (2012) S. 34 75 Vgl. Elmasri/Navathe (2009) S. 20.


25

Darstellung 6: Applikationsarchitektur einer datenbankbasierten Software76

Veränderungen dieser Steuerungsdaten verändern das Verhalten der Software

und damit auch die darin ablaufenden Prozesse. Sind diese Prozesse von hoher Relevanz für das Geschäft, ist auch das Risiko solcher Änderungen groß.

Das Konfigurationsmanagement stellt nun verschiedene Anforderungen an den

Änderungsprozess von Steuerungsdaten. Wie bereits in Kapitel 2.3 erwähnt, ist Konfigurationsmanagement notwendig, um unter anderem:

• Die Nachvollziehbarkeit der Änderung zu gewährleisten

• Verantwortlichkeiten zur Quellen zurückzuverfolgen

• Keine unerwünschte Änderungen durchzuführen und

• ein schnelles und einfaches Auditing zu haben.

ITIL Service Transition 2011 führt dazu noch weitere Anforderungen an:77

• Die Sicherstellung des kontrollierten Einsatzes während des gesamten Le-

benszyklus

• Belegen, managen und beschützen der Änderungselemente während des

gesamten Lebenszyklus durch das Arbeiten mit Änderungsmanagement,

76 Datadisk (2014) online. 77 Vgl. Cabinet Office (2011) S. 90.


26

sodass nur autorisierte Elemente durch autorisierte Anpassungen erfolgen

können.

4.6 Erfüllung der Anforderungen des Konfigurationsmanage-ments von Steuerungsdaten in datenbankbasierten Applika-tionen

Wie bereits in den Kapitel 4.3 und 4.4 beschrieben, ist für die zeitsensitive Ver-

waltung von Daten zusätzlicher Implementierungsaufwand innerhalb der verwen-

deten Applikation notwendig. Ohne diese Aufwände kann den Anforderungen des

Konfigurationsmanagements bezüglich des kontrollierten Einsatzes über den ge-samten Lebenszyklus nicht entsprochen werden (siehe Kapitel 4).

Den weiteren Anforderungen bezüglich belegen, managen und beschützen der

Änderungselemente während des gesamten Lebenszyklus kann aber ohne weite-

re Funktionalitäten innerhalb der Applikation nicht entsprochen werden. Eine rein

datenbankbasierte Protokollierung wie beispielsweise durch automatisches Auslö-

sen der Speicherung von Änderungsdatensätzen ist nicht ausreichend, da diese

einem/einer AnwenderIn nicht in der Benutzeroberfläche der Applikation darge-stellt werden.

Um einen kontrollierten und nachvollziehbaren Zugriff im Sinne eines Änderungs-

management zu ermöglichen, würden beispielsweise Zugriffskontrollen und Proto-

kollierungen notwendig sein sowie eine Möglichkeit, einen Änderungsworkflow (z.B. Anfordern, genehmigen und durchführen) darzustellen.

Damit ist es nicht möglich, Steuerungsdaten einer datenbankbasierten Applikation entsprechend den Anforderungen von Konfigurationsmanagement zu verwalten.


27

5 Alternative Verwaltungsmöglichkeiten von betreibe-rInnen-spezifischen Steuerungsdaten

Als Alternative zur datenbankbasierten Speicherung (siehe Kapitel 4) besteht die

Möglichkeit, diese Daten in Klartext-Dateien (siehe Kapitel 3) abzulegen. In die-

sem Kapitel werden die verschiedenen Möglichkeiten zur Verwaltung von Steue-

rungsdaten erläutert und auf den Erfüllungsgrad der Anforderungen von Konfigu-rationsmanagement untersucht.

5.1 Auszeichnungssprache Extensible Markup Language (XML) XML ist eine Meta-Auszeichnungssprache für Textdokumente. Dabei werden Da-

ten als Zeichenketten festgehalten und mit beschreibenden Textauszeichnungen

umgeben.78 Als Textdokument sind XML-Dokumente dazu geeignet, in Versions-verwaltungssoftware (siehe Kapitel 3) verwaltet zu werden.

5.1.1 Grundlagen von XML XML entwickelte sich aus im Jahre 1969 entwickelten Standard Generalized

Markup Language (SGML) und aus Hypertext Markup Language (HTML). SGML

wurde entwickelt, um Dokumentenstrukturen zu beschreiben. HTML wurde entwi-

ckelt als Beschreibungssprache von webbasierten Dokumenten zur Darstellung

von Bildern, Texten und Links auf Webseiten.79

Da bei HTML die möglichen Elemente fix vorgegeben sind, war dies für eine wei-

tere Entwicklung des Webs zu unflexibel. Auch der Informationsverlust (z.B. gehen

Attributsbeschreibungen von Daten verloren) bei Datendarstellungen in HTML aus einer z.B. Datenbanktabelle ist als großer Nachteil zu sehen.80

Aus diesen Gründen wurde XML als flexible Beschreibungssprache entwickelt. Sie

ermöglicht eine individuelle Definition der Elemente und Struktur. Dateninhalte

können wie in Datenbanktabellen über ein beschreibendes Element definiert wer-

den.81 In Fehler! Verweisquelle konnte nicht gefunden werden. ist ein Beispiel ei-

ner XML-Datei aus der Fehlerverwaltungs-Software Mantis-Bugtracker abgebildet.

78 Vgl. Harold/Means (2004) S. 3. 79 Vgl. Vonhoegen (2007) S. 28. 80 Vgl. Vonhoegen (2007) S. 29. 81 Vgl. Vonhoegen (2007) S. 28.


28

Darstellung 7: Beispiel eines XML82

5.1.2 Aufbau von XML Trotz der flexiblen Definitionsmöglichkeiten der Struktur gibt es zwei vorgegebene Elemente in der Grundstruktur:

• Prolog: Im Prolog werden optional Basisdaten über das XML festgehalten.

Es wird definiert, welche Version der XML-Sprache und nach welcher Zei-

chensatzkodierung das Dokument erstellt wird.83 Eine Zeichensatzkodie-

rung definiert die möglichen maschinenlesbaren Zeichenkombinationen.84

Weiters besteht die Möglichkeit, eine Definition des Dokumententyps

82 XML-Export aus der Fehlerverwaltungssoftware Mantis Bug-Tracker 83 Vgl. Fawcett u.a. (2012) S. 29. 84 Vgl. Techterms (2010) online.


29

(Document Type Definition, DTD) oder eines XML Schemas vorzuneh-

men.85

• Wurzelelement: Das Wurzelelement ist das erste Element der Datenstruk-

tur. Es schließt alle anderen möglichen Elemente in sich ein.86

5.1.3 XML Dokumenttyp Definition und XML-Schema Eine DTD und ein XML-Schema sind in einer formalen Syntax geschrieben und

beschreiben, welche Elemente in dem XML vorkommen können und welche Inhal-te und Attribute dieses Element haben kann.87

Auf Basis eines DTD oder eines XML-Schemas können Programme automatisch überprüfen, ob das zu verarbeitende XML den Vorgaben des Modelles entspricht.

Darstellung 8: Beispiel eines DTD von Projektdaten88

Fehler! Verweisquelle konnte nicht gefunden werden. zeigt ein Beispiel eines

DTD von Projektdaten. Die gleichen Inhalte sind in Fehler! Verweisquelle konnte nicht gefunden werden. in Form eines XML-Schemas abgebildet.

85 Vgl. Vonhoegen (2007) S. 53. 86 Vgl. Vonhoegen (2007) S. 54. 87 Vgl. Harold/Means (2004) S. 28. 88 Vonhoegen (2007) S. 24.

24

Einführung1

Jargon heißt, und bricht die Verarbeitung mit einer entsprechenden Fehlermel-dung ab. Während der Internet Explorer bei einer HTML-Seite allerlei Ungenau-igkeiten durchgehen lässt und die Seite trotzdem anzeigt, herrscht also bei XMLein strenges Regime, in der guten Absicht, Webanwendungen in der Zukunft ineinen solideren Zustand zu befördern.

1.1.4 Gültige Dokumente per DTD oder SchemaDie bloß formale Prüfung auf Wohlgeformtheit kann noch ergänzt werden durcheine Prüfung auf Gültigkeit. Dabei geht es um die Frage, ob das Dokument auchalle geforderten Informationen enthält, und zwar in der richtigen Reihenfolge.Ein Projekt in unserem Beispiel kann zwar mehr als einen Autor haben, aber keinProjekt kommt ohne Autor aus. Um die Elemente und Attribute und ihre Reihen-folge für ein Dokument genau festzulegen, kann dem XML-Dokument ein ent-sprechendes Datenmodell zugeordnet werden, an dem seine Gültigkeit danngemessen werden kann.

Mit dem Werkzeug, das wir im Verlauf dieses Buchs noch häufiger verwendenwerden – XMLSpy – kann ein solches Datenmodell auch nachträglich aus einemschon vorliegenden XML-Dokument erzeugt werden. Dabei gibt es hauptsächlichzwei Möglichkeiten. Sie können eine DTD – eine Dokumenttyp-Definition – oderein XML Schema erzeugen. Die Rolle dieser beiden Datenmodelle wird ausführ-lich in Kapitel 3, Dokumenttypen und Validierung, behandelt. Eine DTD für unserBeispiel sieht zum Beispiel so aus:

Das gleiche Datenmodell in Form eines XML Schemas zeigt die nächste Abbil-dung.

Abbildung 1.4 Eine DTD für die Projektdaten


30

Darstellung 9: XML-Schema der Projektdaten89

5.1.4 XML-Daten Die XML-Daten enthalten alle Elemente, Attribute und deren Ausprägungen. Das

Wurzelelement folgt auf den Prolog (siehe Kapitel 5.1.2). Innerhalb des Wur-

zelelements sind alle Daten des XML in Baumform (siehe Darstellung 10) enthal-ten.90

89 Vonhoegen (2007) S. 25. 90 Vgl. Vonhoegen (2007) S. 54.

25

Kleines Einstiegsprojekt zum Kennenlernen 1.1

XMLSpy gibt dieses Datenmodell grafisch in einer entsprechenden Baumstrukturaus. Der Modelldesigner kann sein Modell auch gleich in dieser grafischen Formentwerfen. Das erleichtert es, den Überblick über die Hierarchie der Informati-onseinheiten zu behalten, die er konstruiert.

Die Gültigkeit eines Dokuments kann in XMLSpy immer sofort geprüft werden,weil ein validierender Parser integriert ist. Der Internet Explorer ignoriert dage-gen normalerweise die Frage der Gültigkeit, zeigt also auch ungültige Dokumentesolange an, als sie wohlgeformt sind.

Abbildung 1.5 Das XML Schema, das der DTD entspricht

Abbildung 1.6 Das XML Schema als Diagramm in XMLSpy


31

Darstellung 10: Baumstruktur eines XML-Kontaktdokuments91

Der hier gezeigte Baum kann auch ein relationales Datenmodell darstellen.92 So-

mit ist es auch möglich, Daten einer relationalen Datenbank in einem XML zu

speichern.

5.1.5 Anwendungsgebiete von XML XML findet häufig Anwendung in der Darstellung und Speicherung von Daten.93 In

der Folge werden diese Anwendungsgebiete aufgelistet:

• Dokumenten-zentriertes XML: Wird verwendet, um eine grobe Struktur der

Inhalte (z.B. Kapitel) mit Metadaten anzureichern. Weiters wird es dazu

verwendet, um mehrere Publikationskanäle zu bedienen und die Inhalte dabei wiederzuverwenden.94

• Konfigurations-Dateien: Zur Speicherung von Konfigurationsdaten verwen-

den aufgrund der einfachen Analysemöglichkeiten fast alle modernen Sys-teme XML.95

• Webservices: Ein Webservice ist ein Dienst, der im Web von beliebigen

Anwendungen benutzbar ist.96 Im Rahmen der Kommunikation von Webs-

ervices wird XML als einfacher Weg zur plattformübergreifenden Serialisie-rung von Objekten verwendet.97

91 Vonhoegen (2007) S. 54. 92 Vgl. Vonhoegen (2007) S. 54. 93 Vgl. Fawcett u.a. (2012) S. 14. 94 Vgl. Fawcett u.a. (2012) S. 13 f. 95 Vgl. Fawcett u.a. (2012) S. 14. 96 Vgl. IT Wissen (2014) online. 97 Vgl. Fawcett u.a. (2012) S. 14.

54

XML – Bausteine und Regeln2

2.1.7 XML-Daten: der Baum der ElementeErst hinter dem Prolog beginnen die eigentlichen XML-Daten in Form einesBaums aus Elementen und Attributen. Das erste Element im Dokument ist immerdas Wurzelelement, das alle anderen möglichen Elemente in sich einschließt. Mitanderen Worten, das Dokument hat die Struktur eines Baums aus ineinander ver-schachtelten Elementen.

Außer für das Wurzelelement gibt es folglich für jedes andere Element genau einElternelement, während das Wurzelelement und jedes seiner Kindelemente wie-der weitere Kindelemente zum Inhalt haben können. Es sind beliebig tiefe Ver-schachtelungen erlaubt.

Diese hierarchische Baumstruktur kann durch einen Graphen dargestellt werden,dessen Knoten durch gerichtete Kanten verbunden sind und dessen Wurzelkno-ten für keine dieser Kanten der Endknoten ist. Dieser Graph enthält folglich auchkeine Zyklen.

Der Baum ist durch die sequenzielle Abfolge der Elemente im XML-Dokumentimplizit geordnet. Natürlich kann auch eine ganz flache Struktur wie eine relati-onale Datenbanktabelle in XML ausgedrückt werden, aber die besonderen Stär-ken des Modells kommen dann zur Geltung, wenn es um tiefgestaffelte Daten-strukturen geht.

2.1.8 Start-Tags und End-TagsJedes Element wird jeweils durch ein Start-Tag und ein End-Tag begrenzt. DasXML-Dokument vermischt also die darin enthaltenen Inhalte mit Informationenüber diese Inhalte, oder man kann auch sagen, es mischt Informationen und

Abbildung 2.2 Baumstruktur eines Dokuments

name ort mail name ort mail

kontakt kontakt

kontakte


32

• Web Inhalte: XHTML (eine XML Version von HTML) ist eine Variante, We-

binhalte wiederverwendbar zu machen und auch eine Möglichkeit zur Re-duktion der verwendeten Bandbreite und Speicher.98

• Dokumentenmanagement: Hier wird XML zur Verwaltung der Metadaten

(z.B. AutorIn, Erstellungsdatum oder Änderungen) von Dokumenten ver-wendet.

• Interoperabilität im Geschäftsverkehr: Das Definieren und Abstimmen eines

XMLs zum Austausch von Daten zwischen verschiedenen Applikationen, ist einfacher als die Verarbeitung eines applikationsspezifischen Formates.99

5.1.6 Erfüllung der Konfigurationsmanagement-Anforderungen von Steuerungsdaten in datenbankbasierten Applikationen verwaltet in XML XML bietet sowohl die Möglichkeit zur Abbildung von relationalen (siehe Kapitel 5.1.4), als auch von objektorientierten Datenstrukturen.100

Werden nun die Steuerungsdaten zum Zeitpunkt Null (z.B. Inbetriebnahme) mittels

einer Exportschnittstelle in ein XML-Datei geschrieben, ist das Ergebnis ein Text-

dokument. Auch ein Import dieser XML ist wieder mittels Schnittstelle möglich.

Dieses Textdokument kann über die in Kapitel 3 beschriebene Versionsverwal-

tungssoftware verwaltet werden.

Durch die Versionsverwaltungssoftware wird prinzipiell die Fähigkeit geschaffen:

• Zugriffskontrollen durchzuführen

• Änderungen nachverfolgen

• Historien aller Mutationen zu führen

• Änderungsworkflows zu schaffen

Dadurch kann den Anforderungen des Konfigurationsmanagements bezüglich des

kontrollierten Einsatzes über den gesamten Lebenszyklus sowie dem Belegen,

Managen und Beschützen der Änderungselemente während des gesamten Le-benszyklus entsprochen werden.

98 Vgl. Fawcett u.a. (2012) S. 15. 99 Vgl. Fawcett u.a. (2012) S. 12. 100 Vgl. Fawcett u.a. (2012) S. 14.


33

5.2 Domain Specific Language Eine Domain Specific Language (DSL) ist im Gegensatz zu einer General Purpose

Language eine Programmiersprache mit limitierten Ausdrucksmöglichkeiten, die

auf eine bestimmte Domain (Problemgebiet) fokussiert ist.101 Eine General Purpo-

se Language ist eine Programmiersprache mit der es möglich ist, alle Arten von Problemstellungen zu lösen.102

M. Fowler definiert die Domain Specific Language wie folgt:

„A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usual-ly restricted to, a particular problem domain.“103

Eine DSL hat vier Kernelemente:104

• Es ist eine Sprache, die von Menschen benutzet wird, um einen Computer

zu instruieren, etwas zu tun.

• Die Sprache sollte flüssig sein, damit die Ausdrucksstärke nicht nur von

einzelnen Ausdrücken, sondern vom gesamten Aufbau der Konstrukte kommt.

• Die DSL soll im Gegensatz zu General Purpose Languages, nur jenes Mi-

nimum an Features haben, das benötigt wird, um die definierte Domain ab-zubilden.

• Eine beschränkte Sprache ist nur dann nützlich, wenn sie einen klaren Fo-kus auf eine beschränkte Domain hat.

Die Domain Specific Language wird durch einen speziellen Compiler bei der Aus-

führung durch Funktionen einer General Purpose Language interpretiert und aus-

geführt.105

5.2.1 Grundlagen von DSL Bei DSL wird zwischen internen und externen DSL unterschieden.

101 Vgl. Fowler (2010) o.S. 102 Vgl. PCmag (2014) online. 103 Van Deursen u.a. (2000) o.S. 104 Vgl. Fowler (2010) o.S. 105 Vgl. Fowler (2010) o.S.


34

Interne DSL:

Eine interne DSL ist durch die Syntax einer General-Purpose Language repräsen-

tiert. Es wird dabei eine Teilmenge der General-Purpose Language verwendet, um

einen kleinen Bestandteil des Gesamtsystems abzubilden. Eine interne DSL muss

– im Gegensatz zu einer externen DSL – nicht von einem speziellen Compiler übersetzt werden, um ausführbar zu sein.106

Sie ist aufgrund dessen, dass sie eine General Purpose Language als Basis ver-

wendet, ohne weitere Kompilierung direkt in der Ausführungsumgebung (z.B. Java Virtual Machine) dieser Sprache einsetzbar.

Das Resultat der Definition einer internen DSL ist eine maßgeschneiderte Spra-

che. Ein Beispiel hierfür ist das Entwicklungsframework „Ruby on Rails“, das die

General Purpose Language „Ruby“ als Grundlage verwendet. 107

Externe DSL:

Eine externe DSL ist eine Domain Specific Language, die eine von der General

Purpose Language mit der sie zusammenarbeitet (Basissprache) unabhängige

Syntax hat. Es wird also eine eigene Syntax verwendet, die nur spezifisch für die definierte Domain verwendet wird.108

Ein Beispiel für eine externe DSL im Kontext des Wertpapierhandels:109

buy 500.shares.of("SUNW").at(10.14)

sell 350.shares.of(„AAPL").at(179.30)

show_transactions "AAPL"

print_portfolio_value

In diesem Beispiel ist die Syntax im Zusammenhang mit dem Fachgebiet ver-

ständlich. Die Anweisungen, die in der externen DSL verfasst werden, müssen

durch einen Prozess in die Basissprache übersetzt werden, der einer Kompilie-

106 Vgl. Fowler (2010) o.S. 107 Vgl. Fowler (2010) o.S. 108 Vgl. Fowler (2010) o.S. 109 Spradlin (2008) online.


35

rung gleicht. Dieses Zwischenergebnis kann im Anschluss in der Ausführungsum-

gebung der Basissprache ausgeführt werden. 110

5.2.2 Anwendungsgebiete von DSL Domain Specific Language bietet verschiedene Anwendungsmöglichkeiten inner-halb des Softwarelebenszyklus.

In der Folge werden diese Anwendungsgebiete kurz erläutert:

• Applikations Domain DSL: Es handelt sich um eine DSL, die das Kernge-

schäft der Businesslogik (u.a. Steuerungsdaten) der Applikation beschreibt.

Diese Art von DSL ist dafür vorgesehen, von Domain Experten (z.B. An-

wendernInnen) eingesetzt zu werden. Die Anforderung an die Sprach-

Notation sind dadurch strenger (z.B. Einfachheit der Bedienung und Werk-

zeug-Unterstützung). Applikations Domain DSL benötigen auch im Ver-

gleich zu anderen DSL mehr Aufwand, da die Domain zuerst verstanden,

strukturiert und von den Domain ExpertInnen wieder erlernt werden muss.111

• Anforderungsanalyse DSL: Diese DSL fokussiert nicht auf automatische

Quellcode-Generierung, sondern auf eine präzise, komplette und prüfbare

Beschreibung der Anforderungen. Die Nachvollziehbarkeit zwischen den Artefakten ist wichtig. 112

• DSL für Analysen wird zur Prüfung und Analyse von Belegen verwendet.

Die Formalismen der DSL ermöglichen eine formale Prüfung von z.B. kom-

plexen technischen Systemen.113

• DSL als Hilfsmittel: Hier werden DSL als Hilfsmittel für EntwicklerInnen

eingesetzt. Es wird damit ein kleiner Teil des Softwareentwicklungsprozes-

ses automatisiert. Ein Beispiel hierfür ist die Generierung von Datenbankta-

bellen auf Basis von Klassendiagrammen wie in „Ruby on Rails“.114 Klas-

110 Vgl. Voelter (2013) S. 51 111 Vgl. Voelter (2013) S. 49. 112 Vgl. Voelter (2013) S. 49. 113 Vgl. Voelter (2013) S. 49 f. 114 Vgl. Voelter (2013) S. 47.


36

sendiagramme beschreiben die Objekte und die Struktur der Information

die von der Applikation verwendet werden.115

• Architektur DSL: Ein großes Anwendungsgebiet von DSL ist die Beschrei-

bung von Architekturelementen (z.B. Komponenten, Schnittstellen oder Nachrichten) mithilfe von DSL.116

5.2.3 Erfüllung der Konfigurationsmanagement-Anforderungen von Steuerungsdaten in datenbankbasierten Applikationen verwaltet in DSL DSL bietet ähnlich wie XML (siehe Kapitel 5.1.6) die Möglichkeit, Steuerungsda-

ten in Form von Klartext, im Fall von DSL eine Art von Quellcode darzustellen.

AnwenderInnen (=Domain ExpertInnen) sind dadurch in der Lage, die Pflege der

Steuerungsdaten vorzunehmen. Diese Form von DSL wird auch als von Fachleu-

ten lesbarer Code bezeichnet.117 Der dadurch erzeugte DSL-Code wird ähnlich

der datenbankbasierten Verwaltung von Steuerungsdaten (siehe Kapitel 4.6) in

der Datenbank abgelegt und kann von dort mit dem gleichen Verfahren wie für

XML (siehe Kapitel 5.1.6), exportiert und von einer Versionsverwaltungssoftware verwaltet werden.

Damit sind dieselben Möglichkeiten bezüglich Konfigurationsmanagement-Anforderungen gegeben wie bei XML:

• Zugriffskontrollen durchzuführen

• Änderungen nachzuverfolgen

• Historien aller Mutationen führen

• Änderungsworkflows schaffen

Es ist somit auch mittels DSL möglich, über den gesamten Lebenszyklus Ände-rungselemente zu belegen, zu managen und zu beschützen.

5.3 Vergleich von DSL und XML als Grundlage für die Verwal-tung von Steuerungsdaten

In den Kapiteln 4.6, 5.1.6 sowie 5.2.3 wurde die Eignung der Methoden im Hin-

blick auf die Abdeckung der Anforderungen aus Konfigurationsmanagement für

Steuerungsdaten untersucht. Sowohl DSL als auch XML sind in der Lage, aus 115 Vgl. Microsoft (2014) online. 116 Vgl. Voelter (2013) S. 47 f. 117 Vgl. Fowler (2010) o.S.


37

Sicht von Konfigurationsmanagement diese Anforderungen abzudecken. Bei der

datenbankbasierten Speicherung ist die Anforderung nicht ohne zusätzliche Im-

plementierungen innerhalb der verwalteten Applikation zur Abdeckung der Anfor-derungen bezüglich Verwaltung möglich.

Auch bei den Varianten XML und DSL sind zusätzliche Implementierungen not-

wendig. Dabei handelt es sich jedoch um reine Import/Export Schnittstellen, wobei

die Datenbankvariante auch Prozesslogik zur Verwaltung (z.B. AnwenderInnenau-

torisierung oder Freigabeprozess) benötigt.

Die Varianten XML und DSL unterscheiden sich nicht, was die Verwaltbarkeit im

Konfigurationsmanagement betrifft. Hier bleibt als Differenzierungsmerkmal nur der Aufwand, die jeweilige Methode aufzubauen.

Bei XML beläuft sich dieser Aufwand auf die Definition der XML-Struktur. Diese

Definition kann über eine Ableitung des Datenmodells erfolgen (siehe Kapitel 5.1.6).

Bei DSL ist der Aufwand abhängig von der Komplexität der abzubildenden Domai-

ne und der notwendigen Kompilierung. Es ist jedoch ein Aufwand, der zusätzlich

zu der Analyse des Datenmodelles anfällt. Somit ist die Variante mit dem gerings-

ten Aufwand, welche die Anforderungen des Konfigurationsmanagements erfüllen kann, eine Speicherung der Steuerungsdaten in XML.


38

6 Conclusio Die Ergebnisse der Recherche zeigen die Probleme bei der Verwaltung von be-

treiberInnenspezifischen Steuerungsdaten bei der alleinigen Verwendung von Da-

tenbanken im Hinblick auf die Anforderungen des Konfigurationsmanagements. Es

ist ohne Funktionalitätserweiterung innerhalb der betriebenen Applikation nicht

möglich, Zugriffskontrollen und Protokollierungen durchzuführen oder einen Ände-rungsworkflow abzubilden.

Die alternativen Verwaltungsmöglichkeiten basierend auf XML und DSL – mit Un-

terstützung von Versionsverwaltungssoftware – ermöglichen hingegen eine voll-

ständige Abdeckung der Anforderungen. Durch den Einsatz von Versionsverwal-

tungssoftware ist die Nachvollziehbarkeit gewährleistet (inklusive Verantwortlich-

keiten) und die Auditierung wird unterstützt. Weiters sind alle Veränderungen der

Elemente dokumentiert und jederzeit wieder herstellbar. Der zusätzliche Aufwand

beschränkt sich bei dieser Methode auf die Notwendigkeit, den Export und Import der Daten aus und in die Datenbank zu ermöglichen.

Bei der Variante der Verwaltung der Daten durch XML gibt es Vorteile im Ver-

gleich zum Einsatz von DSL. Der Einsatz von DSL benötigt im Vergleich zu XML

jedoch höhere Aufwände, da hierbei nicht nur die Steuerungsdaten modelliert

werden müssen, sondern auch die Notwendigkeit besteht, die Domain zu analy-sieren. Weiters muss eine Kompilierung durchgeführt werden.

Durch den Einsatz von XML und einer Versionsverwaltungssoftware wird das

Problem, dass sich jene Daten, die innerhalb der Applikation einen Bezug zu den

Steuerungsdaten herstellen, bei der Veränderung der Steuerungsdaten möglich-

erweise auf die ursprünglichen Steuerungsdaten zeigen müssen, nicht gelöst. Ein

Beispiel hierfür können Umsatzdaten einer Kontoapplikation sein, die auf eine Be-

rechnungsmethode des aktuellen Steuerjahres zeigen. Berechnungsmethoden

sind im diesem Fall die Steuerungsdaten. Durch eine Änderung in den Steuerge-

setzen muss eine neue Berechnungsmethode konfiguriert werden. Damit die Um-

satzdaten die mit der ursprünglichen Berechnungsmethode erzeugt wurden, auch

nach der Konfigurationsänderung noch bei einer Anzeige oder einem Storno mit

diesen Daten in der Applikation verarbeitet werden können, ist es notwendig in-

nerhalb der Software diese Historie zu erhalten. Dieser historische Bezug ist durch

die in dieser Arbeit aufgezeigten Verwaltungsmöglichkeiten nicht möglich.


39

Die Erkenntnisse aus dieser Arbeit werden im Rahmen eines betrieblichen Evalu-ierungsprojektes Anwendung finden.

Weitere Forschungen zu diesem Thema sollten die Frage untersuchen, inwieweit

die hier dargestellten Vorgehensweisen in einer Steuerungsdatenverwaltungsap-

plikation integriert werden können, um Steuerungsdaten von beliebigen daten-

bankbasierten Applikationen ohne Zusatzaufwände zu verwalten.


40

7 Literaturverzeichnis Allain, A. (2014): Compiling and Linking, bezogen unter:

http://www.cprogramming.com/compilingandlinking.html, Zugriff am: 25.06.2014

Azad, K (2007): A Visual Guide to Version Control, bezogen unter: http://betterexplained.com/articles/a-visual-guide-to-version-control/, Zugriff am: 11.05.2014

Berlin, D. / Rooney, G.(2006): Practical Subversion, 2. Aufl., New York: Springer-Verlag New York

Cabinet Office (2011): ITIL® Service Transition, 2. Aufl., Norwich: The Stationery Office

Chacon, S. (2009): Pro Git, 1. Aufl., New York: Springer-Verlag New York Conrardi, R. / Westfechtel B. (1998): Version Models for Software Configuration

Management, in: ACM Computing Surveys, 30/2, S. 232-282, bezogen un-ter: http://dx.doi.org/10.1145/280277.280280, Zugriff am 27.04.2014

Datadisk (2014): Applikationarchitektur, bezogen unter: http://www.datadisk.co.uk/images/sap/basis/intro4.jpg, Zugriff am: 01.06.2014

Ehow (2014): Definition of Agile Project Management, bezogen unter: http://www.ehow.com/facts_6801409_definition-agile-project-management.html, Zugriff am: 10.06.2014

Elmasri, R. A. / Navathe, S. B. (2009): Grundlagen von Datenbanksystemen, 3. Aufl., München: Pearson Education Deutschland GmbH,

Fawcett, J. / Quin, L. R.E. / Ayers, D. (2012): Beginning XML, 5. Aufl., Indianapo-lis: John Wiley & Sons

Fowler, M. (2010): Domain Specific Languages, 1. Aufl., Boston: Addison-Wesley Professional

Günther, O. (1998): Environmental Information Systems, 1. Aufl., Berlin: Springer-Verlag

Harold, E. R. / Means, W. S. (2004): XML in a Nutshell, 3. Aufl., Sebastopol: O’Reilly Media

Hass, A. M. J. (2003): Configuration Management Principles and Practice, Boston: Pearson Education Inc., bezogen unter: http://my.safaribooksonline.com/book/management/0321117662, Zugriff am: 01.06.2014

ITWissen (2014): Webservice, bezogen unter: http://www.itwissen.info/definition/lexikon/Webservice-WS-web-services.html, Zugriff am 10.06.2014

Keyes, J. (2004): Software Configuration Management, 1. Aufl., Boca Raton: Au-erbach Publications, bezogen unter: http://www.amazon.com/Software-Configuration-Management-Jessica-Keyes-ebook/dp/B000Q36ELA/ref=tmm_kin_title_0, Zugriff am: 14.04.2014


41

Kulkarni, K. / Michels, J. (2012): Temporal features in SQL:2011, in: SIGMOD Re-cord, 41/3, S. 34-43, bezogen unter: http://dl.acm.org/citation.cfm?id=2380786, Zugriff am: 01.06.2014

Microsoft (2014): UML Class Diagrams: Reference, bezogen unter: http://msdn.microsoft.com/en-us/library/dd409437.aspx, Zugriff am 13.06.2014

PCmag (2014): Definition of: general-purpose language, bezogen unter: http://www.pcmag.com/encyclopedia/term/43726/general-purpose-language, Zugriff am 10.06.2014

Salzberg, B. / Tsotras, V. J. (1999): Comparison of Access Methods for Time-Evolving Data, in: ACM Computing Surveys, 31/2, S. 158-221, bezogen un-ter: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190.9679&rep=rep1&type=pdf, Zugriff am: 01.06.2014

SAP Knowledge Warehouse (2014): Steuerungsdaten, bezogen unter: http://www.urz.uni-heidel-berg.de/saphelp/helpdata/DE/35/28ea57e8aa5570e10000009b38f983/content.htm, Zugriff am: 01.06.2014

Software Engineering Institute (2010): CMMI® für Entwicklung, Version 1.3, Pro-zessverbesserung für die Entwicklung besserer Produkte und Dienstleis-tungens, Pittsburgh: Software Engineering Institute, bezogen unter: http://www.sei.cmu.edu/library/assets/whitepapers/10tr033de_v11.pdf, Zu-griff am 01.06.2014

Spradlin, J. (2008): Groovy Domain Specific Language Tutorial, bezogen unter: http://www.justinspradlin.com/programming/groovy-domain-specific-language-tutorial/, Zugriff am 02.06.2014

Techterms (2010): Character encoding, bezogen unter: http://www.techterms.com/definition/characterencoding, Zugriff am: 10.06.2014

TimeConsult (2005): What are Temporal Databases?, bezogen unter: http://www.timeconsult.com/TemporalData/TemporalDB.html, Zugriff am: 01.06.2014

Tutorialspoint (2014): SQL - Transactions ,bezogen unter: http://www.tutorialspoint.com/sql/sql-transactions.htm, Zugriff am 10.06.2014

Van Deursen, A. / Klint, P./ Visser, J. (2000): Domain-Specific Languages: An Annotated Bibliography, in: Sigplan Notices, 35/6, S. 26-36, bezo-gen unter: http://dx.doi.org/10.1145/352029.352035, Zugriff am 26.04.2014

Verband der Automobilindustrie (2010): Automotive Spice® Process Assessment Model, Version 2.5, bezogen unter: http://www.automotivespice.com/fileadmin/software-download/automotiveSIG_PAM_v25.pdf, Zugriff am 01.06.2014

Voelter, M. (2013): DSL Engineering: Designing, Implementing and Using Domain-Specific Languages, 1. Aufl., CreateSpace Independent Publishing Platform


42

Vonhoegen, H. (2011): Einstieg in XML, 6. Aufl., Bonn: Galileo Press GmbH WhatIs (2014): Definition compiler, bezogen unter:

http://whatis.techtarget.com/definition/compiler, Zugriff am: 12.06.2014

Releasespezifisches Verwalten von betreiberInnenspezifschen Steuerungsdaten auf Basis von...

Documents

Transcript of Releasespezifisches Verwalten von betreiberInnenspezifschen Steuerungsdaten auf Basis von...