Diplomarbeit_Pavel_H..

Transcription

Universität Bremen
Fachbereich Mathematik/Informatik
Quelloffene Content Management Systeme
zwischen relationaler und XML-Persistenz
– Ein Vergleich aus Entwicklersicht –
Diplomarbeit
Pavel Hasanov
12. Februar 2010
Gutachter:
Prof. Dr. Karl-Heinz Rödiger
Dr. Dieter Müller
Erklärung der Selbstständigkeit
Hiermit versichere ich, die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie die Zitate deutlich
kenntlich gemacht zu haben.
Bremen, den 06.01.2010
Pavel Hasanov
Inhaltsverzeichnis
1 Einleitung
1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Content Management System . . . . . . . . . .
2.1.1 Web Content Management System . . .
2.1.2 Enterprise Content Management System
2.1.3 Grundfunktionalitäten eines CMS . . . .
2.1.4 Vorteile von XML in einem CMS . . . .
2.2 CMS-Techniken und Datenhaltung . . . . . . .
2.2.1 Techniken . . . . . . . . . . . . . . . . .
2.2.2 Datenhaltung . . . . . . . . . . . . . . .
2.2.2.1 Datenbanken . . . . . . . . . .
2.2.2.2 Speicherung ohne Datenbank .
2.2.2.3 XML-fähige Datenbanken . . .
2.3 Schlussbemerkung . . . . . . . . . . . . . . . . .
3 Auswahl der Systeme
3.1 Auswahlkriterien . . . . . . . . . . . . .
3.1.1 Funktionale Kriterien . . . . . . .
3.1.2 Nicht-funktionale Kriterien . . . .
3.1.2.1 Benutzbarkeits-Kriterien
3.1.2.2 Lizenz-Kriterien . . . .
3.1.2.3 Datenhaltungs-Kriterien
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
5
6
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
10
10
12
13
13
15
15
16
16
18
.
.
.
.
.
.
20
20
21
21
21
22
22
Inhaltsverzeichnis
3.2
3.3
ii
Marktübersicht . . . . . . . . . . . . .
3.2.1 Filterung nach K.O.-Kriterien .
3.2.2 CMS Award . . . . . . . . . . .
3.2.3 Google Summer of Code . . . .
3.2.4 Wappalyzer-Statistik . . . . . .
3.2.5 Ergebnisse der Sekundäranalyse
Beschreibung der Systeme . . . . . . .
3.3.1 TYPO3 . . . . . . . . . . . . .
3.3.2 Joomla . . . . . . . . . . . . . .
3.3.3 Drupal . . . . . . . . . . . . . .
3.3.4 eZ Publish . . . . . . . . . . . .
3.3.5 Papaya CMS . . . . . . . . . .
4 Untersuchung
4.1 Theoretische Grundlage . . . . .
4.1.1 Qualitätssicht . . . . . . .
4.2 Evaluationsmethode . . . . . . .
4.2.1 Experte . . . . . . . . . .
4.3 Evaluationsverfahren . . . . . . .
4.4 Kriterienkatalog . . . . . . . . . .
4.5 Fragenkatalog . . . . . . . . . . .
4.5.1 Fragen zu Benutzbarkeit .
4.5.1.1 Verständlichkeit .
4.5.1.2 Erlernbarkeit . .
4.5.2 Fragen zu Änderbarkeit .
4.5.2.1 Analysierbarkeit
4.5.2.2 Modifizierbarkeit
4.5.2.3 Stabilität . . . .
4.5.2.4 Prüfbarkeit . . .
4.5.3 Fragen zu Übertragbarkeit
4.5.3.1 Anpassbarkeit . .
4.5.3.2 Installierbarkeit .
4.5.3.3 Konformität . . .
4.5.3.4 Austauschbarkeit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
25
26
28
29
29
30
30
31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
34
35
36
36
37
43
43
43
44
44
45
45
45
46
46
46
47
47
47
Inhaltsverzeichnis
iii
5 Auswertung
5.1 Systeme auf relationaler Basis . . . . . . . . . . . . . .
5.1.1 Benutzbarkeit . . . . . . . . . . . . . . . . . . .
5.1.2 Änderbarkeit . . . . . . . . . . . . . . . . . . .
5.1.3 Übertragbarkeit . . . . . . . . . . . . . . . . . .
5.2 XML-basierte Systeme . . . . . . . . . . . . . . . . . .
5.2.1 Benutzbarkeit . . . . . . . . . . . . . . . . . . .
5.2.2 Änderbarkeit . . . . . . . . . . . . . . . . . . .
5.3 Vergleich der relationalen und XML-basierten Systeme
5.3.1 Benutzbarkeit . . . . . . . . . . . . . . . . . . .
5.3.2 Änderbarkeit . . . . . . . . . . . . . . . . . . .
5.4 Schlussfolgerung . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
50
53
55
57
57
59
60
62
62
64
66
68
6 Zusammenfassung und Ausblick
69
Literaturverzeichnis
72
Onlineverzeichnis
76
Abbildungsverzeichnis
79
Tabellenverzeichnis
80
Abkürzungen
81
Anhang
82
A Fragenkataloge
A.1 TYPO3 . . .
A.2 Joomla . . . .
A.3 Drupal . . . .
A.4 eZ Publish . .
A.5 Papaya CMS
A.6 Fragenkatalog
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
84
89
94
99
104
109
Kapitel 1
Einleitung
Der Web-Auftritt ist heutzutage zu einer der wichtigsten Komponenten der Außendarstellung von Unternehmen und anderen Körperschaften geworden. Für die
meisten Unternehmen ist ein eigener Internetauftritt mittlerweile unverzichtbar. In
Deutschland waren im Jahr 2008 laut dem Bundesverband Informationswirtschaft,
Telekommunikation und neue Medien (BITKOM) [Schulz 2008] vier von fünf Unternehmen (78%) im Internet präsent. Das entspricht einer Steigerung von 5% gegenüber dem Jahr 2006.
Die in vielen Fällen erste Begegnung und dadurch auch den ersten Eindruck von
der Firma bekommt der Kunde durch ihre Internetpräsenz. Die Webseite ist ein
‚Gesicht‘ der Firma, das attraktiv und anziehend sein soll. Zusätzlich ist sie eine
Pinnwand der Firma, wo informative und aktuelle Daten veröffentlicht werden.
Das Leben im Unternehmen ‚brummt‘, die Produkte und Leistungen ändern sich
bzw. werden ständig erneuert, die Angebote müssen bekannt gegeben werden. Diese
Änderungen sollen auch auf der Webseite vorgenommen und zeitnah einer breiten
Öffentlichkeit zugängig gemacht werden; nur so kann der Internetauftritt immer
nützlich und effektiv bleiben.
Die Pflege der Webseite ist aber kein einfacher Prozess, da sie Kenntnisse in Programmierung und Grafikdesign erfordert. Bei einer statischen Internetseite müsste
man jedesmal einen Dienstleister für die Aufgaben beauftragen. Damit man diese
Kosten und Aufwendungen sparen kann, kommen sogenannte Content Management
Systeme (CMS) zu Hilfe, die den Inhalt vom Design und der Funktionalität trennen.
1.1 Problemstellung
2
Immer mehr Unternehmen steigen von einer statischen HTML-Seite auf solche dynamischen, redaktionellen Systeme um und gewinnen dadurch die technische Freiheit
bei der Pflege der Inhalte.
Die Geschichte der Inhaltsverwaltung mit Hilfe von CMS ist bereits mehr als 10
Jahre alt. Innerhalb dieser Zeit sind mehr als 2000 Systeme (nach [Hein 2009]) auf
dem Markt erschienen. Viele davon sind kleine Agenturlösungen, die zu unbekannt
oder zu speziell sind, um sich nachhaltig durchzusetzen. Andere sind durch Lizenzgebühren und hohen Entwicklungsaufwand zu kostenintensiv, was der Grund dafür
ist, weshalb nur große Unternehmen diese nutzen. Heutzutage werden immer mehr
Lösungen unter Open-Source-Lizenzen gestellt. Dabei setzt man auf ein anderes
Erfolgsmodell: man bietet die kostenlosen Systeme mit kostenpflichtigem professionellem Support anstelle von Lizenzkosten für die Software und den Support an. So
können sich zumindest auch die kleineren oder mittleren Unternehmen ein System
als einfaches Basis-Modell leisten.
1.1 Problemstellung
Das breite Auswahlspektrum der CMS macht es schwierig, sich für ein bestimmtes System zu entscheiden. Es existieren in dem Bereich Produkte von einfachster
Webseiten-Gestaltungssoftware bis hin zu großen E-Business-Portal-Lösungen (vgl.
[Kampffmeyer 2007, S. 256]). Trotz der Vielfalt der Systeme gibt es wenige, die solche wichtigen Aspekte wie Webstandards, Flexibilität oder Erweiterbarkeit leisten,
meint der Web- und Content-Management Experte Ansgar Hein [Hein 2009]. Ihm
zufolge sind die meisten Systeme von eher durchschnittlicher Qualität. Die Entwickler fokussieren sich eher auf die Funktionalität der Systeme. Das Problem dabei ist,
dass viele bekannte Systeme schon länger auf dem Markt sind und eine veraltete
Struktur haben. Inzwischen ist schon einiges passiert in der Internet-Welt. Nicht
nur die Ära des Tabellen-Layouts ist vergangen; auch die Software-Architektur hat
eine neue Richtung bekommen, die mehr den Blick auf offene Schnittstellen und
Flexibilität richtet. Deswegen wäre es sinnvoll, zuerst die Architektur des gesamten Systems anzupassen, bevor man die zahlreichen neuen Funktionen als externe
Software-Bausteine (sogenannte Erweiterungen) entwickelt.
1.1 Problemstellung
3
Open Source (OS)-Lösungen für CMS werden von vielen Firmen häufig wegen der
kostenfreien Nutzungsrechte eingesetzt. Das Aufsetzen eines solchen Systems mit
Hilfe einer Installationsanleitung kann ziemlich einfach verlaufen. In den meisten
Fällen reicht es Unternehmen nicht aus, lediglich eine sogenannte Dummy-Seite zu
benutzen, weil jede Firma Präferenzen und Vorstellungen der eigenen Internetpräsenz hat. Häufig besteht ein Bedarf an neuen Funktionalitäten, die programmiert
und an das System angepasst werden müssen. Die Problematik hierbei ist, dass die
in den Firmen gegebenenfalls vorhandenen IT-Mitarbeiter sich mit der Architektur
der Systeme nicht auskennen.
Die CMS sind unterschiedlich aufgebaut. Unterschiede beginnen schon auf der
Datenbank-Ebene, bei denen zwei verschiedene Herangehensweisen zum Speichern
der Daten zu unterscheiden sind: datenbankbasierte und dokumentenzentrierte
Speicherung. Die meisten CMS bedienen sich der datenbankbasierten Speicherung,
häufig in einer Kombination aus dem Datenbanksystem MySQL und der Skriptsprache PHP. Zusätzlich wird häufig eine eigene Skriptsprache für interne Einstellungen
und Konfigurationen eingesetzt. Systeme, die auf diese Weise aufgebaut sind, erfordern einen hohen Programmieraufwand. Des Weiteren gelingt es den firmeninternen
IT-Mitarbeitern nicht, zeitnah in die Architektur eines solchen Systems einzusteigen
und die Semantik von Skriptsprachen zu verstehen. Änderungen, Anpassungen oder
Erweiterungen kosten demnach entweder viel Zeit oder man beauftragt eine externe
Firma, die sich um die Belange des Unternehmens kümmert. In jedem Fall ist es ein
außerplanmäßiger Kostenfaktor, der bei der Entscheidung eines kostenlosen CMS
nicht bedacht wurde.
Oftmals wird vergessen, dass das Ziel eines OS-Produktes ist, anderen Entwicklern
die Möglichkeit zu geben, das System zu erweitern, um dieses möglichst fehlerfrei, erfolgreicher und ansehnlicher zu machen. Ein OS-System sollte eine saubere
und klare Struktur vorweisen, um eine stabile Plattform für die Weiterentwicklung
zu bieten. Dabei ist es sinnvoll, Standards zu verwenden, um das Interesse einer
möglichst breiten Masse zu wecken und Spezialisten in diesen Bereichen mit einzubeziehen. Die Verwendung der dokumentenzentrierten Methode kann viele Vorteile
haben. Dabei werden die einzelnen Internet-Dokumente als übersichtliche, menschenlesbare XML-Dateien gespeichert. Die Transformation in HTML-Dokumente
erfolgt per XSLT, einem offenen Standard, der leicht erlernt werden kann. Systeme
auf dieser Basis sind bereits vorhanden, werden aber selten eingesetzt und von den
1.1 Problemstellung
4
rein datenbankbasierten vom Markt gedrängt.
Mehrere Systeme wurden bereits mit einander verglichen; es existieren zahlreiche
Veröffentlichungen auf diesem Gebiet. Außerdem listen mehrere Internetseiten und
Online-Portale eine große Auswahl von CMS in der Datenbank zur Gegenüberstellung auf. Der Vergleich dabei ist eher benutzerorientiert. Benutzer können sich
dadurch leicht einen Überblick über die riesige Auswahl an Systemen verschaffen
und das am besten für ihre Bedürfnisse passende System aussuchen, ohne vorher
alle zu installieren und auszuprobieren. Die Systeme sind sehr detailliert beschrieben; somit wird dem Benutzer die perfekte Einstiegsplattform in die CMS-Welt
geboten.
Bei diesen Vergleichen fehlt aber die Information, die für Entwickler interessant ist.
Diese Kategorie hängt sehr eng mit der OS-Lizenz zusammen, da man die Möglichkeit hat, die Entwicklung der Software zu beeinflussen und eigene Ideen in den
Systemen zu realisieren. Damit sind nicht die Erstentwickler (die Autoren) von Systemen gemeint, sondern auch die Entwickler in der Community, die sich in Kernund Erweiterungsentwickler aufteilen (nach [Hauser 2008, S. 247]), und die Gruppe der Anwender, die das System erweitern sollen und für individuelle Bedürfnisse
(bzw. Bedürfnisse der Kunden) anpassen sollen. Im zweiten Fall sind es meistens
die Administratoren der Systeme, die über Programmier-Kenntnisse verfügen und
das System dementsprechend nicht nur aufsetzen, sondern auch ändern bzw. erweitern können. Häufig entwickeln sie selbst die Erweiterungen und veröffentlichen sie.
Dadurch kommt es zu möglichen Überschneidungen der beiden Gruppen, die in der
Abbildung 1.1 anschaulich dargestellt sind.
Als Folgerung aus dem oben Gesagten kann man drei wichtige Problemstellungen
festlegen, die ein Schwerpunkt dieser Arbeit sind:
• große Auswahl an OS-CMS, aber wenig qualitative;
• es gibt Standard-basierte Systeme (XML), die aber wenig verwendet werden;
• ein Vergleich der Systeme unter technischen Aspekten fehlt.
1.2 Motivation
5
Abbildung 1.1: Mögliche Überschneidungen der Entwickler- und Anwendergruppen in einer OS-Community ([Hasecke 2008, S. 20])
1.2 Motivation
Eine vierjährige Nebenbeschäftigung als studentische Hilfskraft bei einer Medienagentur hat den Autor dieser Arbeit mit einem der verbreitetsten CMS unter einer
Open-Source-Lizenz TYPO3 ([Ahlswede 2009]) bekannt gemacht. In diesem Sinne war er einer der Anwender, der das System aus technischer Seite verwendet
und weiterentwickelt hat. Seine Aufgabe war die Erstellung von Internet-Seiten mit
TYPO3 und die Anpassung des Systems an Kundenanforderungen. Häufig sollten
Erweiterungen geändert oder individuelle entwickelt werden.
Der Einstieg in das System war relativ zeitaufwendig. Die interne Struktur war für
den Autor und seine Kollegen zu unübersichtlich. Zusätzlich hat die schwer erlernbare und gewöhnungsbedürftige Skriptsprache TypoScript die Arbeit mit TYPO3
behindert. Dadurch ist die Wartung der erstellten Web-Auftritte und die Realisierung neuer Kundenanfragen mit hohem Zeitaufwand verbunden gewesen.
Mittlerweile hat die TYPO3-Community neue Versionen herausgebracht, deren Code erheblich aufgeräumter ist; allerdings wurde die eigentliche Arbeit und die Wartung des Systems nicht wirklich erleichtert. Es werden immer noch keine Standards
verwendet, und die Struktur ist unverändert geblieben.
1.3 Aufbau der Arbeit
6
Im Laufe der Zeit entstand die Idee, ein eigenes CMS auszuarbeiten. Der Hauptunterschied zu den meisten CMS sollte die Inhaltsspeicherung in XML-Format sein,
um die Daten flexibel, strukturiert und erweiterbar zu machen und einen akzeptierten Standard einzuführen. Dafür bräuchte man keinen Spezialisten, der sich mit dem
System auskennt sondern einen, der XML- und XSLT-Programmierung beherrscht
und der nach einer kurzen Einarbeitungszeit mit dem System vertraut ist.
Bei der Recherche hat sich ergeben, dass es OS-Produkte solcher Art bereits gibt,
diese sich jedoch nicht wirklich durchgesetzt haben. Es stellt sich daher die Frage,
warum dies nicht geschehen ist?
Auf Basis dieser Probleme und Fragen ist das Thema dieser Diplomarbeit entstanden.
1.3 Aufbau der Arbeit
Die vorliegende Arbeit ist in sechs Kapitel aufgeteilt. Das aktuelle Kapitel schafft
eine Einleitung zu dem Thema und zum Aufbau der Arbeit. In dem zweiten Kapitel wird Hintergrundwissen über die verschiedenen Arten von CMS vermittelt.
Außerdem werden hier mögliche technische Konstrukte für ein CMS vorgestellt und
beschrieben. Der Fokus ist dabei auf verschiedene Möglichkeiten der Datenhaltung
gelegt; dabei werden XML- und relationale Datenbanken miteinander verglichen.
Im dritten Kapitel werden die zu untersuchenden Systeme der beiden DatenhaltungsMethoden aus der großen Vielfalt ausgesucht. Dafür werden zuerst die Mindestanforderungen an CMS definiert und es wird eine Sekundäranalyse durchgeführt.
Anschließend werden die ausgewählten Systeme in diesem Kapitel beschrieben.
Das Untersuchungsverfahren wird im vierten Kapitel ausgearbeitet und vorgestellt.
Des Weiteren wird hier der Kriterienkatalog für die Evaluation zusammengestellt.
Im fünften Kapitel wird der Ablauf der Evaluation in einzelnen Schritten beschrieben. Hier werden die Systeme nach ausgewählten Kriterien untersucht.
Abgeschlossen wird die Arbeit mit dem sechsten Kapitel, das sich mit der Zusammenfassung und Analyse der Ergebnisse der Untersuchung befasst.
Kapitel 2
Grundlagen
Bevor man sich in den ‚Dschungel‘ der Angebote an OS CMS-Produkten begibt,
um das passende auszusuchen, wird in diesem Kapitel CMS als allgemeiner Begriff
betrachtet, werden seine Aufgaben spezifiziert und die verschiedenen Formen der
Systeme angegeben. Da eine Gruppe der zu untersuchenden Systeme die Besonderheit hat, Inhalte im XML-Format zu speichern, wird zusätzlich in diesem Kapitel
auf XML-Einsatz in einem CMS eingegangen. Außerdem werden mögliche CMSKonstrukte vorgestellt und verschiedene Ansätze zur Datenhaltung in einem CMS
beschrieben.
2.1 Content Management System
Unter einem CMS versteht man ein Softwaresystem zum Erstellen, Pflegen und Zusammenführen verschiedener Inhalte. Der Inhalt bezeichnet dabei jede Art von Informationen, Bildern und Dokumenten in verschiedenen Datei-Formaten. Die Ausgabe kann auf unterschiedlichen Medien erfolgen. Beispiele für mögliche Ergebnisse sind Kataloge, Bücher, Preislisten, Technische Dokumentationen, CD-ROMs,
Webseiten oder PDFs (laut der Begriffserklärung auf der eforia web manager-Seite
[Efo 2009]). Grundsätzlich wird das Layout vom Inhalt beim Erstellungsprozess getrennt, so dass Anpassungen am Design einfacher vorgenommen werden können. Bei
den meisten CMS werden auch die Inhalte von externen Dokumenten abgegrenzt,
so wie es in Abbildung 2.1 am Beispiel eines Internet-Mediums dargestellt ist.
8
Abbildung 2.1: Aufbau eines CMS ([Winkler 2001])
Bei der Betrachtung des Themas Content Management (CM) muss zwischen zwei
speziellen Ausprägungen, dem Web Content Management System (WCMS) und
dem Enterprise Content Management System (ECMS) unterschieden werden (nach
[Kampffmeyer 2007, S. 256]). Beide Ausprägungen entstehen aus verschiedenen Ursprüngen; ihre Funktionen sind in der Regel auf abweichende Schwerpunkte festgelegt.
2.1.1 Web Content Management System
Wie der Name schon ausdrückt, ist ein WCMS ein Content Management System,
das auf die Erstellung und Verwaltung von digitalen Daten mit dem Schwerpunkt
auf das Medium Internet spezialisiert ist (vgl. [Grume 2003, S. 4]). Das System läuft
üblicherweise auf einem Webserver und ermöglicht die selbständige Bearbeitung von
Internetseiten ohne Web- und HTML-Kenntnisse.
Ein WCMS besteht aus zwei Teilen: dem sogenannten Backend (Redaktionsansicht),
das zur Pflege der Daten dient, und einem Frontend, das die Inhalte nach außen im
World Wide Web (WWW) präsentiert. Die Verwaltung und die Inhaltspflege finden
komplett über den Web-Browser statt.
An dieser Stelle ist zu erklären, dass die in dieser Arbeit untersuchten CMS alle
webbasiert sind und literaturgemäß WCMS heißen sollen. Üblicherweise wird der
Begriff Web Content Management System, insbesondere im deutschen Sprachraum,
9
als Synonym zu CMS benutzt ([Stamm 2002]). Die meisten kennen diese Art Systeme nur unter letzterem Namen; aus diesem Grund wird dieser allgemein anerkannte
Begriff auch in dieser Diplomarbeit benutzt und im Folgendem nur noch die Abkürzung CMS verwendet.
2.1.2 Enterprise Content Management System
Heutzutage werden viele, insbesondere kommerzielle CMS mit dem EnterpriseZusatz bezeichnet (vgl. [Hauser 2008, S. 247]). Häufig ist das nur eine Marketingstrategie, um ein Produkt auf dem Markt anzupreisen. In diesem Fall wird
der Begriff missbraucht und die Enterprise-Benennung als besonders groß, schön
und teuer verstanden. Hinzu kommt die Tatsache, dass WCMS und CMS oftmals
gleichbedeutend verwendet werden (siehe Abschnitt 2.1.1). Damit wird die Verwirrung verstärkt und es ergibt sich, dass ein ECMS ein System ist, welches lediglich
zur Verwaltung von großen Internetseiten dient.
Die Verwirrung kommt dadurch, dass es nicht um das Wort Enterprise als Begriffszusatz geht, sondern um den Enterprise Content als Paarwort. Damit wird
der ganze Dokumentenbestand des Unternehmens gemeint - sei es Web, Intranet,
Mail oder Papier, sei es Text, Foto oder Film. So ist ein ECMS ein System, das alle Unternehmensinformationen an jedem beliebigen Ort jederzeit verfügbar macht
und damit eine essentielle Grundlage für den Erfolg moderner Unternehmen bietet
([Krüger 2007b]). Solche Systeme besitzen einen erheblichen Funktionsumfang und
werden meistens in großen Firmen eingesetzt.
2.1.3 Grundfunktionalitäten eines CMS
Wie bereits aus der Definition der CMS (siehe Abschnitt 2.1) klar geworden ist, ist
die Trennung von Inhalten und Design eines der wichtigsten Merkmale von CMS.
Dabei wird das Design oder Layout konventionell über Vorlagedateien, sogenannten Templates, bestimmt. Der eigentliche Inhalt wird dagegen entweder in einer
Datenbank oder in Dateien gehalten und mittels bestimmter Platzhalter an den
vorgesehenen Stellen in das Template eingefügt. Die Eingabe der Inhalte erfolgt
10
über die Formulare im Backend; so werden Texte, Dokumente, Links und andere Inhaltselemente eingefügt. Beim Einstellen von Inhalten über die Eingabemaske
der Formulare wird die Struktur der Seite bereits erkennbar gemacht. Dies ist ein
sogenanntes WYSIWYG-Prinzip (What You See Is What You Get). Dabei wird
die zu bearbeitende Seite bzw. das Seitenelement dem Redakteur genauso oder
sehr ähnlich dargestellt, wie es nachher im Frontend aussehen wird. Das Template
und der Inhalt werden im Betrieb dynamisch zusammengestellt; dadurch wird eine
HTML-Seite generiert (vgl. [Thiess 2003, S. 11]).
Bei der Pflege der Internetseite sind meistens mehrere Personen, wie Redakteure,
Webdesigner und Administratoren involviert. Jeder hat Aufgaben, die unabhängig
von einander erledigt werden müssen. Daher besitzt ein CMS optimalerweise eine
Benutzerverwaltung zusammen mit einem Gruppen- bzw. Rollenkonzept. So können
mit weniger Aufwand für jeden Benutzer genau die Rechte definiert werden, die er
zur Erfüllung seiner Aufgaben benötigt.
Des Weiteren gehört die Unterstützung des sogenannten Workflow-Management
ebenfalls zu den typischen Funktionen eines CMS (laut [eTe 2007]). Damit ist es
möglich, die Inhalte wie in einem klassischen Redaktionsarbeitsablauf zu bearbeiten. Hierbei werden die Inhalte nach der Erstellung bzw. Bearbeitung von einem
Redakteur nicht direkt publiziert, sondern zuerst zur Kontrolle an den Chefredakteur übergeben, der bei Bedarf redigiert und die Inhalte erst dann freischaltet. Somit
macht die Unterstützung von Workflow-Management in einem CMS die Qualitätssicherung der Inhalte möglich.
Ein weiteres wichtiges Merkmal eines CMS ist die Wiederverwendbarkeit von Inhalten ([eTe 2007]). Diese Funktionalität entsteht eigentlich als positiver Nebeneffekt
aufgrund der Trennung von Inhalten und Design. Durch diesen Nebeneffekt kann
immer wieder auf eine Inhalts-Komponente zurückgegriffen werden, ohne sie neu
produzieren zu müssen.
Heutzutage hat der Austausch von Inhalten zwischen verschiedenen Webseiten im
Internet an Bedeutung gewonnen. Dieser Prozess der Mehrfachverwendung von Inhalten wird als Content Syndication bezeichnet und zählt zu einer der Grundfunktionalitäten eines modernen CMS. Hier erfolgt der Import bzw. Export der Inhalte
größtenteils im XML-Format. Die XML-Technologie ist nicht nur bezüglich der Con-
11
tent Syndication nützlich, sondern dient allgemein ebenfalls der Effizienz bzw. der
Qualität eines CMS, was im nächsten Abschnitt genauer gezeigt wird.
2.1.4 Vorteile von XML in einem CMS
Es gibt kaum einen anderen Standard, der in der Literatur in Bezug auf CMS
so häufig erwähnt wird, wie das XML-Format (siehe [Hüttenegger 2006, S. 47]).
Grundsätzlich wird XML in einem System für zwei Zwecke eingesetzt: der eine
ist der Import bzw. Export von Inhalten, der andere die gesamte Speicherung der
Inhalte. Der Im- und Export wird heute von den meisten CMS unterstützt; es
werden Funktionen zur Verwaltung von XML-Dokumenten und zur Konvertierung
der unterschiedlichen Inhalte in das XML-Format angeboten (vgl. [Christ 2007, S.
34]). Auf die möglichen Ansätze für die XML-Inhaltsspeicherung wird später im
Abschnitt 2.2.2.3 noch eingegangen.
Basierend auf der Auflistung der XML-Stärken in der Arbeit von [Hüttenegger 2006]
kann man folgende zentrale Vorteile bei dem Einsatz dieser Technologie in einem
CMS feststellen:
• Natürliche Trennung von Layout, Struktur und Inhalt
Bei der Entwicklung des XML-Formats versuchten die Entwickler, dieses so
einfach wie möglich zu gestalten. Dabei war die Grundidee, Inhalt, Struktur
und Darstellung auf einfache Art klar von einander zu trennen. Diese Trennung wird durch das Aufteilen des XML-Konzeptes in drei Komponenten eine Dokumenttypdefinition (DTD), eine XML-Datei und ein Stylesheet - ermöglicht. Die Inhalte lassen sich dabei in beliebig kleine Einheiten zerlegen
und mit semantischen Informationen kennzeichnen. Eine DTD definiert, wie
diese einzelnen Elemente, deren Attribute und baumartige Struktur spezifiziert sind. Mit dem Stylesheet (CSS oder XSLT-Scripte) wird die Ausgabe
formatiert.
• einfache Erweiterbarkeit
Eine sehr wichtige Eigenschaft von XML ist die Erweiterbarkeit der jeweiligen
Sprache, die XML seinen Namen (extensible) verliehen hat. Da die Strukturinformationen leicht zugänglich sind und gut abgegrenzt in der DTD liegen,
2.2 CMS-Techniken und Datenhaltung
12
sind für die Änderungen bzw. Erweiterungen nur die Anpassungen der DTD
notwendig und keine Modifikation des CMS selbst.
• flexible Ausgabe
Dank der klaren Trennung von Darstellung und Inhalt können mit XML viele
Präsentationsmedien unterstützt werden. Über die Erstellung verschiedener
XSLT-Stylesheets ist es möglich, den Inhalt, zum Beispiel für ein Webmedium in einem XHTML-Format (XML-konforme Reformulierung von HTML)
auszugeben, für ein WAP-Handy in ein WML-Format zu transformieren oder
einfach als PDF-Dokument zum Drucken bereitzustellen. Die Gruppe der auf
XML-basierten Sprachen ist mittlerweile gewachsen.
• einfacher Datenaustausch
Wie vorher bereits erwähnt (siehe Abschnitt 2.1.3), hat sich XML als universelles Austauschformat für Inhalte besonders in der Internetwelt durchgesetzt.
Da in einem XML basierten CMS alle Inhalte in einer XML-Struktur liegen, ist
der Import bzw. Export ohne zusätzliche Konvertierungsmechanismen leicht
durchführbar.
Wie man sieht, werden alle Grundfunktionen, die im vorherigen Abschnitt 2.1.3
erläutert wurden, auf natürliche Weise mit der Verwendung von XML hervorragend
unterstützt. Die tatsächlichen Einsatzmöglichkeiten dieser Technologie in einem modernen CMS werden im nächsten Abschnitt (2.2) bei der Vorstellung der wichtigsten
Techniken und Ansätze zur Datenhaltung erläutert.
Da die Datenhaltung ein Schwerpunkt dieser Arbeit ist, werden im nächsten Abschnitt die angewandten Techniken und Methoden zur Inhaltsspeicherung aufgeführt.
2.2.1 Techniken
Wenn man bei den unterschiedlichen CMS hinter die ‚Kulissen‘ schaut, stellt man
schnell fest, dass für fast jede sinnvoll auf dem Webserver einsetzbare Program-
13
miersprache von C über TCL bis Python ein CMS existiert (vgl. [Braun 2007,
S. 92]). Die meisten Systeme basieren jedoch auf PHP und sind auf einer sogenannten LAMP-Technologie zugeschnitten. LAMP steht für Linux, Apache,
MySQL, PHP (auch Perl oder Python) und bedeutet, dass eine Anwendung für
einen Linuxserver mit installiertem Apache-Webserver konzipiert ist, auf dem das
Datenbankmanagementsystem MySQL und die Skriptsprachen PHP, Perl oder Python eingesetzt werden können. Die Popularität von in PHP implementierten CMS
zeigt einerseits, dass PHP bei Open-Source-Webentwicklern ziemlich beliebt ist
und demonstriert anderseits, wie einfach es ist, mit PHP entsprechende Funktionen
zu entwickeln (siehe [Hüttenegger 2006, S. 38]). Abgesehen davon lassen sich auf
LAMP zugeschnittene Systeme häufig auf einem preiswertem Web-Hosting-Paket
bei einem Internetdienstanbieter (engl. Internet Service Provider (ISP)) aufsetzen. Somit braucht man keine zusätzliche Software bzw. Software-Umgebung zu
bestellen oder einen eigenen Server zu betreiben; es entstehen keine extra Kosten.
Die meisten PHP- und Python-basierten Systeme sind im Allgemeinen älter als die
Java-Konkurrenz und haben somit eine längere Entwicklungszeit hinter sich. Sie verfügen in der Regel über einen größeren Funktionsumfang. Java bietet im Gegensatz
dazu viele Vorteile im Enterprise-Umfeld. Die Vorteile ergeben sich durch die Möglichkeit, den vollen Umfang der Java EE-Technologien1 nutzen zu können. Dank der
Java Connector Architecture (JCA) ist Java besonders vorteilhaft beim Integrieren
anderer Anwendungen. Dazu kommen noch die Stärken der für Java EE-Technologie
benötigten Server wie JBoss, BEA, IBM etc., die automatische Lastenverteilung, hohe Skalierbarkeit und Ausfallsicherheit garantieren (nach [Sommergut 2005]). Allerdings sind viele davon kommerziell und außer der Miete der Server-Hardware (bzw.
Kosten für den eigenen Server) können noch zusätzliche Lizenzgebühren anfallen.
Weiter sind die CMS auf Java-Basis wegen der dahinter liegenden Komplexität und
Mächtigkeit weniger flexibel (vgl. [Hüttenegger 2006, S. 39]). Aus diesem Grund
sind die größeren CMS meist eher ECMS, auf Basis dieser Technologie umgesetzt
und mehr für die Nutzung von größeren Firmen geeignet.
Daneben gibt es noch etliche weitere CMS, die deutlich andere Technologien verwenden. Einige davon haben keine Datenbank für die Speicherung der Inhalte und sind
auf XML/XSLT-Technologie aufgebaut. Hier werden die Inhalte direkt im Datei1
ab Version 5 Namensänderung Java 2 Platform, Enterprise Edition (J2EE)
14
system als XML-Dokumente abgespeichert und einzelne XML-Knoten über XSLTAnweisungen für die Ausgabe formatiert. Dieser Einsatz wird gewöhnlich für kleinere Systeme angewendet. Die zahlreichen Anforderungen an moderne CMS und umfangreiche Funktionalitäten lassen sich mit dieser Technologie entweder schlecht umsetzen oder erfordern einen hohen Programmieraufwand und verlieren dabei enorm
an Performanz.
2.2.2 Datenhaltung
Wie bereits im vorherigen Abschnitt (2.2.1) deutlich geworden ist, unterscheiden
sich die CMS auf der Datenhaltungs-Ebene. Einerseits können Daten in einer
Datenbank abgelegt und andererseits direkt in einem Dateisystem gespeichert werden. Zum Speichern von XML-Daten in einer Datenbank gibt es wieder verschiedene
Lösungsansätze, die auch in diesem Abschnitt thematisiert werden.
2.2.2.1 Datenbanken
Damit die zahlreichen CMS-Funktionen realisierbar sind und die strukturierten Inhalte effektiv und zielgerecht benutzt werden können, müssen diese mit zusätzlichen Informationen (Attributen bzw. Metadaten) versehen werden. Dadurch kann
die Datenhaltung relativ komplex werden. Aus diesem Grund ist die Verwendung
eines Datenbankmanagementsystem (DBMS) anzuraten. Diese Systeme sorgen für
die sichere und dauerhafte Datenablage, da sie über Aspekte wie Systemsicherheit,
Datensicherheit oder Skalierbarkeit verfügen. So müssen die CMS sich nicht selbst
um solche Aufgaben kümmern (vgl. [Glantschnig 2004, S. 31]).
Relationale DBMS sind mit Abstand am weitesten verbreitet, sodass die Begriffe Datenbank und relationale Datenbank im allgemeinen Sprachgebrauch häufig
als Synonyme verwendet werden (siehe [Wittenbrink 2003]). Für die Inhaltsablage in den meisten CMS wird ebenso eine relationale Datenbank eingesetzt (vgl.
[Glantschnig 2004, S. 32]). Hierbei werden die Daten in Form einer zweidimensionalen Tabelle abgespeichert und mit Hilfe der Abfragesprache SQL angelegt und
manipuliert.
15
Zusätzlich gibt es eine kleine Anzahl an CMS, die die Inhalte in einer objektorientierten Datenbank abspeichern. Hier werden die Daten als Objekte verwaltet und
der Gedanke der Objektorientierung in der Datenbank fortgesetzt. Dadurch leisten
diese Datenbanken mehr, wie beispielsweise die Verwaltung komplexerer Objekte oder deren Kapselung. Dies kann sehr hilfreich bei der Programmierung von
CMS sein. Allerdings können bestimmte Zugriffe auf komplexere Objekte schnell
exponentiellen Aufwand erreichen und somit zu Performanzproblemen führen (vgl.
[Glantschnig 2004, S. 32]).
2.2.2.2 Speicherung ohne Datenbank
Die einfachste Methode, die Daten zu speichern, ist die Ablage in einem Dateisystem. Die Problematik besteht darin, die Daten in einer einfachen Textdatei
strukturiert zu halten; hier kommt die bereits erwähnte XML-Technologie zur Hilfe. Grundsätzlich können XML-Dateien die Rolle einer Datenbank in einem CMS
übernehmen und ihre Eigenschaften zur Datenhaltung ersetzen. Die Daten können nicht nur strukturiert nach einem XML-Schema abgelegt werden, sondern auch
mit Hilfe von XML-Anfragesprachen wie xPath oder xQuery durchsucht werden
[Glantschnig 2004, S. 48]. Somit verfügt ein CMS automatisch über die wichtigsten
Vorteile der XML-Technologie (siehe Abschnitt 2.1.4) und benötigt keine zusätzliche
Datenbank-Software für die Haltung und Organisation der Daten.
Allerdings stoßen die reinen XML-CMS bei den größeren Projekten oder bei speziellen technischen Umsetzungen schnell an ihre Grenzen. Das Hauptproblem ist
die Performanz. Um Operationen auf den Daten durchführen zu können, wird das
XML-Dokument bis auf die einfachsten Bestandteile (Knoten) zerlegt. Bei großen
und komplexeren Dokumenten kann dieser Prozess einige Zeit kosten; Zeit, die bei
einem DBMS eingespart wird. Deswegen wurden bereits Konzepte entwickelt, die
XML-Daten und relationale Datenbanken verkoppeln ([Winkler 2001]).
2.2.2.3 XML-fähige Datenbanken
Eine XML-Datenbank ist die dritte Lösung für die Datenhaltung in einem CMS; sie
ermöglicht die Speicherung der XML-Dokumente, Fragmente oder auch einzelner
16
XML-formatierter Daten innerhalb einer Datenbank ([Winkler 2001]). Hier unterscheidet man drei verschiedene Ansätze:
• Abbildung der XML-Struktur in der Datenbank (elementbasierte Speicherung)
• Speicherung der XML-Daten als CLOB (dokumentbasierte Speicherung)
• Einsatz von nativen XML-Datenbanken (XDBMS).
Bei den ersten zwei Ansätzen handelt es sich um eine traditionelle Datenbank,
die XML-erweitert2 ist und entweder eine XML-Struktur auf Tabellen mit entsprechenden Fremdschlüsselbeziehungen abbildet oder ein gesamtes XML-Dokument
komplett als einen Datentyp für sehr lange Zeichenketten, sogenanntes Character
Large Object (CLOB), in einer Tabellenspalte speichert. Der zuletzt aufgezählte
Ansatz stellt eine spezielle Datenbank dar, deren Architektur an die Verarbeitung
der XML-Dokumenten angepasst ist.
Abbildung der XML-Struktur
Nach der Abbildung der XML-Baumstruktur auf eine oder mehrere Tabellen ist
jedes einzelne XML-Element in der Datenbank vorhanden und somit über SQLAnfragen direkt zugreifbar und schnell auffindbar. Allerdings sind das XML-Schema
und das relationale Schema nicht exakt miteinander kompatibel. Das heißt, dass in
manchen Fällen auf einige Teile der physikalischen Struktur, wie die Reihenfolge
der einzelnen XML-Elemente oder Kommentare, verzichtet werden muss oder noch
kompliziertere Tabellenstrukturen aufgebaut werden müssen. Außerdem ist die Zerlegung des XML-Baumes in seine einzelnen Knoten (sogenanntes Shredding) und
seine über komplexe Datenbankanfragen erfolgte Zusammensetzung zu einem XMLDokument (sogenanntes Wrapping) oft sehr aufwendig und verschlechtert die Performanz des gesamten Systems. Zudem können bereits kleinste Änderungen in der
XML-Struktur erhebliche Auswirkungen auf das relationale Schema haben. Deswegen eignet sich dieser Ansatz am besten für die einfach strukturierten, einheitlichen
(datenorientierten) XML-Dokumente (vgl. [Päßler 2006, S. 43]).
CLOB-Speicherung
Durch die Ablage eines kompletten XML-Dokumentes in einer Datenbank wird seine
Struktur vollständig erhalten. Somit ist dieser Ansatz gut für komplex strukturierte
2
in der Literatur als XML-enabled bekannt
2.3 Schlussbemerkung
17
(textorientierte) XML-Daten geeignet. Der XML-Baum wird dabei aus einer CLOBZelle komplett eingelesen und muss für die Manipulation der einzelnen Teile geparst
werden. Deshalb treten hier die gleichen Probleme auf, wie bei der einfachen Ablage
der XML-Dokumente in einem Dateisystem (siehe Abschnitt 2.2.2.2).
Häufig wird dieser Ansatz mit dem ersten zusammen verwendet. Hier werden die
XML-Teile, die von dem System am meisten benötigt und verarbeitet werden, getrennt von den anderen XML-Daten gehalten. Dadurch erhöht man beispielsweise
die Suchgeschwindigkeit und ermöglicht die Sortierung (vgl. [Glantschnig 2004, S.
49]).
Native XML-Datenbanken
Bei der nativen XML-Unterstützung wird das Dokument in bereits geparster Form
in einer Datenbank, deren innere Architektur vollständig für XML optimiert ist,
direkt (nativ) gespeichert. Somit lässt sich jedes einzelne XML-Element über
einen Datenbankindex mit Hilfe einer erweiterten XML-Abfragesprache (XQuery
bzw. SQL/XML) schnell finden und manipulieren. Auch XML-Dokumente anderer
Struktur werden effizient gespeichert, ohne Änderungen im Datenbank-Schema
oder Anpassungen der Datei durchführen zu müssen. Allerdings sind diese Datenbanken viel jünger als die relationalen und deswegen noch nicht so ausgereift (vgl.
[Glantschnig 2004, S. 49]).
Es existieren viele CMS mit diversen Ausprägungen und den verschiedensten
Techniken, wobei die meisten auf die LAMP-Umgebung zugeschnitten und in
PHP/MySQL entwickelt sind. Der XML-Einsatz in einem CMS ist vorteilhafter,
da die auf XML-basierenden Systeme allein durch Eigenschaften dieser Technologie
die meisten Basisanforderungen abdecken, ohne zusätzliche Module entwickeln zu
müssen. Trotz alledem konnten sich nur wenige Systeme durchsetzen. Aus diesem
Grund wird hier der Schwerpunkt dieser Arbeit auf die Datenhaltung gesetzt und
bei der Auswahl der zu untersuchenden Systeme berücksichtigt. Es werden einerseits
die XML- und andererseits reine relationale Datenbank-basierende Systeme nebeneinander gestellt und auf definierte Qualitäten untersucht. Die beiden Gruppen
sind in der Abbildung 2.2 deutlich zu erkennen; hier sind die möglichen Methoden
18
zur CMS-Datenhaltung (siehe Abschnitt 2.2.2) dargestellt und die Gruppen von
einander klar getrennt.
Abbildung 2.2: Übersicht der CMS-Datenhaltung: Aufteilung in XML- und relationale Speicherungsgruppen
Kapitel 3
Auswahl der Systeme
Nach der detaillierten Darstellung der verschiedenen CMS und dem kurzen Einstieg in die CMS-Techniken, sollen in diesem Kapitel die Systeme ermittelt werden,
die im Folgenden untersucht werden. Hierfür wird eine sogenannte Sekundäranalyse durchgeführt. Dabei wird das bereits auf existierenden Internet-CM-Portalen
gesammelte Datenmaterial ausgewertet. Für die Durchführung werden die im vorherigen Kapitel erwähnten Basisanforderungen und die Speicherungsmethoden berücksichtigt und die gefundenen Systeme in zwei Gruppen (Datenhaltung mit und
ohne XML-Einsatz) aufgeteilt. Zuerst werden die zentralen Auswahlkriterien definiert und die Produkt-Listen auf entsprechenden Internet-Portalen durchsucht. Im
Anschluss werden die anhand der Kriterien ermittelten Systeme kurz vorgestellt.
3.1 Auswahlkriterien
In diesem Abschnitt werden die Mindestanforderungen festgelegt, über die die Systeme verfügen müssen, um für die Untersuchungen repräsentativ zu sein. Das sind
die zentralen Kriterien für die Systemauswahl und werden daher als K.O.-Kriterien
bezeichnet. Die Systeme, die diese K.O.-Kriterien nicht erfüllen, werden nicht weiter berücksichtigt. Bei der Festlegung der Mindestanforderungen wird auf die Liste der CMS-Auswahlkriterien in dem bereits angesprochenen ECM-Portal jdk.de
([Krüger 2007a]) zurückgegriffen. Die Anforderungen ergeben sich aus einer Kombination der eben genannten Liste und den Schwerpunkten dieser Arbeit und werden
in funktionale und nicht-funktionale Kriterien unterteilt.
20
3.1.1 Funktionale Kriterien
Die folgenden funktionalen Kriterien basieren hauptsächlich auf den allgemeinen
Grundfunktionalitäten eines CMS (siehe Abschnitt 2.1.3).
• Das System verfügt über eine zentrale Benutzerverwaltung und Rechtevergabe.
• Das System ist modular aufgebaut und erweiterbar, d.h. zusätzliche Funktionalitäten können als Erweiterungen hinzugefügt werden.
• Die Unterstützung von Arbeitsabläufen (Workflow-Management) ist vorhanden.
• Die Inhalte lassen sich in XML und im Newsfeedformat RSS importieren bzw.
exportieren.
• Versionierung von Dokumenten bzw. Inhaltselementen ist im System vorhanden.
• Die Performanz des Systems wird durch Caching unterstützt.
3.1.2 Nicht-funktionale Kriterien
Die nicht-funktionalen Kriterien werden wie folgt aufgeteilt:
• Benutzbarkeits-Kriterien
• Lizenz-Kriterien
• Datenhaltungs-Kriterien
3.1.2.1 Benutzbarkeits-Kriterien
Die Benutzbarkeits-Kriterien berücksichtigen bei weiteren Untersuchungen nur die
Systeme, deren Backend auch von Benutzergruppen mit lediglich durchschnittlichen
Computer-Kenntnissen effizient benutzt werden können und ausreichend Hilfe beim
Umgang und der Weiterentwicklung bieten.
• Die Trennung von Inhalt, Layout und Struktur ist gegeben.
21
• Die Inhalte können über einen WYSIWYG-Editor gepflegt werden.
• Das System ist mit Hilfehinweisen ausgestattet.
• Unterstützung durch Handbücher (sowohl für den Benutzer als auch für den
Entwickler), Community-Foren, Tutorials etc. ist vorhanden.
3.1.2.2 Lizenz-Kriterien
Die rechtlichen Rahmenbedingungen für die Nutzung einer Software werden unter einer Lizenz erfasst. Bei einer OS-Lizenz müssen die Nutzungsrechte nach den
Richtlinien der Open Source Initiative (OSI) anerkannt werden. Insgesamt wurden
bereits 66 verschiedene OS-Lizenzen von der OSI anerkannt und auf ihrer offiziellen Internetseite aufgezählt (siehe [Tiemann 2006]). Die am meisten verbreiteten
Lizenzen werden in der Abbildung 3.1 dargestellt.
Somit stellen die folgende Punkte die Lizenz-Kriterien dar:
• Das System steht unter einer der Open-Source-Lizenz.
• Eine Entwickler-Community ist vorhanden.
• Es wird eine Unterstützung durch die Community, Bücher etc. geboten.
3.1.2.3 Datenhaltungs-Kriterien
Da die Datenhaltung in einem CMS einer der Schwerpunkte dieser Arbeit ist, spielt
dieser Aspekt bei der Auswahl der Systeme eine große Rolle. Die zu evaluierenden
Systeme werden in zwei Gruppen unterschieden: zum einen die Produkte mit einer
XML-basierten Datenhaltung und zum anderen Systeme mit einer reinen relationalen Datenbank. Beide Methoden zur Datenhaltung wurden bereits im Abschnitt
2.2.2 vorgestellt und in der Abbildung 2.2 deutlich von einander getrennt. Die zu
untersuchenden CMS müssen somit eine Speicherungsmethode verwenden, die zu
einer der beiden in dieser Abbildung dargestellten Kategorien gehört.
3.2 Marktübersicht
22
Abbildung 3.1: Verteilung der Open-Source-Lizenzen ([Kleijn 2006])
3.2 Marktübersicht
Um die in der Praxis relevantesten Systeme zu finden, werden hier verschiedene
Ansätze angewendet und mehrere Internet-Portale als Analyse-Hilfsmittel herangezogen. Zuerst wird eine grobe Filterung nach vorher definierten Kriterien durchgeführt. Danach werden die am häufigsten verwendeten und bekannten CMS mit Hilfe
verschiedenen Statistiken und Projektteilnahmen bestimmt. Dabei werden immer
die Kriterien zur Datenhaltung berücksichtigt und die beiden erwähnten Gruppen
der Speicherung unterschieden.
3.2.1 Filterung nach K.O.-Kriterien
Für die Filterung der CMS nach den definierten Kriterien wird das webbasierte CMS-Auswahltool (http://www.cms-vergleich.de/) von Stefan Heinrich benutzt, das im Rahmen einer Studienarbeit an der FH Jena entstanden ist. Die Eingabemaske für die Suche der passenden CMS erlaubt es, die im vorherigen Abschnitt
definierten Kriterien einzugeben und die Systeme zu bewerten. Die Anfrage mit den
3.2 Marktübersicht
23
genannten K.O.-Kriterien hat als Ergebnis die folgende Liste an CM-Produkten geliefert:
• OpenPHPNuke
• Contrexx® Open Source WCMS
• Drupal
• TYPO3
• Zikula
• Papaya CMS
• Plone
Da cms-vergleich.de nur K.O.-Kriterien vergleicht, aber keine Angaben zu anderen
Qualitäten (z.B. Benutzbarkeit) macht, werden nun noch weitere Vergleiche herangezogen; dabei soll auch gesehen werden, welche dieser Systeme am häufigsten
verwendet werden.
3.2.2 CMS Award
Seit 2006 findet jährlich ein CMS-Wettbewerb (CMS Award) des englischen Verlages
Packt Publishing statt, bei dem die drei besten OS-CMS in verschiedenen Kategorien prämiert werden. Die Bewertung erfolgt in zwei Runden, wobei die VorrundenEntscheidungswahl den Benutzern überlassen wird, indem jeder sein bevorzugtes
System in entsprechenden Kategorien nominieren kann. In die zweite, finale Runde
kommen die fünf bestplatzierten CMS jeder Kategorie und werden dann von der
Jury, die aus CMS-Experten besteht, beurteilt. Unter der Haupt-Nominierung Best
Overall Open Source CMS werden bei der Systemwahl folgende Kriterien berücksichtigt: Performanz, Benutzbarkeit, Erreichbarkeit, Skalierbarkeit, einfache Installation und Anpassbarkeit (ease of configuration and customization), Sicherheit und
Unterstützung durch Community. Die Gewinner in dieser Kategorie in den letzten
drei Jahren1 sind in der Tabelle 3.1 aufgelistet.
1
die Finalisten des laufenden Jahres 2009 waren zum Zeitpunkt der Sekundäranalyse für diese
Arbeit noch nicht bekannt gegeben
3.2 Marktübersicht
24
1.
2.
3.
2006
Joomla
Drupal
Plone
2007
Drupal
Joomla
CMS Made Simple
2008
Drupal
Joomla
DotNetNuke
Tabelle 3.1: Die Gewinner der CMS Awards (Quelle: http://www.packtpub.com)
So sieht man, welche Systeme von den meisten Benutzern eingesetzt werden und
unter den genannten Kriterien führend sind.
3.2.3 Google Summer of Code
Bei dem Google Summer of Code (GSoC) haben qualifizierte Studenten die Möglichkeit sich durch die Weiterentwicklung ausgewählter OS-Projekte eine Geld-Premie
zu verdienen. Das GSoC-Programm ist auf einen Zeitraum von drei Monaten begrenzt. Dieses Jahr haben es drei CMS (TYPO3, Joomla, Drupal) geschafft, an dem
Projekt teilzunehmen und gehören damit zu den 150 ausgewählten OS-Projekten.
Sie stehen auf der Teilnehmerliste in einer Reihe neben solchen ‚OS-Giganten‘ wie
PHP, MySQL, Debian, Eclipse Foundation, Mozilla Project etc. Die Teilnahme an
dem GSoC-Programm bedeutet für die Systeme und deren Community nicht nur
Erweiterung und Neuentwicklung der Module, sondern auch einen Zuwachs der Entwickler in die Community und natürlich auch einen steigenden Bekanntheitsgrad
(nach [Hedemann 2009a]).
3.2.4 Wappalyzer-Statistik
Wappalyzer ist eine Erweiterung für den Webbrowser Firefox, die gesammelte Daten
über eine in diesem Browser angezeigte Internetseite direkt in dessen Statusleiste
darstellt. Die Daten werden von allen Wappalyzer-Benutzern zusammengefasst und
zentral in der Datenbank erhoben. Bei einer Anzahl von 167.435 Nutzern, die diese Erweiterung installiert haben, wurden bereits 1.135.418 Webseiten analysiert,
die in 78 verschiedenen Systemen (hauptsächlich CMS) aufgebaut sind2 . Mit dem
rasanten Anstieg der Benutzer und der Popularität des Firefox-Browsers hat die
2
Stand von 07.05.2009
3.2 Marktübersicht
25
Statistik-Datenbank von Wappalyzer sich zu einem mächtigen Marketing-Werkzeug
entwickelt (siehe [Hedemann 2009b]).
Die erfassten Daten kann man sich als globale Statistik auf der WappalyzerSeite (http://wappalyzer.com/stats) anzeigen lassen. Die auf CMS-Systeme
beschränkte Übersicht über die meist eingesetzten Systeme für April 2009 wird
in Abbildung 3.2 dargestellt. Wie man hier sehen kann sind Joomla, Drupal und
TYPO3 mit Abstand die beliebtesten Systeme. Von den Systemen die das XML
Format für die Speicherung unterstützen, sind nur wenige dabei (eZ Publish und
Papaya CMS).
Abbildung 3.2: Wappalyzer Statistik für April 2009: 20 meist verwendete CMS
3.2.5 Ergebnisse der Sekundäranalyse
Die Ergebnisse der Sekundäranalyse sind in der Tabelle 3.2 zusammengefasst. Alle
aufgelisteten Systeme erfüllen die gestellten K.O.-Kriterien und werden mit Abstand
am meisten eingesetzt.
3.2 Marktübersicht
26
Auswahlmethode
CMS-Auswahltool
CMS-Awards
GSoC
Wappalyzer
Systeme mit relationaler
Persistenz
OpenPHPNuke, Contrexx®
Open Source WCMS, Drupal, TYPO3, Zikula, Plone
Drupal (x3), Joomla (x3),
Plone, CMS Made Simple,
DotNetNuke
Drupal, Joomla, TYPO3
Joomla, Drupal, TYPO3
Systeme
mit
Persistenz
Papaya CMS
XML-
—
—
eZ Publish, Papaya CMS
Tabelle 3.2: Ergebnisse der Sekundäranalyse
In der ersten Gruppe (auf relationaler DB basierte Systeme) kann man deutlich
drei Favoriten erkennen (Drupal, Joomla, TYPO3), die am meisten (mindestens
dreimal) in den Analyse-Ergebnissen vorkommen. Im Rahmen dieser Arbeit werden
die weiteren Untersuchungen auf die drei Favoriten eingeschränkt.
Zu der zweiten Gruppe (Systeme mit XML-basierter Datenhaltung) wurden insgesamt nur zwei Produkte gefunden (eZ Publish, Papaya CMS). Das zeigt, dass
Systeme auf XML-Basis eher eine Minderheit auf dem freien Markt sind, obwohl
die Technik sehr gut für ein CMS geeignet ist (siehe Abschnitt 2.1.4).
In Grafik 3.3 wird anschaulich dargestellt, welche in Abschnitt 2.2.2 erwähnten
Techniken zur Datenhaltung genau von den ermittelten Systemen verwendet werden. Wie man deutlich erkennen kann, verwenden die beiden Systeme aus der
zweiten Gruppe dieselbe Technik zur XML-Speicherung: die Abbildung der XMLStruktur in einer relationalen Datenbank. Zu den anderen zwei Varianten der XMLDatenhaltung wurden keine Produkte gefunden. Des Weiteren konnte sich kein
System durchsetzen, welches auf reinen XML-Dokumenten basiert, da keines den
aufgestellten Kriterien entspricht. Die Systeme, die auf modernen nativen XML
Datenbankmanagementsystemen (XDBMS) aufgebaut sind, konnten sich ebenfalls
nicht durchsetzen, da XDBMS relativ jung sind und bis heute selten in CMS eingesetzt werden.
3.3 Beschreibung der Systeme
27
Abbildung 3.3: Übersicht der CMS-Datenhaltung und der gewählten Systeme
In diesem Abschnitt werden die durch die Sekundäranalyse gefundenen Systeme beschrieben. Alle Systeme sind auf die LAMP-Technlogoie zugeschnitten und stehen
unter GPL-Lizenz offen zur Verfügung. Hinter jedem von diesen steht eine starke Community, die Entwickler und Benutzer vernetzt. Außerdem wird eine große
Unterstützung durch Handbücher, Diskussionsforen und Dienstleister zu jedem Produkt geboten. Allerdings verfolgt jedes einzelnes CMS seine eigenen Ziele und besitzt
dadurch seine eigenen Stärken und Schwächen, die im Folgenden kurz angedeutet
werden.
28
3.3.1 TYPO3
TYPO3 ist bereits seit 1998 auf dem Markt und ist heutzutage eines der umfangreichsten und meist eingesetzten OS-CMS weltweit (vgl. [Lammenett 2007, S. 10]).
TYPO3 ist reich an Funktionen; seine Möglichkeiten gehen weit über die typischen
Aufgaben eines WCMS hinaus. Daher wird das System häufig auch als Framework
oder Entwicklungsplattform eingesetzt und der Enterprise-Klasse zugeordnet (vgl.
[Lammenett 2007, S. 12]). Die damit verbundene Komplexität macht es jedoch für
Entwickler schwer, das System zu erlernen ([typ 2009]).
Die eigene Konfigurationssprache TypoScript ist sehr mächtig, aber mit keiner verbreiteten Programmiersprache vergleichbar und erschwert dadurch den Einstieg.
Mit TypoScript lassen sich nicht nur bestimmte Konfigurationen an der Seite und
den Erweiterungen vornehmen, sondern jede kleinste Komponente der Internetseite
kann dadurch eingestellt, verändert oder neu erstellt werden. So kann die Ausgabe
der Seite extrem automatisiert werden.
Es existieren viele Organisationen bzw. Unternehmen, die sich für TYPO3 entschieden haben und die eigene Internet-Präsenz mit TYPO3 betreiben. Viele davon sind
weltweit bekannt, wie UNICEF, DFB (Deutscher Fussball-Bund), Epson, Philips,
zahlreiche Universitäten und viele mehr.
3.3.2 Joomla
Joomla ist aus dem OS-Projekt Mambo im Jahr 2005 hervorgegangen und ist inzwischen eines der meistverbreiteten CMS weltweit. Joomla wurde mit dem Ziel
entwickelt, die Struktur und Benutzbarkeit des Systems sowohl für Administrator als auch für Redakteur möglichst einfach zu gestalten, um Internettauftritte
schnellstmöglich zu realisieren. Daher wird Joomla als besonders leicht erlernbares System bezeichnetet und ist im Schwerpunkt für kleinere und mittlere Projekte
gedacht; es wurde aber bereits für die Realisierung größerer Internetseiten der unterschiedlichsten Art eingesetzt ([Steyer 2007]). So hat Joomla bei Unternehmen und
Organisationen wie Porsche (in Brasilien), Olympus (in Australien), der Organisation der Vereinten Nationen (UNO), einen der akademischen Einheiten (‚Schools‘)
der Harvard University und vielen anderen an Vertrauen gewonnen.
29
Das System hat zuerst von dem Vorgänger-Projekt (Mambo) nicht nur die besten
Eigenschaften (wie gute Stabilität), sondern auch die Nachteile der viel kritisierten Struktur übernommen. Dieses wurde mittlerweile in der aktuellen 1.5 Version3
deutlich verbessert, indem die komplette Code-Basis umgeschrieben wurde. So hat
sich Joomla zu einem recht flexiblen und leicht erweiterbaren System sich entwickelt, das alles bietet, was eine moderne Internetseite braucht(vgl. [Graf 2008b, S.
39 f.]).
3.3.3 Drupal
Drupal ist seit 2001 auf dem Markt und hat sich inzwischen auf einem sicheren
Platz neben den großen und erfolgreichen Systemen, wie TYPO3 und Joomla in
der CMS-Welt etabliert. Zwischen allen Drupal-Benutzern, tauchen immer wieder
lauter Prominente Unternehmen und Organisationen auf, wie Warner Brothers,
Amnesty International, Sony BMG, MTV (England), Harvard University und sogar
die Regierung der USA mit dem offiziellen Internetauftritt des Weißen Hauses (vgl.
[Franz 2008, S. 62]).
Drupal ist mehr als ein CMS. Drupal legt den Fokus auf den Aufbau einer Community und stellt eine Plattform für Zusammenarbeit zur Verfügung. So können
die Benutzer beispielsweise eigene Weblogs anlegen, sich in Diskussionsforen austauschen oder Artikel veröffentlichen (vgl. [Graf 2008a, S. 25 f.]).
3.3.4 eZ Publish
eZ Publish wird von der norwegischen Firma eZ Systems zusammen mit einer wachsenden Benutzer- und Entwickler-Community seit 1999 entwickelt. Das System ist
sowohl unter der freien GPL-Lizenz, als auch unter der eZ Publish Professional
Lizenz mit zusätzlicher professioneller Unterstützung erhältlich ([Rutke 2009]).
eZ Publish ist einerseits ein sofort einsetzbares CMS, andererseits liefert es eine Plattform für die Entwicklung von Projekten unterschiedlichster Art. Außer der Pflege von Internetseiten, gibt das System die Möglichkeit des Aufbaus
von Intranet, Extranet, Online-Shops, Medienportalen und wird damit zu der
3
Stand am 23.11.2009
30
Enterprise-Kategorie gezählt. Somit eignet sich das System zur Erstellung sowohl
von kleinen, individuellen Internetseiten, als auch von großen Business-Lösungen
([Rachbauer 2007, S. 5 f.]). Zu den namhaften Kunden zählen internationale Unternehmen und Einrichtungen wie das Elle Magazine, das Massachusetts Institute
of Technology, MySQL, NASA, National Geographic, T-Mobile, die Vereinten
Nationen und andere. ([Rutke 2009]).
eZ Publish unterstützt offene Standards und speichert die Inhalte vollständig im
XML-Format. Aus diesem Grund ist das System sehr flexibel und kann in bestehende IT-Infrastrukturen problemlos integriert werden.
3.3.5 Papaya CMS
Papaya CMS wurde speziell für den Unternehmenseinsatz vom Mittelstand bis
zum Konzern und Organisationen konzipiert. Das System erfüllt die Anforderungen großer Projekte mit wenig Zeitaufwand und ist seit 20004 erfolgreich im Einsatz. Die Entwicklung findet fast ausschließlich in Deutschland statt, und wird
hauptsächlich von deutschen Unternehmern und Organisationen wie der Arbeitsgemeinschaft Online Forschung (AGOF), der Deutsche Post AG/DHL, der AOKKrankenversicherung und vielen anderen eingesetzt ([pap 2009a]).
Die Besonderheit von Papaya CMS ist die vorhandene Mediendatenbank, welche
die hochwertige Auslieferung von Bildern, Illustrationen und Multimedia-Elementen
wie Flash-Objekten ermöglicht. Dies wird durch die Möglichkeit erreicht, die hochgeladenen Dateien mit Metainformationen zu versehen ([pap 2009b]).
Die Datensätze werden wie bei eZ Publish in einer baumartigen XML-Struktur
abgelegt und verstärken somit das System mit den bereits beschriebenen Vorteilen
der XML-Technologie (siehe Abschnitt 2.1.4). Zum Erstellen der Design-Vorlagen
(Templates) wird XSLT eingesetzt; so ist es nicht notwendig, sich in eine proprietäre
Scriptsprache einzuarbeiten.
4
wurde bis 2005 kommerziell vertrieben und ist seitdem unter der GNU General Public Licence
(GPL) quelloffen
Kapitel 4
Untersuchung
Nach der ersten groben Selektion sind nun noch drei Systeme basierend auf relationaler Datenhaltung und zwei Systeme auf Basis der baumartigen XML-Speicherung
verblieben. Für die Evaluation der Systeme wird in diesem Kapitel die Untersuchungsmethode mit dem Evaluationsverfahren vorgestellt und die hierfür benötigten
Werkzeuge und Ressourcen beschrieben. Zusätzlich wird hier der Kriterienkatalog
mit den daraus abgeleiteten Fragestellungen beschrieben.
4.1 Theoretische Grundlage
Bevor man die Evaluationselemente dieser Arbeit angeht, wird hier eine kurze Einführung in die theoretischen Grundlagen der klassischen Methoden und Modelle
gegeben, die für die Gestaltung des Kriterienkatalogs angewandt wurden.
Um die verbliebenen Systeme zu untersuchen und sie miteinander zu vergleichen,
muss die Qualität der einzelnen Produkte bewertet werden. Die Software-Qualität
an sich ist allerdings nichts Absolutes, das man messen kann; sie besteht aus vielen
Eigenschaften und Merkmalen einer Software, die zur Erfüllung gegebener Erfordernisse bestimmt werden (vgl. [Wallmüller 2001, S. 64], [Balzert 1998, S. 257]).
Die Operationalisierung der Software-Qualität wird in dem Qualitätsmodell durch
das Ableiten von Unterbegriffen ermöglicht. Dabei werden die Qualitätsmerkmale
in Teilmerkmale bzw. Kriterien zerlegt, die wiederum durch Qualitätsindikatoren
bzw. Metriken gemessen werden können (vgl. [Balzert 1998, S. 257 f.]). Der Aufbau
eines solchen Modells wird in Abbildung 4.1 gezeigt.
32
Abbildung 4.1: Aufbau von Qualitätsmodellen ([Wallmüller 2001, S. 257])
Es wurden in der Vergangenheit bereits unterschiedliche Qualitätsmodelle mit eigenen Qualitätsmerkmalen und -Kriterien entwickelt, wie zum Beispiel von Boehm, McCall, Wallmüller etc. Die zentralen Merkmale wurden 1992 standardisiert
und in ISO 9126 festgelegt. Folgende sechs sind die Hauptqualitätsmerkmale (vgl.
[Wallmüller 2001, S. 59 f.]):
• Funktionalität
• Zuverlässigkeit
• Benutzbarkeit
• Effizienz
• Änderbarkeit
• Übertragbarkeit
„Qualitätsmodelle sind eben nur Modelle. Um wirksam zu werden, müssen sie immer
den gegebenen Umständen in den einzelnen Projekten bzw. Entwicklungsprozessen
33
angepasst werden“ ([Wallmüller 2001, S. 71]). Hierfür existieren einige systematische
Vorgehensweisen zur Erstellung eigener Qualitätsmodelle (vgl. [Balzert 1998, S. 263
f.]). Der dafür bekannte Goal-Question-Metric (GQM)-Ansatz von Basili und Rombach wird auch für die Erstellung des Qualitätsmodells dieser Arbeit angewendet
(siehe Abschnitt 4.3). Die systematische Vorgehensweise bei der Erstellung eines
Qualitätsmodells nach dem GQM-Ansatz ist in folgenden sechs Schritten erfasst
(vgl. [Balzert 1998, S. 263 ff.]):
• Auswertungsziele (Qualitätsanforderungen) für alle Qualitätsmerkmale definieren.
• Alle Fragestellungen zur genaueren Definition der Ziele ableiten.
• Alle Metriken ableiten, die zur Beantwortung der Fragen informativ sein können.
• Mechanismus zur Datensammlung entwerfen, der eine möglichst genaue Messung der Metriken erlaubt.
• Die Messwerte bezüglich aller primitiven Maße validieren.
• Messergebnisse interpretieren, die zur Gesamtbewertung der Qualitätsziele
geführt haben.
Dieser Ansatz wird hier jedoch nur relativ oberflächlich angewendet; es wird (lediglich) die Hauptidee übernommen, wonach die Merkmale so zerlegt werden, dass
die Fragestellungen leicht zu erkennen sind, und dies eine Bewertung der Kriterien
anhand der gegebenen Antworten ermöglicht.
4.1.1 Qualitätssicht
Die Qualität der Software ist stark von subjektiven Anforderungen an das System
abhängig. Verschiedene Personengruppen (Stakeholder), die an dem Entwicklungsprozess teilnehmen oder mit dem System später umgehen müssen, haben unterschiedliche Qualitätsanforderungen, weshalb die Qualitätsmerkmale eines Produktes für verschiedene Personenkreise ungleich bedeutend sind. Aus diesem Grund ist
4.2 Evaluationsmethode
34
es sinnvoll, bei der Gestaltung von Qualitätsmodellen die Qualitätsansichten zu berücksichtigen. So wurden bereits in einem der ältesten Qualitätsmodelle von McCall
1977 drei Personengruppen unterschieden (vgl. [Balzert 1998, S. 262]):
• Benutzer
• Entwickler
• Anwender und Entwickler
Dißmann und Zurwehn ([Wallmüller 2001, S. 64 f.]) haben im Jahr 1986 ein anderes
Qualitätsmodell vorgeschlagen, indem sie Qualitätsmerkmale zu den vier verschiedenen Personenkreisen zuordneten:
• Benutzer
• Betreiber
• Designer
• Programmierer
„[...] durch eine Berücksichtigung der verschiedenen Sichten [wird] die Anwendbarkeit eines Qualitätsmodell erleichtert und vereinfacht [...]“ ([Wallmüller 2001, S.
69]).
Die in dieser Arbeit untersuchten Systeme werden aus der Entwicklersicht betrachtet, daher werden die Qualitätskriterien der beiden oben erwähnten Qualitätsmodelle ausschließlich aus der Sicht von Entwickler (McCall) und Programmierer (Dißmann und Zurwehn) berücksichtigt.
4.2 Evaluationsmethode
Für die Untersuchung der Systeme wurde die Methode des Expertenurteils (ExpertenReview) gewählt. „Expertenurteil ist eine der am häufigsten angewendeten Methoden in der Prüfung und Evaluation“ ([Hampe-Neteler 1994, S. 57]). Des Weiteren
ist die Methode für die Untersuchung der Systeme aus der Entwicklersicht gut geeignet, da sie auf spezifische, qualifizierte und kompetente Meinungen der Experten
aufbaut. Man benötigt für die Untersuchung keine große Anzahl an Entwicklern, die
4.3 Evaluationsverfahren
35
befragt werden oder beobachten müssten. Um ein sinnvolles Ergebnis zu erzielen,
reicht es aus nur einen Experten in die Bewertung einzubeziehen, der eine komplette Personengruppe durch sein fachliches, exklusives Wissen und seine Erfahrung
repräsentiert(vgl. [Mayer 2006, S. 37]). Bei der Befragung des Experten werden
weniger seine Emotionen, Motive oder Einstellungen betrachtet, sondern vielmehr
Wert auf seine kognitive Beurteilung und sein Wissen um den interessierenden
Sachverhalt gelegt (vgl. [Aghamanoukjan 2007, S. 428]).
Die Expertenurteile können frei, strukturiert und methodengeleitet dargestellt werden (vgl. [Hampe-Neteler 1994, S. 100 f.]). In dieser Arbeit wurde sich für ein strukturiertes Experten-Review entschieden. Dabei bekommt der Experte detaillierte Angaben zu den Kriterien und den Vorgehensweisen, was im Gegensatz zu einem freien
Urteil mehr Nachvollziehbarkeit der Ergebnisse verspricht. Die Kriterien entstehen
dabei hauptsächlich aus Standards (wie ISO 9126) und Richtlinien.
4.2.1 Experte
Als Experte bezeichnet man eine Person, die ein spezielles Wissen in einem bestimmten Gebiet hat und innerhalb dieses Gebietes Problemlösungen anbieten kann.
Im Vergleich zu anderen mit dem gleichen Problem befassten Personen (NichtExperten), verfügt der Experte über einen exklusiven Wissensstand; sein Wissen
ist nicht für jeden zugänglich ([Bogner 2005, S. 115 f.]).
Für die Untersuchung der Systeme wird der Autor dieser Arbeit als Experte auftreten. Die mehrjährige Erfahrung im Gebiet von CMS-Entwicklung und -Anwendung
und längere Beschäftigung im Bereich von Software-Engineering und -Evaluation
befähigen ihn für diese Aufgabe, die Systeme anhand der gestellten Kriterien und
daraus abgeleiteter Fragestellungen zu beurteilen.
4.3 Evaluationsverfahren
Das Evaluationsmodell ist auf der Basis eines GQM-Ansatzes aufgebaut. Dazu werden im ersten Schritt Qualitätseigenschaften (Hauptmerkmale) erstellt. Diese Eigenschaften werden mit auf dem Standard (ISO 9126) erfassten Qualitätsmerkmalen
4.4 Kriterienkatalog
36
und den wichtigen Merkmalen eines CMS unter Berücksichtigung der EntwicklerQualitätssicht zusammengestellt. Die Hauptmerkmale werden später in Teilmerkmale (Kriterien) verfeinert. Wenn die Auswertungsziele definiert und die Kriterien
detailliert formuliert sind, können die Fragen zur Abdeckung der Kriterien abgeleitet werden. Die Fragen werden in einem Fragenkatalog für die spätere Auswertung
vom Experten zusammengefasst.
Um die Antworten des Experten zu bewerten wird ein sogenanntes Polaritätsprofil
erstellt. Dabei wird zur Beurteilung der Fragestellungen eine bipolare Einstufungsskala angeboten, deren Endpunkte von adjektivischen Gegensatzpaaren (wie z.B.
gut/schlecht, stark/schwach, klein/groß etc.) gebildet werden. Die in dieser Arbeit
verwendete Bewertungsskala bietet folgende fünf unterschiedliche Gewichtungsstufen zur Auswahl: ‚−−‘, ‚−‘, ‚0‘, ‚+‘, ‚++‘. Der Experte hat die Möglichkeit, seinen
Eindruck zu den gestellten Fragen positiv (mit ‚+‘ oder ‚++‘) bzw. negativ (mit
‚−−‘, ‚−‘) zu äußern. Die Unentschlossenheit wird mit neutralen Wert (‚0‘) bewertet. Zusätzlich ist eine Antwort wie ‚k.A.‘ (für keine Angabe) im Falle der Ablehnung
der Frage oder dazu fehlendem Wissen erlaubt. Die mit ‚k.A.‘ bewerteten Fragen
sind für weitere Auswertungen irrelevant und können daher gestrichen werden.
Die eingetragenen Gewichtungen werden im Nachhinein miteinander verbunden,
so dass sich hieraus ein graphisches Profil bildet. Somit bekommt man eine überschaubare Abbildung der Experten-Bewertungen, die sich nachher leicht auswerten
lassen.
Solche Profile werden zuerst zu jedem ausgesuchten CMS erstellt, um zu jedem
System eine einzelne Aussage zu treffen. Danach werden die Systeme gruppenweise
(baumartige XML-Datenhaltung vs. relationale Persistenz) betrachtet und ausgewertet. Hierbei wird das arithmetische Mittel der jeweiligen Bewertungen berechnet.
Die Software-Qualität lässt sich gemäß ISO 9126 in sechs Merkmale unterteilen, auf
welche weitere Untergliederungen folgen (siehe Abbildung 4.2). Allerdings sind für
diese Arbeit nur die Merkmale relevant, die für die Entwickler wichtig sind.
37
Abbildung 4.2: Merkmale der ISO 9126 ([Balzert 1998, S. 259 f.])
Wie bereits erwähnt, berücksichtigt McCall in seinem Qualitätsmodell exakt die
gleiche Gruppe und unterscheidet drei Qualitätsmerkmale, die lediglich für Entwickler relevant sind. Diese Merkmale sind zusammen mit den abgeleiteten Kriterien in
der Graphik 4.3 abgebildet.
Das Modell von McCall wurde zwar als Basis für viele unternehmensspezifische
Modelle verwendet, ist allerdings ziemlich alt, und neue Erkenntnisse sind in diesem
Modell bisher nicht berücksichtigt. Daher wird noch ein anderes bekanntes Modell
von Dißmann und Zurwehn in Augenschein genommen. Hier sind die Merkmale aus
38
Abbildung 4.3: Qualitätsmodell von McCall: relevante Eigenschaften für Entwickler
der Sicht des Programmierers von Bedeutung (siehe Abbildung 4.4).
Zusätzlich zu den Qualitätsmerkmalen aus den klassischen Qualitätsmodellen, die
für alle Software-Produkte allgemein relevant sind, ist es sinnvoll, die zentralen
Kriterien für die Produkte aus der CMS-Welt zu berücksichtigen. Dafür werden
die Kriterien genommen, die bei dem CMS-Award (siehe Abschnitt 3.2.2) für die
Ermittlung der besten CMS berücksichtigt werden: Performanz, Benutzbarkeit, Erreichbarkeit, Skalierbarkeit, Installierbarkeit, Anpassbarkeit und Sicherheit.
Um die Kriterien für die Untersuchung der gewählten Systeme dieser Arbeit zu ermitteln, werden schließlich alle erwähnten Qualitätsmodelle kombiniert und als Gesamtbild betrachtet. Die Tabelle 4.1 listet grundsätzlich die standardisierten Qualitätsmerkmale mit den abgeleiteten Teilmerkmalen aus ISO 9126 ([Balzert 1998, S.
259 f.]) auf. Die wenigen Qualitätsmerkmale bzw. -Kriterien, die in dem Standard
nicht vorkommen, jedoch in den Qualitätsmodellen, die verschiedene Sichten berücksichtigen (McCall, Dißman und Zurwehn), enthalten sind, werden zu der Liste
hinzugefügt. Die Überschneidungen der Merkmale sind durch die Kreuzmarkierungen deutlich dargestellt. Die Kriterien, die sich stark Überschneiden und häufig als
Synonyme bezeichnet werden, sind hier in einem Punkt erfasst.
39
Abbildung 4.4: Qualitätsmodell von Dißman und Zurwehn: relevante Eigenschaften für Programmierer ([Wallmüller 2001, S. 68])
Um den Kriterienkatalog für die zu untersuchenden Systeme festzulegen, werden
nun die Hauptmerkmale der ISO-Norm mit den dazu gehörigen Kriterien übernommen, die in den drei anderen Modellen vorkommen. Dafür werden die Qualitätseigenschaften zusammen mit den abgeleiteten Kriterien in der Gesamt-Tabelle
(4.1) als einzelne Blöcke betrachtet. Wenn so ein Block mindestens ein Kriterium zu jedem Modell enthält, wird der ganze Kriterien-Block in den Fragekatalog
übernommen. Dabei werden Modelle, die Entwicklersicht berücksichtigen, zusammengefasst betrachtet. So ergibt sich, dass die CMS in dieser Arbeit unter folgenden
drei Qualitätseigenschaften untersucht werden: Benutzbarkeit, Änderbarkeit, Übertragbarkeit.
Bevor der endgültige Kriterienkatalog dieser Arbeit zusammenstellt ist, wird an
dieser Stelle eine Ausnahme bei dem Untermerkmal Bedienbarkeit gemacht. Be-
40
dienbarkeit bezieht sich auf den Aufwand zur Bedienung einer Software; eine Software ist gut bedienbar, wenn die Bedienung intuitiv und schnell stattfinden kann
(vgl. [Balzert 1998, S. 259]). Dieses ist eher für einen Benutzer relevant. Außerdem
gehört dazu die Auswertung der Bedienungsanleitungen (User Manuals), die aber
laut Prof. Dr. A. Hein in seinem Vortrag zur Erstellung und Dokumentation benutzerfreundlicher und fehlertoleranter Software lediglich wichtig für Anwender sind,
die keine technische Sicht auf die Software haben ([Hein 2006]). Also ist die Bedienbarkeit für die Entwickler-Sicht irrelevant und wird nicht in den Kriterienkatalog
übernommen.
Nachdem alle passenden Kriterien aus der Ergebnis-Tabelle selektiert wurden, hat
sich der folgende Kriterienkatalog ergeben:
• Benutzbarkeit
– Verständlichkeit
– Erlernbarkeit
• Änderbarkeit
– Analysierbarkeit
– Modifizierbarkeit
– Stabilität
– Prüfbarkeit
• Übertragbarkeit
– Anpassbarkeit
– Installierbarkeit
– Konformität
– Austauschbarkeit
Die einzelne Qualitätsmerkmale und daraus abgeleitete Unterkriterien werden bei
der Formulierung der dazu passenden Fragestellungen in dem nächsten Kapitel (4.5)
erklärt.
41
Softwaremerkmale bzw. -Kriterien
ISO
9126
Funktionalität
Richtigkeit
Angemessenheit
Interoperabilität
Ordnungsmäßigkeit
Sicherheit
Zuverlässigkeit
Reife
Fehlertoleranz
Wiederherstellbarkeit
Benutzbarkeit
Verständlichkeit
Erlernbarkeit
Bedienbarkeit
Effizienz (Performanz)
Zeitverhalten
Verbrauchsverhalten
Änderbarkeit (Wartbarkeit)
Analysierbarkeit
Modifizierbarkeit (Erweiterbarkeit)
Stabilität
Prüfbarkeit (Testbarkeit)
Skalierbarkeit
Strukturiertheit
Übertragbarkeit (Portabilität)
Anpassbarkeit
Installierbarkeit
Konformität
Austauschbarkeit
Erreichbarkeit
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
CMSAward
McCall
Dißmann
und
Zurwehn
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tabelle 4.1: Qualitätsmerkmale bzw. -Kriterien von McCall, Dißmann und Zurwehn, ISO 9126 und CMS-Award
4.5 Fragenkatalog
42
4.5 Fragenkatalog
In diesem Schritt werden nun die Fragen zu jedem Qualitätskriterium in Bezug
auf die ausgesuchten Systeme formuliert. Für die Nachvollziehbarkeit der Fragestellungen werden verschiedene Hilfsmittel verwendet. Um die Merkmale kurz aufzuklären werden die Definitionen aus der ISO 9126 angewendet ([Balzert 1998, S.
259 f.]) und zusätzlich eine detaillierte Beschreibung der Merkmale aus dem Lernmaterial zu Softwaretechnik II von Prof. Dr. Udo Kelter von der Universität Siegen ([Kelter 2007]) angeschaut. Außerdem werden die im iX-Magazin zur ECMSEvaluation zusammengestellten Fragen ([Popper 2008, S. 78 f.]) untersucht und von
dort die relevanten Fragen übernommen. Die endgültige Entscheidung der FragenFormulierung wurde dem befragten Experten überlassen. Alle Fragestellungen sind
entwicklerorientiert.
4.5.1 Fragen zu Benutzbarkeit
Benutzbarkeit bezieht sich auf den Aufwand, den eine bestimmte Benutzergruppe
für das individuelle Nutzungsverhalten in einem System benötigt.
Für die Entwicklergruppe ist die Benutzbarkeit der für sie relevanten SoftwareBestandteile des Systems von Bedeutung, wie Quellcode, Installation, Konfigurationsmodul, Software-Architektur, Programmierschnittstellen, Datenbankebene etc.
(vgl. [Bennicke 2008, S. 560 ff.]).
4.5.1.1 Verständlichkeit
Verständlichkeit zeigt, wie viel Aufwand wird benötigt, um das Konzept des Systems zu verstehen. Nach Dißmann und Zurwehn zählen zur Verständlichkeit aus
Sicht der Programmierers folgende Kriterien: Dokumentierbarkeit, Selbsterklärbarkeit, Durchschaubarkeit, Einfachheit (siehe Abbildung 4.4). Unter diesem Aspekt
kommen die folgenden Fragestellungen zu Stande.
• Wie ausführlich ist der Quellcode dokumentiert?
• Wie gut ist die Software abstrahiert (objektorientiert implementiert)?
4.5 Fragenkatalog
43
• Wie lesbar ist der Quellcode?
• Wie sind die Variablen in dem Quellcode benannt?
• Wie ausreichend sind die Quellcode-Kommentare?
• Wie umfangreich ist die Software graphisch dokumentiert (z.B. durch UMLDiagramme)?
• Wie gut ist die Programmierschnittstelle zum Systemkern (Core API) beschrieben?
• Wie ausführlich ist die Schnittstelle zur Datenbank dokumentiert?
• Wie viele Erweiterungen haben eine Dokumentation?
• Wie gut sind die Erweiterungen dokumentiert?
4.5.1.2 Erlernbarkeit
Erlernbarkeit zeigt, wie schnell sich die notwendigen Ein- und Ausgaben der Anwendung erlernen lassen.
• Wie schnell ist die System-Architektur erlernbar?
• Wie hilfreich sind die Fehlermeldungen?
• Wie viele Entwicklerhandbücher gibt es?
• Wie groß ist die Entwickler-Community zu dem System?
• Wie viele entwicklerrelevante Tutorials gibt es?
• Wie hoch ist die Dichte der Dienstleister?
4.5.2 Fragen zu Änderbarkeit
Als Änderbarkeit bezeichnet man den Aufwand, der für die Durchführung von zu
erwartenden Änderungen, wie Korrekturen, Verbesserungen oder Anpassungen notwendig ist.
4.5 Fragenkatalog
44
4.5.2.1 Analysierbarkeit
Analysierbarkeit ist der Aufwand, den ein Benutzer betreiben muss, um Fehlerursachen (Mängel) zu analysieren bzw. zu lokalisieren oder von Änderungen betroffene
Stellen zu bestimmen.
• Wie gut lässt sich das Programm auf Fehler durch ein Fehlerprogramm (Debugger) untersuchen?
• Wie komfortabel lassen sich Systemausgaben (Protokoll-Dateien) steuern?
• Wie verständlich sind die Systemausgaben (in einer Protokoll-Datei)?
4.5.2.2 Modifizierbarkeit
Als Modifizierbarkeit bezeichnet man den Aufwand, der zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung an Umgebungsänderungen nötig
ist.
• Wie gut kann das System über Module erweitert oder ausgebaut werden?
• Wie einfach lassen sich die Module anderer Entwickler installieren?
• Wie schwer ist die Struktur für eine Erweiterung anzulegen?
• Wie viele System-Komponenten lassen sich über die Erweiterungen ändern
bzw. ausbauen?
4.5.2.3 Stabilität
Stabilität besagt, wie wahrscheinlich das Auftreten von unerwarteten Nebenwirkungen bei den durchgeführten Änderungen ist.
• Wie oft treten unerwartete Nebenwirkungen nach der Installation einer neuen
Erweiterung auf?
• Wie gut wird die Software durch die Community in Hinblick auf Fehlerkorrektur und Sicherheit gewartet (z.B. Bug Fixes, Security Updates)?
• Wie groß sind die Auswirkungen kleiner Fehler?
4.5 Fragenkatalog
45
• Wie reagiert das System auf Überlastungen bzw. Fehlermeldungen (zahlreiche,
gleichzeitige Fehler)?
4.5.2.4 Prüfbarkeit
Prüfbarkeit ist der Aufwand, der für die Prüfung der geänderten Software notwendig
ist.
• Wie viele Möglichkeiten gibt es, einzelne System-Module zu testen?
• Wie einfach ist die Prüfung einer Komponente unabhängig vom System möglich?
4.5.3 Fragen zu Übertragbarkeit
Als Übertragbarkeit bezeichnet man den Aufwand, der zum Übertragen einer Software in eine andere Umgebung benötigt wird. Die neue Umgebung können Hardware, Betriebssystem, DBMS und ähnliche Basissysteme oder Bibliotheken sein.
4.5.3.1 Anpassbarkeit
Anpassbarkeit betrifft die Änderungen, die erforderlich sind, eine Software in einer
neuen Umgebung zu konfigurieren.
• Auf wie vielen verschiedenen Plattformen und Betriebssystemen kann das
System laufen?
• Auf wie vielen unterschiedlichen Webservern kann das System laufen?
• Wie viele verschiedene Möglichkeiten (verschiedene DBMS, Dateisystem) stehen für die Datenhaltung zur Verfügung?
• In wie vielen Webbrowsern läuft das System-Backend?
4.5 Fragenkatalog
46
4.5.3.2 Installierbarkeit
Mit der Installierbarkeit wird der Aufwand zum Installieren der Software in einer
festgelegten Umgebung bestimmt.
• Wie komfortabel sind die Installationsroutinen (z.B. DB-Einrichtung, DateisystemKonfiguration)?
• Wie viele zusätzliche (System-)Programme werden vorausgesetzt, um das System vollständig nutzen zu können?
• Wie viele abhängige (System-)Programme müssen unabhängig von der Installation eingestellt werden?
• Wie gut lassen sich die nötigen Parameter der gegebenen Systemumgebung
über das Installationswerkzeug einstellen?
• Wie gut wird die Verfügbarkeit aller für die Programmnutzung notwendigen
Daten und Datenbereiche (Speicherbedarf) während der Installation überprüft?
4.5.3.3 Konformität
Mit der Konformität wird der Grad bezeichnet, in dem die Software die Standards
und Vereinbarungen zur Übertragbarkeit erfüllt.
• Wie ähnlich ist die Konfigurationssprache einer offenen Standardsprache?
• Wie gut wird XML unterstützt?
• Wie gut werden Standards (z.B. SQL92, XML) bei der Datenhaltung eingehalten?
4.5.3.4 Austauschbarkeit
Als Austauschbarkeit wird der Aufwand bezeichnet, der benötigt wird, um die Software anstelle eines anderen spezifizierten Systems in der Umgebung zu verwenden.
• Wie gut lassen sich die Daten exportieren bzw. migrieren?
4.5 Fragenkatalog
47
• Wie gut können spezifische Module in einem neuen System weiterverwendet
werden?
Kapitel 5
Auswertung
In diesem Kapitel werden die Polaritätsprofile zu dem Expertenurteil jedes Systems erstellt und ausgewertet. Es kommen jeweils drei Profile zu jedem System
zu Stande. Damit lassen sich im Folgenden die Aussagen zu den gewählten Qualitätseigenschaften (Benutzbarkeit, Änderbarkeit und Übertragbarkeit) der Systeme
leicht treffen. Zusätzlich wird ein allgemeines Polaritätsprofil zu den beiden Gruppen der Systeme erstellt, die sich nach den in dieser Arbeit gegenüber gestellten
Speicherungsmethoden unterscheiden (baumartige XML- und relationale Speicherung). Durch die Auswertung des allgemeinen Profils werden die Systemgruppen
bezüglich der drei Qualitätseigenschaften miteinander verglichen.
Die Fragestellungen werden auf die Profile nicht übertragen; sie befinden sich im
Anhang (A). Die in dem Anhang nummerierten Fragen stimmen mit der Nummerierung der Antworten der möglichen Gegensatzpaare in dem erstellten Profil
überein. Durch die Nummerierung wird bei der Auswertung der Ergebnisse häufig
auf die Fragen zurückgegriffen, um eine präzise Aussage zu erzielen. Jedes Profil
zu den einzelnen Qualitätseigenschaften ist zusätzlich in einzelne Untermerkmale
aufgeteilt.
Die Frage mit der Nummer 27 zu der Änderbarkeit der Systeme wurde in dem
Polaritätsprofil absichtlich ausgelassen, da sie von dem Experten bei vier von fünf
Systemen als ‚k.A.‘ markiert wurde. Das bedeutet, dass ihm entweder das Wissen
dazu fehlte oder die Frage zu diesen vier Systemen irrelevant war.
5.1 Systeme auf relationaler Basis
49
Zuerst werden die Ergebnisse der drei Systeme mit der relationalen Datenhaltung
ausgewertet. Dazu werden die erstellten Polaritätsprofile zu den drei festgelegten
Qualitätseigenschaften nacheinander ausgewertet. Jedes Profil enthält drei verschiedene Kurven für je ein System, die das Urteil des Experten graphisch darstellen.
Somit sind die Stärken und Schwächen einzelner Systeme gut erkennbar und die
Systeme dadurch leicht miteinander vergleichbar.
5.1.1 Benutzbarkeit
Bezüglich der Benutzbarkeit der für Entwickler wichtigen Software-Bestandteile (interne Dokumentation, API- und Architektur-Beschreibung) haben alle drei Systeme
recht positive Ergebnisse gezeigt (siehe Abbildung 5.1). Die einander stark überschneidenden Kurven besitzen teilweise eine große Schwankungsbreite und erreichen zwar hin und wieder den negativen Bereich, bleiben aber überwiegend in dem
positiven Pol.
Drupal hat besonders gute Ergebnisse erzielt mit dem einzig festgestellten Nachteil, dass sehr wenig graphische Beschreibung der Softwarearchitektur vorhanden ist
und damit die Verständlichkeit der Systemstruktur für einen Entwickler erschwert
wird.
Des weiteren bestätigen die Ergebnisse in der Beschreibung der Systeme den bereits angedeuteten Nachteil von TYPO3 (siehe Abschnitt 3.3.1), dass das System
für Entwickler wegen der komplexen Architektur schwer zu erlernen ist. Gleichzeitig
wiederum wird die Erlernbarkeit des Systems durch die Vielzahl an technischen Büchern, Anleitungen (Tutorials) und einer großen Entwickler-Community erhöht. In
Bezug auf Verständlichkeit ist TYPO3 einerseits mit der Knappheit an QuelltextKommentaren leicht negativ aufgefallen, anderseits zeigte es jedoch Stärken in der
besonders umfangreichen und ausführlichen Dokumentation und einer hervorragenden API-Beschreibung.
In Vergleich zu Drupal und TYPO3 ist die Bewertung von Joomla in puncto Benutzbarkeit etwas schlechter ausgefallen. Das Polaritätsprofil zeigt die großen Nachteile
50
in der Dokumentation der Datenbankschnittstelle und der Erweiterungen. Außerdem werden die Entwickler durch technische Handbücher und Tutorials nur mangelhaft unterstützt. Positiv aufgefallen ist Joomla aber mit dem am meisten verständlichen Quellcode, der gut abstrahiert ist, sehr ausführliche Kommentare enthält und
deren Variablen verständlich benannt sind.
Abbildung 5.1: Polaritätsprofil: relational basierte Systeme bezüglich der Benutzbarkeit
51
52
5.1.2 Änderbarkeit
Die Abbildung 5.2 stellt das Polaritätsprofil zur Änderbarkeit der Systeme auf relationaler Basis dar. Die graphische Darstellung besteht aus stark gekrümmten Linien,
die eine eindeutige Aussage zu den Systemen erschwert. Klar zu erkennen ist aber,
dass Drupal im Vergleich zu den anderen beiden Systemen einen deutlichen Vorteil in Bezug auf Analysierbarkeit und Prüfbarkeit hat. TYPO3 und Joomla fallen
in den anderen beiden Untermerkmalen ähnlich schwach auf. Joomla überzeugt in
puncto Modifizierbarkeit, indem es sich am einfachsten durch die externen Module
erweitern lässt und hierfür keine komplexe Struktur benötigt. Bezüglich der Stabilität hat Joomla zwar keine negativen Seiten gezeigt, bleibt aber zusammen mit
Drupal im neutralen Bereich auf Grund der nur unwesentlichen Vorteile. TYPO3 dagegen hat einerseits große Schwächen, was die Auswirkungen kleiner Fehler auf das
gesamte System angeht, wird allerdings am besten von der Entwickler-Community
bei der Fehlerkorrektur und Sicherheit betreut, was die Stabilität des Systems nach
oben treibt.
Abbildung 5.2: Polaritätsprofil: relational basierte Systeme bezüglich der Änderbarkeit
53
54
5.1.3 Übertragbarkeit
Das in der Abbildung 5.3 abgebildete Polaritätsprofil zeigt anschaulich die Übertragbarkeit der relational-basierten Systeme. Die Profile zu Joomla und Drupal
stellen eine überwiegend in dem positiven Pol liegende Linie dar, die relativ gerade
ist und kaum auffällige Kurven enthält. Dieses ist ein deutliches Indiz dafür, dass
die beiden Systeme anhand aller vier Untermerkmale gut bewertet wurden und mit
wenig Aufwand übertragbar sind. Die graphische Ergebnis-Kurve zu TYPO3 ist dagegen relativ gebogen und zeigt unterschiedliche Stärken und Schwächen bezüglich
verschiedener Untermerkmale. So ist deutlich erkennbar, dass das System sich am
einfachsten in einer neuen Umgebung anpassen lässt mit der besonderen Stärke, etliche DBMS zu unterstützen. Außerdem wurden klare Vorteile an TYPO3 in puncto
Installierbarkeit festgestellt: die nötigen System-Parameter lassen sich besonders gut
durch das Installationswerkzeug einstellen und die notwendigen Daten und Datenbereiche werden hervorragend auf die Verfügbarkeit überprüft. Allerdings erschwert
die große Menge an zusätzlichen, vorausgesetzten Programmen die Installation und
zählt hier zum Nachteil des Systems. Zusätzlich fällt TYPO3 wegen seiner schwer
erlernbaren, nicht konformen Konfigurationssprache negativ auf.
Bezüglich der Austauschbarkeit wurden alle drei Systeme relativ neutral bewertet.
Abbildung 5.3: Polaritätsprofil: relational basierte Systeme bezüglich der Übertragbarkeit
55
5.2 XML-basierte Systeme
56
Nun werden die Systeme mit der XML-basierten Speicherung bezüglich der drei
Software-Qualitätseigenschaften ausgewertet und miteinander verglichen.
5.2.1 Benutzbarkeit
Das Polaritätsprofil zu der Benutzbarkeit der Systeme ist in der Abbildung 5.4
dargestellt. Die klare Überlegenheit von eZ Publish ist in der Abbildung deutlich
zu erkennen. Das System hat keine großen Schwächen bezüglich der Benutzbarkeit gezeigt und hat sich aus Entwicklersicht als sehr verständliches und relativ
gut erlernbares System erwiesen. Papaya CMS ist dagegen durch häufige Kurven
im negativen Bereich aufgefallen, insbesondere in der API-Beschreibung, der Dokumentation der Erweiterungen und der Entwickler-Unterstützung durch Bücher,
Tutorials und eine Community. Papaya CMS konnte lediglich in puncto einfache
und gut strukturierte System-Architektur, die wesentlich schneller erlernbar ist als
die von eZ Publish, positiv hervorstechen.
Abbildung 5.4: Polaritätsprofil: XML-basierte Systeme bezüglich der Benutzbarkeit
57
58
5.2.2 Änderbarkeit
Papaya CMS wurde bezüglich der Benutzbarkeit ziemlich schlecht bewertet, ist aber
unter dem Kriterium Änderbarkeit, wie die Abbildung 5.5 zeigt, ein klarer Favorit.
Wie man sehen kann, hat das System in fast allen zwölf Punkten die maximale
Bewertung von ‚++‘ bekommen und hat sich dadurch als sehr flexibles System erwiesen. eZ Publish zeigt hingegen kleine Nachteile in Hinblick auf Analysierbarkeit
und Modifizierbarkeit, wird aber besser durch die Community bezüglich der Fehlerkorrektur und Sicherheit unterstützt und weist sich dadurch als etwas stabileres
System aus. Die besonderen Schwächen von eZ Publish sind in der Prüfbarkeit des
Systems zu finden.
Abbildung 5.5: Polaritätsprofil: XML-basierte Systeme bezüglich der Änderbarkeit
59
60
Die Abbildung 5.6 zeigt das Polaritätsprofil zur Übertragbarkeit der XML-basierten
Systeme. In dem Profil ist ein besonders großer Unterschied der beiden Systeme
bezüglich der Installierbarkeit zu beobachten; eZ Publish erweist sich als gut installierbares System, Papaya CMS ist dagegen eher schwach bis sehr schwach. Bezüglich
der anderen Untermerkmale wurden die beiden Systeme relativ gleich positiv bewertet. Papaya CMS konnte in der Anpassbarkeit und Konformität durch minimal
bessere Ergebnisse überzeugen, eZ Publish bekommt hingegen eine etwas bessere
Bewertung in Hinblick auf Austauschbarkeit.
Abbildung 5.6: Polaritätsprofil: XML-basierte Systeme bezüglich der Übertragbarkeit
61
62
Nachdem die Polaritätsprofile zu den einzelnen Systemen auf relationaler und XMLBasis erstellt und ausgewertet wurden, werden in diesem Abschnitt die Auswertungen der Systeme gruppenweise vorgenommen, um das eigentliche Ziel dieser Arbeit
zu verfolgen und die Systemgruppen miteinander zu vergleichen. Für den Vergleich
der Systeme wurden neue Polaritätsprofile zu den beiden Gruppen erstellt. Dafür
wurden aus den Experten-Bewertungen zu den einzelnen Systemen einer Gruppe
die Durchschnittswerte errechnet und ins neue Profil übertragen. Somit entstanden
zwei neue graphische Darstellungen zu den drei festgelegten Qualitätseigenschaften,
die im Folgendem ausgewertet werden.
5.3.1 Benutzbarkeit
Die Abbildung 5.7 stellt das Polaritätsprofil der beiden Systemgruppen in puncto
Benutzbarkeit dar. Das Profil zeigt, dass die beiden Systemgruppen keine großen
Differenzen haben und insofern gut benutzbar sind. Die beiden Kurven bestehen nur
aus unwesentlichen Schwankungen und befinden sich überwiegend in dem positiven
Pol. Die Unterschiede werden in Bezug auf das Untermerkmal Erlernbarkeit etwas
größer. Die Architektur der XML-basierten Systeme ist etwas schneller erlernbar
und die System-Fehlermeldungen sind etwas hilfreicher als bei den gegenübergestellten Systemen. Die Systeme auf Basis einer rein relationalen Datenbank zeigen
hingegen ihre Stärken in der Entwickler-Unterstützung durch Bücher, Community
und Tutorials.
Abbildung 5.7: Polaritätsprofil: relational und XML-basierte Systeme bezüglich
der Benutzbarkeit
63
64
5.3.2 Änderbarkeit
Das Polaritätsprofil zur Änderbarkeit der beiden Systemgruppen wird in der Abbildung 5.8 angezeigt. In dem Profil ist deutlich erkennbar, dass sich die XML-basierten
Systeme mit wesentlich geringerem Aufwand ändern lassen als die gegenüber gestellten Systeme. Die graphische Darstellung der Bewertungen liegt komplett in
dem positiven Pol und zeigt damit, dass die Systeme in allen vier Untermerkmalen hervorragend abgeschnitten haben. Die Kurve der relational-basierten Systeme
schwankt dagegen häufiger zu dem negativen Pol und zeigt besonders in puncto
Stabilität und Prüfbarkeit gewisse Schwächen. Die einzige Stelle, an der die Systeme auf relationaler Basis unwesentliche Vorteile zeigen, bezieht sich auf die bessere
Erweiterbarkeit, die durch die externen Module geleistet wird.
Abbildung 5.8: Polaritätsprofil: relationale und XML-basierte Systeme bezüglich
der Änderbarkeit
65
66
Das in der Abbildung 5.9 dargestellte Polaritätsprofil lässt keine eindeutige Aussage
zu der Übertragbarkeit im Ganzen zu. Die beiden Kurven korrelieren stark miteinander, bleiben aber dabei weitgehend in dem positiven Bereich. Die Unterschiede
der beiden Systemgruppen werden erst bei der Betrachtung der Kurven bezüglich
der einzelnen Untermerkmale deutlich. In Bezug auf Installierbarkeit haben die
Systeme mit der rein relationalen Datenbank wesentliche Vorteile und lassen sich
durch ihre komfortablen Installationsroutinen schneller und bequemer installieren.
Die XML-basierten Systeme hingegen lassen einerseits ihre Programmteile deutlich
besser durch andere austauschen und sichern andererseits die Übertragung der Systeme in eine neue Umgebung durch den breiteren Einsatz der offenen Standards.
Bezüglich der Anpassbarkeit zeigen die beiden Systemgruppen geringe Unterschiede
mit dem minimalen Vorteil bei den XML-basierten Systemen.
Abbildung 5.9: Polaritätsprofil: relationale und XML-basierte Systeme bezüglich
der Übertragbarkeit
67
5.4 Schlussfolgerung
68
5.4 Schlussfolgerung
Abschließend zu dem Kapitel werden in diesem Abschnitt die Ergebnisse der Untersuchung zusammengefasst.
Die Auswertungen der Ergebnisse haben ergeben, dass es keinen klaren Favoriten in
der Gruppe der Systeme auf relationaler Basis gibt; es wurden zu jedem Produkt jegliche Vorteile und Nachteile bezüglich verschiedener Qualitätskriterien festgestellt.
Bei den untersuchten XML-basierten Systemen lassen sich die Unterschiede deutlicher feststellen: eZ Publish ist definitiv besser benutzbar und übertragbar, Papaya
CMS hingegen zeigt sich in Hinblick auf Änderbarkeit überwiegend an vorderer
Stelle.
Im Vergleich der Systeme der einzelnen Gruppen konnten lediglich deutliche Unterschiede bezüglich der Änderbarkeit festgestellt werden. Die Systeme auf XMLBasis benötigen wesentlich weniger Aufwand, um geändert zu werden. Bezüglich
der Übertragbarkeit konnten die XML-basierten Systeme durch die Unterstützung
einer einheitlichen, offenen und standardisierten Technologie überzeugen. Allerdings
wurden wesentliche Schwächen in den Installationsroutinen der Systeme festgestellt,
die die gesamte Bewertung negativ geprägt haben. Die relational-basierten Systeme
haben keine erheblich schlechteren Ergebnisse gezeigt und deckten sogar die Lücke
der Systeme auf XML-Basis bezüglich Installierbarkeit ab. In Hinblick auf Benutzbarkeit sind die Systeme beider Gruppen gut ausgereift und bieten den Entwicklern
eine relativ einfache Benutzung der für sie relevanten Software-Bestandteile.
Kapitel 6
Zusammenfassung und Ausblick
Die Angebotsfülle von OS-CMS ist überwältigend, wobei die Systeme mit verschiedensten Techniken umgesetzt sind. Die Unterschiede liegen hier bereits auf der Ebene der Datenhaltung. Auf LAMP-Technologie zugeschnittene Produkte sind klare
Favoriten auf dem Markt. Diese Systeme sind meistens mit der Skriptsprache PHP
implementiert und verwenden eine relationale Datenbank (überwiegend MySQL)
zur Speicherung der Inhaltsdaten. Eine ziemlich kleine und unbekannte Gruppe von
CMS setzt bei der Datenhaltung XML-Technologie ein. Die Nutzung dieser einheitlichen, offenen und standardisierten Technologie ermöglicht eine effektive Realisierung diverser Aufgaben, die ein modernes CMS heutzutage erfüllen können muss.
Trotz allen XML-Vorteilen konnten sich nur wenige Systeme dieser Art durchsetzen.
Daher war das Ziel dieser Diplomarbeit, die relational- und XML-basierten Systemgruppen einer software-ergonomischen Evaluation zu unterziehen, um die Stärken
bzw. Schwächen und damit auch die Ursprünge für den Erfolg der einen Gruppe
und die Probleme bei der Durchsetzung der anderen festzustellen.
Im ersten Teil der Arbeit wurden verschiedene Klassen der CMS mit ihren unterschiedlichen Ausprägungen und Techniken kurz vorgestellt. Dabei lag die Betonung auf der verwendeten Datenhaltung. Außerdem wurden die Vorteile der XMLTechnologie in dem Datenhaltungs-Einsatz von einem CMS beschrieben.
Im folgenden Teil fand eine Sekundäranalyse statt, mit der die Systeme für die
weitere Untersuchung ausgewählt werden konnten. Die Systeme wurden nach den
festgelegten zentralen Kriterien (K.O.-Kriterien) sondiert. Es wurden drei Systeme
Kapitel 6 Zusammenfassung und Ausblick
70
auf Basis einer rein relationalen Datenbank – TYPO3, Joomla und Drupal – und
zwei XML-basierte Systeme – eZ Publish und Papapya CMS – ermittelt.
Im dritten Teil wurde das Evaluationsverfahren für die Untersuchung der Systeme ausgearbeitet und vorgestellt. Dabei wurde die Methode des Expertenurteils
für die Durchführung der Untersuchung gewählt. Weiterhin wurden die Qualitätseigenschaften für den Kriterienkatalog auf der Basis von ISO 9126 festgelegt. Dabei
wurden die für Entwickler relevanten Merkmale aus den Qualitätsmodellen von
McCall sowie von Dißmann und Zurwehn berücksichtigt. Abgeschlossen wurde das
Kapitel mit der Vorstellung der aus den Kriterien abgeleiteten entwicklerrelevanten Fragestellungen, die zu einem Fragenkatalog zusammengefasst wurden. Gemäß
dem erstellten Kriterienkatalog wurden die Systeme anhand der drei SoftwareQualitätseigenschaften – Benutzbarkeit, Änderbarkeit und Übertragbarkeit – beurteilt. Als Experte ist der Autor dieser Arbeit aufgetreten, der die Systeme mittels
des Fragenkatalogs bewertet hat. Zu den ausgefüllten Fragenkatalogen wurden im
letzten Teil der Arbeit die sogenannten Polaritätsprofile erstellt und ausgewertet.
Die Auswertung der Profile hat ergeben, dass sich die Systeme auf XML-Basis aus
Entwicklersicht von den Systemen auf relationaler Basis positiv abheben konnten.
Sie haben deutlich bessere Ergebnisse bezüglich der Änderbarkeit der Systeme gezeigt und überzeugen in Hinblick auf Übertragbarkeit. Die einzige Schwäche liegt
in den nicht ausgereiften Installationsroutinen, die den gesamten Installationsaufwand erhöhen. Bezüglich der Benutzbarkeit der für Entwickler relevanten SoftwareBestandteile haben sich beide Systemgruppen mit minimalen Unterschieden ziemlich gut dargestellt. Hier haben die Systeme auf XML-Basis kleine Nachteile in der
Unterstützung durch Communitys, entwicklerrelevante Bücher und Anleitungen.
Diese Schwachstelle ist damit verbunden, dass die Systeme weniger bekannt sind
und dadurch nur von einer kleineren Community unterstützt werden.
Anhand der Ergebnisse der Untersuchung kann nun eine mögliche Antwort auf
die Kernfrage – warum sich XML-basierten Systeme trotz besserer Technik nicht
durchsetzten konnten – gegeben werden. Auf Grund des aufwändigen Installationsprozesses kann bereits beim ersten Kontakt mit dem System ein negativer Eindruck
entstehen. Darüber hinaus kann der Entwickler durch geringe Unterstützung abgehalten werden, sich mit der neuen Technik auseinander zu setzten, und kehrt zurück
zum alt bewährten. Dies hat zur Folge, dass die Community nicht erweitert wird
Kapitel 6 Zusammenfassung und Ausblick
71
und weiterhin gering bleibt. Ein System, das nur durch eine kleine Community unterstützt wird, gewinnt nur schwer das Vertrauen der Benutzer. Schließlich wird sich
für ein anderes System mit einer umfangreicheren Community entschieden. Um dem
entgegen zu wirken und weitere Erfolge verzeichnen zu können sollten die genannten
Defizite der XML-basierten Systeme korrigieren werden.
Letztendlich hat diese Arbeit gezeigt, dass sich der Einsatz der XML-Technologie
in einem CMS-System aus der Sicht der Entwickler rentiert. Um dieses Ergebnis
auf die Probe zu stellen und ein objektiveres und umfassenderes Urteil zu erzielen
besteht die Möglichkeit, die K.O.-Kriterien bei der Systemauswahl zu verringern
und dadurch die Anzahl der untersuchten Systeme zu erhöhen. Die Nachteile eines
Systems würden nicht zwangsläufig den gesamten Wert der Systemgruppe negativ
beeinflussen. Im Rahmen dieser Arbeit war es allerdings wichtig, die Auswahlkriterien zu den Systemen genau zu definieren, um die Vielfalt der Systeme auf eine
übersichtliche Anzahl einzugrenzen.
Außerdem wäre es noch interessant, die Systeme beider Gruppen einer Evaluation
aus Benutzersicht zu unterziehen und anschließend die neuen Ergebnisse mit denen
dieser Arbeit zu vergleichen. Die Anforderungen an die CMS wachsen durch den
Benutzer, der seine Ansprüche an die sich ständig entwickelnden Welt anpasst. Die
interne Struktur des Systems interessiert den Benutzer eher nicht; daher wird ein
System, das den Benutzer-Ansprüchen (funktionalen Anforderungen) entspricht,
weiter gut auf dem Markt positioniert. Die Meinung der Entwickler wird hier nicht
weiter beachtet. Ein solcher Vergleich wäre zwar sehr interessant, würde aber den
Rahmen dieser Arbeit sprengen und bleibt daher für folgende Arbeiten offen.
[Aghamanoukjan 2007] Aghamanoukjan, A. ; Ruber, R. ; Meyer, M.: Qualitative Interviews. In: Buber, R. ; Holzmüller, H. H.
(Hrsg.): Qualitative Marktforschung. Wiesbaden 2007, S.
415–435
[Ahlswede 2009] Ahlswede, M. ; Schult, T. J.: CMS-Ausstatter: Erweiterungen für Joomla und Typo3. iX (2009) Nr. 3, S. 92–94
[Ansorge 1998] Ansorge, P.: Entwicklungsbegleitende ergonomische Reviews und Usability-Tests.
Softwaretechnik-Trends 18
(1998), S. 11
[Balzert 1998] Balzert, H.: Lehrbuch der Software-Technik: SoftwareManagement, Software-Qualitätssicherung, Unternehmensmodellierung. Bd. 2, Heidelberg 1998
[Baumgartner 2004] Baumgartner, P. ; Häfele, H. ; Maier-Häfele, K.:
Content Management Systeme in e-Education, Innsbruck
2004
[Bennicke 2008] Bennicke, M. ; Hofmann, A. ; Lewerentz, C. ; Wichert, K.-H.: Software Controlling: Qualitätsbezogene
Projektsteuerung. Informatik-Spektrum 31 (2008), S. 556–
564
[Bogner 2005] Bogner, A. ; Littig, B. ; Menz, W.: Das Experteninterview: Theorie, Methode, Anwendung. 2. Aufl., Wiesbaden
2005
73
[Braun 2007] Braun, H.:
Website-Baukästen: Freie ContentManagement-Systeme und andere Werkzeuge für dynamische Internet-Auftritte. c’t (2007) Nr. 11, S. 88–95
[Bärwolff 2008] Bärwolff, M.: Monopolelemente bei freier Software. In:
Lutterbeck, B. ; Bärwolff, M. ; Gehring, R. A.
(Hrsg.): Open Source Jahrbuch 2008: Zwischen freier Software und Gesellschaftsmodell. Berlin 2008, S. 71–82
[Christ 2007] Christ, O.: Content Management in der Praxis, Berlin
2007
[Enderle 2001] Enderle, J.: XML in relationalen Datenbanken. Informatik Spektrum 24 (2001) Nr. 6, S. 357–368
[Ensthaler 2009] Ensthaler, J.: Gewerblicher Rechtsschutz und Urheberrecht. 3., überarb. u. erw. Aufl., Berlin 2009
[Franz 2008] Franz, M.: Drupal 6: Neue APIs und mehr Komfort. iX
(2008) Nr. 5, S. 62–64
[Glantschnig 2004] Glantschnig, P.: Innovative Content Management Systeme im Betrachtungsfeld von Java 2 Enterprise Edition,
Technischen Universität Graz, Diplomarbeit, 2004
[Graf 2008a] Graf, H.: Drupal 6: Websites entwickeln und verwalten
mit dem Open Source-CMS, München 2008
[Graf 2008b] Graf, H.: Joomla! 1.5: Websites organisieren und gestalten
mit dem Open Source-CMS, München 2008
[Grume 2003] Grume, M.: Eine Evaluierung kommerzieller Content Management Systeme, Technische Universität Wien, Bakkalaureatsarb., 2003
[Hampe-Neteler 1994] Hampe-Neteler, W.: Software-ergonomische Bewertung zwischen Arbeitsgestaltung und Softwareentwicklung,
Frankfurt a.M. 1994
74
[Hasecke 2008] Hasecke, J. U.: Anwenderemanzipation - Wie Nutzer die
Softwareentwicklung beeinflussen können. In: Lutterbeck, B. ; Bärwolff, M. ; Gehring, R. A. (Hrsg.): Open
Source Jahrbuch 2008: Zwischen freier Software und Gesellschaftsmodell. Berlin 2008, S. 13–24
[Hauser 2008] Hauser, T. ; Pietsch, A.: Open Source Content Management - Eine kritische Betrachtung. In: Lutterbeck, B.
; Bärwolff, M. ; Gehring, R. A. (Hrsg.): Open Source
Jahrbuch 2008: Zwischen freier Software und Gesellschaftsmodell. Berlin 2008, S. 245–254
[Hofmann 2008] Hofmann, A. ; Krebs, M. ; Stamm, C. ; Sury, U.: Lancierung und Verwaltung von Open Source Projekten. IMVS
Fokus Report 200 (2008), S. 24–35
[Hüttenegger 2006] Hüttenegger, G.: Open Source Knowledge Management,
Berlin 2006
[Kampffmeyer 2007] Kampffmeyer, U.: Worauf kommt es bei der CMSAuswahl an? In: Schwarz, T. (Hrsg.): Leitfaden OnlineMarketing. Waghäusel 2007, S. 256–263
[Koller 2007] Koller, A.: Web Content und Content Management Systeme: Ohne Struktur kein Semantic Web!, Berlin 2007
[Lammenett 2007] Lammenett, E.: TYPO3 Online-Marketing-Guide, Wiesbaden 2007
[Mayer 2006] Mayer, H.O.: Interview und schriftliche Befragung: Entwicklung, Durchführung und Auswertung. 3. Aufl., Oldenburg 2006
[Moos 2008] Moos, A.: XQuery und SQL/XML in DB2-Datenbanken:
Verwaltung und Erzeugung von XML-Dokumenten in DB2,
Wiesbaden 2008
[Päßler 2006] Päßler, M. ; M., Nicola: Native XML-Unterstützung in
DB2 Viper. Datenbank Spektrum 17 (2006), S. 42–47
75
[Pomberger 1996] Pomberger, G. ; Blaschek, G. ; Kepler, J.: Software Engineering: Prototyping und objektorientierte SoftwareEntwicklung. 2. Aufl., München 1996
[Popper 2008] Popper, A.: An der frischen Luft: Enterprise Content Management mit Alfresco. iX (2008) Nr. 7, S. 76–82
[Potschka 2009] Potschka, F.: Mehr Kbytes: Content Management. iX
(2009) Nr. 1, S. 144–145
[Pressman 2005] Pressman, R. S.: Software Engineering: A Practitioner’s
Approach. 6th ed., New York 2005
[Rachbauer 2007] Rachbauer, T.: Evaluierung des Content Management
Systems EZ Publish, Norderstedt, Studienarbeit, 2007
[Schmid 1987] Schmid, W.: Das Anwenderbrevier: Die zehn Tugenden
guter Software, Frankfurt a.M 1987
[Thiess 2003] Thiess, K.: Analyse von Open Source Content Management Systemen als Mittel des Informationsmanagements
und Implementierung einer Beispielanwendung in einem
deutschen Automobilkonzern, Technische Fachhochschule
Wildau, Diplomarbet, 2003
[Wallmüller 2001] Wallmüller, E.: Software-Qualitätsmanagement in der
Praxis. 2. Aufl., München 2001
Onlineverzeichnis
[Efo 2009] http://www.eforia.de/text/eforia_web_manager/
support/begriffserklaerungen_de.html, Abruf: 15.07.2009
[eTe 2007] Content Management Systeme. http://www.e-teaching.org/
technik/distribution/cms/index_html, Abruf: 15.07.2009
[Hedemann 2009a] Hedemann, F.:
Google akzeptiert die Bewerbung von
TYPO3 für den ”Summer of Code 2009”.
http:
//t3n.de/news/typo3-google-akzeptiert-bewerbungtypo3-summer-code-2009-239982/, Abruf: 05.09.2009
[Hedemann 2009b] Hedemann, F.:
Wappalyzer durchleuchtet Websites: Welche Software wird wie oft verwendet?
http:
//t3n.de/news/wappalyzer-durchleuchtet-websiteswelche-software-oft-237871/, Abruf: 01.09.2009
[Hein 2006] Hein, A.:
Hinweise zur Erstellung und Dokumentation benutzerfreundlicher und fehlertoleranter Software.
http://www.informatik.fh-nuernberg.de/professors/
hein/HINTS/Software_Development.pdf, Abruf: 20.12.2009
[Hein 2009] Hein, A.: Content Management: Gestern, heute und morgen.
http://www.contentmanager.de/magazin/artikel_
1977_content_management.html, Abruf: 26.06.2009
[Kelter 2007] Kelter, U.:
Software-Qualitätsmodelle.
http:
//pi.informatik.uni-siegen.de/lehre/2009s/LM/lm_
sqmo_20070505_a5.pdf, Abruf: 19.11.2009
Onlineverzeichnis
77
[Kleijn 2006] Kleijn, A.: Open-Source-Lizenzen. http://www.heise.de/
open/Open-Source-Lizenzen--/artikel/75786/1, Abruf:
27.07.2009
[Krüger 2007a] Krüger, D.:
Kriterien für die (W)CMS-Auswahl.
http://www.jdk.de/de/cms/wcm-cms-web-contentmanagement/auswahlkriterien-wcm.html, Abruf: 20.09.2009
[Krüger 2007b] Krüger, D.:
Was ist Enterprise Content Management
(ECM)?
http://www.jdk.de/de/cms/ecm-enterprisecontent-management/was-ist-ecm.html, Abruf: 18.07.2009
[pap 2009a] papaya CMS 5.0. http://www.contentmanager.de/itguide/
produkt_599_papaya_cms_50_open_source_unter_gpl.
html, Abruf: 26.11.2009
[pap 2009b] papaya CMS: Leistungsmerkmale. http://www.papaya-cms.
com/leistungsmerkmale.29.html, Abruf: 27.11.2009
[Rutke 2009] Rutke, R.: Neue eZ Publish Version 4.1 mit erweiterter Unterstützung für große Unternehmens- und Medienportale in Verbindung mit vollständigem Support und Wartungsangebot des
Herstellers. http://www.pressebox.de/pressemeldungen/
ez-systems-germany-gmbh/boxid-249177.html,
Abruf:
26.11.2009
[Schulz 2008] Schulz, H.:
Bitkom: Vier von fünf deutschen Unternehmen präsentieren sich im Internet.
http:
//www.heise.de/newsticker/Bitkom-Vier-von-fuenfdeutschen-Unternehmen-praesentieren-sich-imInternet--/meldung/109799, Abruf: 28.06.2009
[Sommergut 2005] Sommergut, W.: Freie CMS-Lösungen für Unternehmen.
http://www.computerwoche.de/index.cfm?pid=378&pk=
552813&p=1, Abruf: 18.08.2009
[Stamm 2002] Stamm, M.:
Web Content Management System.
http://www.cyres.de/cms-grundlagen/cms-definition/
web-content-management-system.htm, Abruf: 05.07.2009
Onlineverzeichnis
78
[Steyer 2007] Steyer, R.:
Systemvorstellung: Joomla! im Überblick.
http://www.contentmanager.de/magazin/artikel_1421_
joomla_cms_open_source.html, Abruf: 22.11.2009
[Tiemann 2006] Tiemann, M.:
http://www.opensource.org/licenses/
alphabetical, Abruf: 29.07.2009
[typ 2009] Höchste Performance und Sicherheit mit Typo3. http://www.
24ix.de/Typo3.55.0.html, Abruf: 21.11.2009
[Winkler 2001] Winkler, J.: Content Management mit XML. http://www.
html-world.de/program/xml_6.php, Abruf: 16.07.2009
[Wittenbrink 2003] Wittenbrink, H ; Köhler, W.:
XML.
//www.teialehrbuch.de/Kostenlose-Kurse/XML/,
07.07.2009
http:
Abruf:
1.1
2.1
2.2
Mögliche Überschneidungen der Entwickler- und Anwendergruppen
in einer OS-Community . . . . . . . . . . . . . . . . . . . . . . . .
5
Aufbau eines CMS . . . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht der CMS-Datenhaltung: Aufteilung in XML- und relationale Speicherungsgruppen . . . . . . . . . . . . . . . . . . . . . . .
19
3.1
3.2
3.3
Verteilung der Open-Source-Lizenzen . . . . . . . . . . . . . . . . .
Wappalyzer Statistik für April 2009: 20 meist verwendete CMS . . .
Übersicht der CMS-Datenhaltung und der gewählten Systeme . . .
23
26
28
4.1
4.2
4.3
4.4
Aufbau von Qualitätsmodellen . . . . . . . . . . . . . . . . . . . . .
Merkmale der ISO 9126 . . . . . . . . . . . . . . . . . . . . . . . .
Qualitätsmodell von McCall: relevante Eigenschaften für Entwickler
Qualitätsmodell von Dißman und Zurwehn: relevante Eigenschaften
für Programmierer . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
38
39
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Polaritätsprofil: relational basierte Systeme bezüglich der Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Polaritätsprofil: relational basierte Systeme bezüglich der Änderbarkeit
Polaritätsprofil: relational basierte Systeme bezüglich der Übertragbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Polaritätsprofil: XML-basierte Systeme bezüglich der Benutzbarkeit
Polaritätsprofil: XML-basierte Systeme bezüglich der Änderbarkeit .
Polaritätsprofil: XML-basierte Systeme bezüglich der Übertragbarkeit
Polaritätsprofil: relational und XML-basierte Systeme bezüglich der
Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
40
52
54
56
58
59
61
63
5.8
5.9
Polaritätsprofil: relationale und XML-basierte Systeme bezüglich der
Änderbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Polaritätsprofil: relationale und XML-basierte Systeme bezüglich der
Übertragbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
65
67
Tabellenverzeichnis
3.1
3.2
Die Gewinner der CMS Awards . . . . . . . . . . . . . . . . . . . .
Ergebnisse der Sekundäranalyse . . . . . . . . . . . . . . . . . . . .
25
27
4.1
Qualitätsmerkmale bzw. -Kriterien von McCall, Dißmann und Zurwehn, ISO 9126 und CMS-Award . . . . . . . . . . . . . . . . . . .
42
A.1
A.2
A.3
A.4
A.5
A.6
Fragenkatalog
Fragenkatalog
Fragenkatalog
Fragenkatalog
Fragenkatalog
Fragenkatalog
zu
zu
zu
zu
zu
zu
TYPO3 . . .
Joomla . . . .
Drupal . . . .
eZ Publish . .
Papaya CMS .
Joomla . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 88
. 93
. 98
. 103
. 108
. 113
Abkürzungen
API
Application Programming Interface
BSD
Berkeley Software Distribution
CLOB Character Large Object
CM
Content Management
CMS Content Management System
CSS
Cascading Style Sheets
DB
Datenbank
DBMS Datenbankmanagementsystem
DTD Dokumenttypdefinition
ECM Enterprise Content Management
ECMS Enterprise Content Management System
FSF
Free Software Foundation
GQM Goal-Question-Metric
GSoC Google Summer of Code
GPL
General Public License
HTML Hypertext Makrup Language
ISP
Internet Service Provider
J2EE Java 2 Platform, Enterprise Edition
Java EE Java Platform, Enterprise Edition
JCA
Java Connector Architecture
MPL Mozilla Public License
LAMP Linux, Apache, MySQL, PHP (auch Perl oder Python)
LGPL Lesser General Public License
MySQL My Structured Query Language
OS
Open Source
OSD
The Open Source Definition
OSI
Open Source Initiative
Tabellenverzeichnis
PDF
Portable Document Format
PHP
Personal Home Page; PHP Hypertext Preprocessor
SQL
Structured Query Language
XDBMS XML-Datenbankmanagementsystem
XHTML eXtensible Hypertext Makrup Language
XDBMS XML Datenbankmanagementsystem
XML eXtensible Markup Language
XSLT eXtensible Stylesheet Language Transformation
WAP Wireless Access Point
WML Wireless Markup Language
WCMS Web Content Management System
WYSIWYG What You See Is What You Get
WWW World Wide Web
83
Anhang A
Fragenkataloge
Hier sind alle vom Experten ausgewerteten Fragenkataloge zu jedem System angehängt. Jeder Fragenkatalog ist in die festgelegten Merkmale aufgeteilt. Außerdem
sind die Fragen zu den abgeleiteten Untermerkmalen mit Trennlinien von einander abgegrenzt, damit die Aussagen zu jedem einzelnen Qualitästskriterium besser
nachvollziehbar sind.
Die Experten-Bewertungen beziehen sich auf die aktuellen Versionen1 der Systeme,
die als stabil laufend (‚stable‘) bezeichnet sind.
Die zur Bewertung angebotenen adjektivischen Gegensatzpaare sind so angeordnet,
dass die links von ‚0‘ platzierten möglichen Einstufungen von negativer und die
rechten von positiver Bedeutung sind.
1
Stand vom 01.11.2009 bis 01.12.2009
A.1 TYPO3
85
A.1 TYPO3
Die Bewertung der Experten zu TYPO3 in der Version 4.2.10.
Benutzbarkeit
Nr.
Frage
Antwort
1. Wie ausführlich ist der Quellcode
dokumentiert?
k.A.
+ ++ ausführknapp −− − 0 lich
2. Wie gut ist die Software abstrahiert (objektorientiert implementiert)?
+ ++
schlecht −− − 0 gut
3. Wie lesbar ist der Quellcode?
++
schlecht −− − 0 + gut
4. Wie sind die Variablen in dem
Quellcode benannt?
+ ++ verständunver- −− − 0 ständlich
lich
die
− 0 + ++ ausführknapp −− lich
6. Wie umfangreich ist die Software graphisch dokumentiert (z.B.
durch UML-Diagramme)?
+ ++ umfanggering −− − 0 reich
5. Wie
ausreichend
sind
Quellcode-Kommentare?
7. Wie gut ist die Programmierschnittstelle zum Systemkern
(Core API) beschrieben?
++
8. Wie ausführlich ist die Datenbankschnittstelle dokumentiert?
++
9. Wie viele Erweiterungen haben
eine Dokumentation?
+ ++
wenige −− − 0 viele
10. Wie gut sind die Erweiterungen
dokumentiert?
A.1 TYPO3
Nr.
86
Frage
Antwort
k.A.
11. Wie schnell ist die SystemArchitektur erlernbar?
−−− 0 + ++
langsam 12. Wie hilfreich sind die Fehlermeldungen?
0 + ++
wenig −− − sehr
hilfreich
hilfreich
schnell
13. Wie viele Entwicklerhandbücher
gibt es?
++
wenige −− − 0 + viele
14. Wie groß ist die EntwicklerCommunity zu dem System?
++
klein −− − 0 + groß
15. Wie viele entwicklerrelevante Tutorials gibt es?
++
16. Wie hoch ist die Dichte der
Dienstleister?
++
niedrig −− − 0 + hoch
Änderbarkeit
Nr.
Frage
17. Wie gut lässt sich das Programm
auf Fehler durch ein Fehlersuchprogramm (Debugger) untersuchen?
Antwort
+ ++
schlecht −− − 0 k.A.
gut
− 0 + ++ komforta18. Wie komfortabel lassen sich Sys- unkomfor- −− temausgaben (Protokoll-Dateien)
tabel
bel
steuern?
19. Wie verständlich sind die Systemausgaben (in einer ProtokollDatei)?
0 + ++ verständunver- −− − ständlich
lich
A.1 TYPO3
Nr.
87
Frage
20. Wie gut kann das System über
Module erweitert oder ausgebaut
werden?
Antwort
++
schlecht −− − 0 + k.A.
gut
21. Wie einfach lassen sich die Module anderer Entwickler installieren?
0 + ++
schwer −− − einfach
22. Wie schwer ist die Struktur für eine Erweiterung anzulegen?
−−− 0 + ++
schwer einfach
23. Wie viele System-Komponenten
lassen sich über die Erweiterungen ändern bzw. ausbauen?
+ ++
24. Wie oft treten unerwartete Nebenwirkungen nach der Installation einer neuen Erweiterung auf?
0 + ++
oft −− − selten
25. Wie gut wird die Software durch
die Community in Hinblick auf
Fehlerkorrektur und Sicherheit
gewartet (z.B. Bug Fixes, Security Updates)?
++
schlecht −− − 0 + 26. Wie groß sind die Auswirkungen
kleiner Fehler?
−−− 0 + ++
groß gut
klein
27. Wie reagiert das System auf
Überlastungen bzw. Fehlermeldungen (zahlreiche, gleichzeitige
Fehler)?
− 0 + ++
schlecht −− gut
28. Wie viele Möglichkeiten gibt es,
einzelne System-Module zu testen?
− 0 + ++
wenige −− viele
A.1 TYPO3
Nr.
88
Frage
Antwort
29. Wie einfach ist die Prüfung einer Komponente unabhängig vom
System möglich?
−−− 0 + ++
schwer k.A.
einfach
Übertragbarkeit
Nr.
Frage
Antwort
k.A.
30. Auf wie vielen verschiedenen
Plattformen und Betriebssystemen kann das System laufen?
++ auf vielen
auf −− − 0 + wenigen
31. Auf wie vielen unterschiedlichen
Webservern kann das System laufen?
+ ++ auf vielen
auf −− − 0 wenigen
32. Wie viele verschiedene Möglichkeiten (verschiedene DBMS,
Dateisystem) stehen für die Datenhaltung zur Verfügung?
++
wenige −− − 0 + ++
33. In wie vielen Webbrowsern läuft in wenigen −− − 0 + das System-Backend?
viele
in vielen
+ ++ komforta34. Wie komfortabel sind die unkomfor- −− − 0 Installationsroutinen
(z.B.
tabel
bel
DB-Einrichtung,
DateisystemKonfiguration)?
35. Wie viele zusätzliche (System-)
Programme werden vorausgesetzt, um das System vollständig
nutzen zu können?
− 0 + ++
viele −− wenige
A.1 TYPO3
Nr.
89
Frage
Antwort
k.A.
36. Wie viele abhängige (System-)
Programme müssen unabhängig
von der Installation eingestellt
werden?
+ ++
viele −− − 0 37. Wie gut lassen sich die nötigen
Parameter der gegebenen Systemumgebung über das Installationswerkzeug einstellen?
++
38. Wie gut wird die Verfügbarkeit
aller für die Programmnutzung
notwendigen Daten und Datenbereiche (Speicherbedarf) während
der Installation überprüft?
++
39. Wie ähnlich ist die Konfigurationssprache einer offenen Standardsprache?
−−− 0 + ++
nicht ähnlich
sehr
ähnlich
40. Wie gut wird XML unterstützt?
0 + ++
schlecht −− − gut
41. Wie gut werden Standards (z.B.
SQL92, XML) bei der Datenhaltung eingehalten?
++
42. Wie gut lassen sich die Daten exportieren bzw. migrieren?
+ ++
43. Wie gut können spezifische Module in einem neuen System weiterverwendet werden?
− 0 + ++
schlecht −− gut
Tabelle A.1: Fragenkatalog zu TYPO3
wenige
A.2 Joomla
90
A.2 Joomla
Die Experten-Bewertung von Joomla anhand der Version 1.5.15.
Benutzbarkeit
Nr.
Frage
Antwort
dokumentiert?
k.A.
0 + ++ ausführknapp −− − lich
++
++
Quellcode benannt?
5. Wie
ausreichend
sind
die
++ verständunver- −− − 0 + ständlich
lich
++
knapp −− − 0 + ausführlich
− 0 + ++ umfanggering −− reich
++
− 0 + ++
schlecht −− gut
eine Dokumentation?
−−− 0 + ++
wenige viele
dokumentiert?
− 0 + ++ ausführknapp −− lich
A.2 Joomla
Nr.
91
Frage
Antwort
k.A.
+ ++
langsam −− − 0 12. Wie hilfreich sind die Fehlermeldungen?
0 + ++
wenig −− − sehr
hilfreich
hilfreich
schnell
gibt es?
− 0 + ++
wenige −− viele
++
− 0 + ++
wenige −− viele
Dienstleister?
++
Änderbarkeit
Nr.
Frage
Antwort
0 + ++
schlecht −− − k.A.
gut
−−− 0 + ++ komforta18. Wie komfortabel lassen sich Sys- unkomfor- temausgaben (Protokoll-Dateien)
tabel
bel
steuern?
− 0 + ++ verständunver- −− ständlich
lich
A.2 Joomla
Nr.
92
Frage
Antwort
k.A.
werden?
++
++
schwer −− − 0 + einfach
+ ++
schwer −− − 0 einfach
0 + ++
wenige −− − viele
+ ++
oft −− − 0 selten
0 + ++
schlecht −− − 26. Wie groß sind die Auswirkungen
kleiner Fehler?
+ ++
groß −− − 0 27. Wie reagiert das System auf
Fehler)?
schlecht −− − 0 + ++
gut
− 0 + ++
wenige −− viele
gut
klein
X
A.2 Joomla
Nr.
93
Frage
Antwort
System möglich?
−−− 0 + ++
schwer k.A.
einfach
Übertragbarkeit
Nr.
Frage
Antwort
k.A.
++ auf vielen
− 0 + ++ auf vielen
auf −− wenigen
0 + ++
+ ++ in vielen
33. In wie vielen Webbrowsern läuft in wenigen −− − 0 das System-Backend?
(z.B.
tabel
bel
DB-Einrichtung,
nutzen zu können?
+ ++
viele −− − 0 wenige
A.2 Joomla
Nr.
94
Frage
Antwort
k.A.
werden?
++
viele −− − 0 + 37. Wie gut lassen sich die nötigen
+ ++
+ ++
+ ++
nicht −− − 0 ähnlich
sehr
ähnlich
+ ++
++
+ ++
− 0 + ++
schlecht −− gut
Tabelle A.2: Fragenkatalog zu Joomla
wenige
A.3 Drupal
95
A.3 Drupal
Die Experten-Bewertung von Drupal in der Version 6.15.
Benutzbarkeit
Nr.
Frage
Antwort
k.A.
dokumentiert?
++
0 + ++
schlecht −− − gut
++
Quellcode benannt?
lich
die
++
−−− 0 + ++
gering umfangreich
+ ++
+ ++
eine Dokumentation?
+ ++
5. Wie
ausreichend
sind
dokumentiert?
A.3 Drupal
Nr.
96
Frage
Antwort
k.A.
0 + ++
langsam −− − 12. Wie hilfreich sind die Fehlermeldungen?
+ ++
wenig −− − 0 sehr
hilfreich
hilfreich
schnell
gibt es?
+ ++
++
++
Dienstleister?
++
Änderbarkeit
Nr.
Frage
Antwort
− 0 + ++
schlecht −− k.A.
gut
++ komforta18. Wie komfortabel lassen sich Sys- unkomfor- −− − 0 + temausgaben (Protokoll-Dateien)
tabel
bel
steuern?
lich
A.3 Drupal
Nr.
97
Frage
Antwort
k.A.
werden?
++
schlecht −− − 0 + 21. Wie einfach lassen sich die Module anderer Entwickler installieren?
+ ++
schwer −− − 0 einfach
− 0 + ++
schwer −− einfach
++
+ ++
+ ++
schlecht −− − 0 26. Wie groß sind die Auswirkungen
kleiner Fehler?
− 0 + ++
groß −− 27. Wie reagiert das System auf
Fehler)?
gut
+ ++
gut
gut
klein
X
A.3 Drupal
Nr.
98
Frage
Antwort
System möglich?
0 + ++
schwer −− − k.A.
einfach
Übertragbarkeit
Nr.
Frage
Antwort
k.A.
++ auf vielen
+ ++ auf vielen
+ ++
wenige −− − 0 ++
viele
in vielen
(z.B.
tabel
bel
DB-Einrichtung,
nutzen zu können?
+ ++
A.3 Drupal
Nr.
99
Frage
Antwort
k.A.
werden?
+ ++
+ ++
+ ++
+ ++
sehr
ähnlich
− 0 + ++
schlecht −− gut
++
+ ++
− 0 + ++
schlecht −− gut
Tabelle A.3: Fragenkatalog zu Drupal
wenige
A.4 eZ Publish
100
A.4 eZ Publish
Die Experten-Bewertung von eZ Publish in der Version 4.2.0.
Benutzbarkeit
Nr.
Frage
Antwort
k.A.
dokumentiert?
++
knapp −− − 0 + 2. Wie gut ist die Software abstrahiert (objektorientiert implementiert)?
++
++
Quellcode benannt?
ausführlich
++ verständunver- −− − 0 + ständlich
lich
die
+ ++ umfanggering −− − 0 reich
5. Wie
ausreichend
sind
++
++
eine Dokumentation?
dokumentiert?
0 + ++
A.4 eZ Publish
Nr.
101
Frage
Antwort
k.A.
0 + ++
langsam −− − 12. Wie hilfreich sind die Fehlermeldungen?
+ ++
hilfreich
hilfreich
schnell
gibt es?
0 + ++
++
0 + ++
Dienstleister?
0 + ++
niedrig −− − hoch
Änderbarkeit
Nr.
Frage
Antwort
+ ++
schlecht −− − 0 k.A.
gut
− 0 + ++ komforta18. Wie komfortabel lassen sich Sys- unkomfor- −− temausgaben (Protokoll-Dateien)
tabel
bel
steuern?
0 + ++ verständunver- −− − ständlich
lich
A.4 eZ Publish
Nr.
102
Frage
Antwort
k.A.
werden?
+ ++
− 0 + ++
schwer −− einfach
0 + ++
schwer −− − einfach
+ ++
+ ++
++
schlecht −− − 0 + 26. Wie groß sind die Auswirkungen
kleiner Fehler?
++
groß −− − 0 + 27. Wie reagiert das System auf
Fehler)?
gut
+ ++
gut
klein
X
A.4 eZ Publish
Nr.
103
Frage
Antwort
System möglich?
− 0 + ++
schwer −− k.A.
einfach
Übertragbarkeit
Nr.
Frage
Antwort
k.A.
++ auf vielen
+ ++ auf vielen
+ ++
wenige −− − 0 ++
viele
in vielen
++ komforta34. Wie komfortabel sind die unkomfor- −− − 0 + Installationsroutinen
(z.B.
tabel
bel
DB-Einrichtung,
nutzen zu können?
+ ++
A.4 eZ Publish
Nr.
104
Frage
Antwort
k.A.
werden?
+ ++
++
++
+ ++
sehr
ähnlich
++
++
++
++
Tabelle A.4: Fragenkatalog zu eZ Publish
wenige
A.5 Papaya CMS
105
A.5 Papaya CMS
Die Experten-Bewertung von Papaya CMS anhand der Version 5.0.
Benutzbarkeit
Nr.
Frage
Antwort
dokumentiert?
k.A.
++
++
Quellcode benannt?
5. Wie
ausreichend
sind
die
lich
−−− 0 + ++
gering 7. Wie gut ist die Programmierschnittstelle zum Systemkern
−−− 0 + ++
schlecht gut
− 0 + ++
schlecht −− gut
eine Dokumentation?
− 0 + ++
wenige −− viele
dokumentiert?
−−− 0 + ++
knapp ausführlich
umfangreich
A.5 Papaya CMS
Nr.
106
Frage
Antwort
k.A.
++
langsam −− − 0 + 12. Wie hilfreich sind die Fehlermeldungen?
+ ++
hilfreich
hilfreich
schnell
gibt es?
− 0 + ++
wenige −− viele
− 0 + ++
klein −− groß
−−− 0 + ++
wenige viele
Dienstleister?
−−− 0 + ++
niedrig hoch
Änderbarkeit
Nr.
Frage
Antwort
++
schlecht −− − 0 + k.A.
gut
++ komforta18. Wie komfortabel lassen sich Sys- unkomfor- −− − 0 + temausgaben (Protokoll-Dateien)
tabel
bel
steuern?
lich
A.5 Papaya CMS
Nr.
107
Frage
Antwort
k.A.
werden?
++
++
++
++
+ ++
+ ++
schlecht −− − 0 26. Wie groß sind die Auswirkungen
kleiner Fehler?
++
groß −− − 0 + 27. Wie reagiert das System auf
Fehler)?
gut
++
gut
klein
X
A.5 Papaya CMS
Nr.
108
Frage
Antwort
System möglich?
++
schwer −− − 0 + k.A.
einfach
Übertragbarkeit
Nr.
Frage
Antwort
k.A.
++ auf vielen
++ auf vielen
+ ++
wenige −− − 0 ++
viele
in vielen
−−− 0 + ++ komforta34. Wie komfortabel sind die unkomfor- Installationsroutinen
(z.B.
tabel
bel
DB-Einrichtung,
nutzen zu können?
−−− 0 + ++
viele wenige
A.5 Papaya CMS
Nr.
109
Frage
werden?
Antwort
0 + ++
viele −− − k.A.
wenige
37. Wie gut lassen sich die nötigen
−−− 0 + ++
schlecht gut
− 0 + ++
schlecht −− gut
++
nicht −− − 0 + ähnlich
sehr
ähnlich
++
++
++
+ ++
Tabelle A.5: Fragenkatalog zu Papaya CMS
A.6 Fragenkatalog
110
A.6 Fragenkatalog
.
Benutzbarkeit
Nr.
Frage
Antwort
dokumentiert?
k.A.
knapp −− − 0 + ++ ausführlich
gut
gut
Quellcode benannt?
5. Wie
ausreichend
sind
unver- −− − 0 + ++ verständständlich
lich
die
gering −− − 0 + ++ umfangreich
gut
gut
eine Dokumentation?
wenige −− − 0 + ++
viele
dokumentiert?
A.6 Fragenkatalog
Nr.
111
Frage
Antwort
k.A.
langsam −− − 0 + ++
schnell
12. Wie hilfreich sind die Fehlermeldungen?
wenig −− − 0 + ++
sehr
hilfreich
hilfreich
gibt es?
wenige −− − 0 + ++
viele
klein −− − 0 + ++
groß
wenige −− − 0 + ++
viele
Dienstleister?
niedrig −− − 0 + ++
hoch
Änderbarkeit
Nr.
Frage
Antwort
k.A.
gut
18. Wie komfortabel lassen sich Sys- unkomfor- −− − 0 + ++ komfortatemausgaben (Protokoll-Dateien)
tabel
bel
steuern?
unver- −− − 0 + ++ verständständlich
lich
A.6 Fragenkatalog
Nr.
112
Frage
Antwort
k.A.
werden?
gut
schwer −− − 0 + ++
einfach
schwer −− − 0 + ++
einfach
wenige −− − 0 + ++
viele
oft −− − 0 + ++
selten
26. Wie groß sind die Auswirkungen
kleiner Fehler?
groß −− − 0 + ++
27. Wie reagiert das System auf
Fehler)?
gut
wenige −− − 0 + ++
viele
gut
klein
X
A.6 Fragenkatalog
Nr.
113
Frage
Antwort
System möglich?
schwer −− − 0 + ++
k.A.
einfach
Übertragbarkeit
Nr.
Frage
Antwort
k.A.
auf −− − 0 + ++ auf vielen
wenigen
auf −− − 0 + ++ auf vielen
wenigen
wenige −− − 0 + ++
viele
33. In wie vielen Webbrowsern läuft in wenigen −− − 0 + ++ in vielen
das System-Backend?
34. Wie komfortabel sind die unkomfor- −− − 0 + ++ komfortaInstallationsroutinen
(z.B.
tabel
bel
DB-Einrichtung,
nutzen zu können?
viele −− − 0 + ++
wenige
A.6 Fragenkatalog
Nr.
114
Frage
Antwort
k.A.
werden?
viele −− − 0 + ++
37. Wie gut lassen sich die nötigen
gut
gut
nicht −− − 0 + ++
ähnlich
sehr
ähnlich
gut
gut
gut
gut
Tabelle A.6: Fragenkatalog zu Joomla
wenige
Danksagung
Zu der Entstehung dieser Arbeit haben mehrere Personen beigetragen, denen ich
hiermit danken möchte.
An erster Stelle danke ich meinem Betreuer Prof. Dr. Karl-Heinz Rödiger für seine
intensive Unterstützung, seine ständige Hilfsbereitschaft und seine wertvollen Literaturhinweise. Er hat sich immer auch für spontane Treffen Zeit genommen, um
über neue Ideen oder Probleme bei meiner Arbeit zu sprechen. Außerdem danke ich
herzlich meinem Arbeitgeber und Kollegen Jan-Christoph Kranefeld für seine exklusive technische Beratung und die sehr oft mühsamen Fehlerkorrekturen. Weiterhin
danke ich herzlich Herrn Lukas Kumai für seine hilfreiche Ratschläge und Verbesserungsvorschläge. Ich danke auch meiner Freundin Katrin für die vielen Stunden, die
sie auf mich verzichten musste. Ein letztes Dankeschön geht an ihre Mutter Bärbel
und meinen Kommilitonen Jakob für das abschließende Korrekturlesen.

Diplomarbeit_Pavel_H..

Transcription

Similar documents

Proceedings 25. GI-Workshop „Grundlagen von - CEUR

PDF-Download

touren-test bmw r 1200 gs

Dipl. Inf. Michael Christen

Evaluierung von Open Source Konferenzwerkzeugen unter dem

Masterarbeit - WWW-Docs for TU

Workshop Karten für MapSource (neu: BaseCamp) und Garmin-GPS

Die Linux-Konsole, die Bash, das Terminal, die - Anti

newsWorks Installation Einzelplatz