Content Management Systeme. Möglichkeiten und Vorteile für kleine und mittelständische Unternehmen

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Anhangsverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation und Ziel der Arbeit
1.2 Aufbau der Arbeit

2 Grundlagen
2.1 Kleine und mittelständische Unternehmen
2.2 Open Source Software
2.2.1 Definition und Begriffsabgrenzung
2.2.2 Open Source Software Lizenzen
2.2.3 Vor- und Nachteile von Open Source Software
2.2.3.1 Vorteile von Open Source Software
2.2.3.2 Nachteile von Open Source Software
2.2.4 Open Source Geschäftsmodelle
2.3 Webtechnologien und -standards
2.3.1 SGML – Standard Generalized Markup Language und XML – Extensible Markup Language
2.3.2 (X)HTML – (Extensible) HyperText Markup Language
2.3.3 PHP – Hypertext Preprocessor
2.3.4 CSS – Cascading Stylesheets
2.3.5 Java und Javascript
2.4 Vorgehensmodelle zur Systementwicklung und
-implementation
2.4.1 Phasenmodell der Systementwicklung
2.4.1.1 Analysephase
2.4.1.2 Eigenentwicklung oder Standardsoftware?
2.4.1.3 Entwurfsphase bei Eigenproduktion
2.4.1.4 Entwurfsphase bei Standardsoftware
2.4.1.5 Realisierungsphase bei Eigenentwicklung
2.4.1.6 Realisierungsphase bei Standardsoftware
2.4.1.7 Einführungsphase
2.4.1.8 Kritik des Phasenmodells
2.4.2 Wasserfall- und V-Modell

3 Von Content zu Content Management Systemen
3.1 Content
3.2 Content Management
3.2.1 Gestaltungsprinzipien des Content Managements
3.2.2 Prozess des Content Managements
3.3 Content Management Systeme
3.3.1 Zentrale Funktionen von Content Management Systemen
3.3.2 Dokumenten Management Systeme
3.3.3 Knowledge Management Systeme
3.3.4 Web Content Management Systeme
3.3.4.1 Aufbau von Web Content Management Systemen
3.3.4.2 Vorteile von Web Content Management Systemen
3.3.5 Enterprise Content Management Systeme
3.3.5.1 Aufbau von Enterprise Content Management Systemen
3.3.5.2 Vorteile von Enterprise Content Management Systemen
3.4 Kritische Erfolgsfaktoren für Content Management Systeme
3.5 Open Source vs. kommerzielle Content Management Systeme

4 Konzeption von Content Management Systemen für kleine und mittelständische Unternehmen
4.1 Projektbegründung und -vorbereitung
4.2 Analysephase
4.2.1 Durchführung einer Ist-Analyse
4.2.2 Entwicklung eines Soll-Konzeptes
4.3 Auswahl und Anschaffung eines CMS
4.4 Realisierungsphase
4.5 Einführungsphase

5 Praxisbeispiel: Konzeption eines neuen Webauftritts für das IWI
der Leibniz Universität Hannover
5.1 Vorphase
5.2 Die ehemalige Webseite des IWI – Eine Ist-Analyse
5.2.1 Erhebung des Ist-Zustandes
5.2.2 Schwachstellen
5.3 Aufstellen des Soll-Konzeptes
5.3.1 Anforderungsanalyse
5.3.2 Grobentwurf
5.3.3 Pflichtenheft
5.4 Auswahl und Anschaffung des geeigneten Content Management Systems
5.4.1 Grobbewertung
5.4.2 Typo3
5.4.3 Redaxo
5.4.4 Joomla!
5.4.5 Feinbewertung
5.5 Realisierung
5.5.1 Installation und Konfiguration des WCMS Joomla!
5.5.2 Das neue Template
5.5.3 Individualprogrammierung
5.6 Einführung

6 Fazit und Ausblick
6.1 Zusammenfassung der Ergebnisse
6.2 Ausblick

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abb. 1: Nutzung von Internet und E-Business in kleinen und mittelständischen Unternehmen

Abb. 2: Verteilung der OSS-Lizenzen bei SourceForge

Abb. 3: Wahrnehmung der Vorteile von OSS aus Sicht der Anwender

Abb. 4: Wahrnehmung der Nachteile von OSS aus Sicht der Anwender

Abb. 5: Open Source Geschäftsmodelle

Abb. 6: Zusammenhang von SGML, XML, HTML und CSS

Abb. 7: Beispiel der XML-Baumstruktur

Abb. 8: Arbeitsweise von PHP und (X)HTML

Abb. 9: Das Phasenmodell der Systementwicklung

Abb. 10: Beispiel eines Wasserfallmodells

Abb. 11: Auszug der Projektdurchführungsstrategien des V-Modells

Abb. 12: Content, die Trennung von Struktur, Darstellung und Inhalt

Abb. 13: Inhaltsbausteine eines Contents von Spiegel-Online

Abb. 14: Gestaltungsprinzipien und Prozesse des Content Managements

Abb. 15: Der Content Lebenszyklus

Abb. 16: Trennung von Inhalt, Struktur und Darstellung

Abb. 17: Bausteine des Knowledge Management

Abb. 18: Aufbau von WCMS

Abb. 19: Komponenten von WCMS

Abb. 20: Komponenten von ECMS

Abb. 21: Anwendungsschwerpunkte von ECMS

Abb. 22: Phase Projektbegründung der Einführung eines CMS

Abb. 23: Analysephase der Einführung eines CMS

Abb. 24: Auswahl- und Anschaffungsphase der Einführung eines CMS

Abb. 25: Bewertung von CMS

Abb. 26: Vergleich der CMS Joomla!, Redaxo und Typo3

Abb. 27: Realisierungsphase der Einführung eines CMS

Abb. 28: Einführungsphase der Einführung eines CMS

Abb. 29: Die alte Webseite des IWI

Abb. 30: Das Frontend der neuen Webseite des IWI

Abb. 31: ERM als Basis der Individualprogrammierungen für das IWI

Abb. 32: Eingabeformular zum Anlegen neuer Lehrveranstaltungen

Abb. 33: Eingabeformular zum Anlegen neuer Publikationen

Tabellenverzeichnis

Tab. 1: Abgrenzung von OSS und anderen Softwarearten

Tab. 2: Vor- und Nachteile von Open Source Software

Tab. 3: Erhebungs- und Darstellungstechniken

Tab. 4: Mögliche Fragestellungen zur Durchführung einer Ist-Analyse

Tab. 5: Anforderungen an CMS

Tab. 6: Beispiel für ein Kriterienraster zur Bewertung von CMS

Tab. 7: Ergebnis der Grobbewertung von WCMS

Anhangsverzeichnis

Anhang 1: Tabellenstruktur der relationalen Datenbank

Anhang 2: Quelltext des Skriptes lehre.php

Anhang 3: Quelltext des Skriptes lehre_aktuell.php

Anhang 4: Quelltext des Skriptes auswahl.php

Anhang 5: Quelltext des Skriptes verarbeiten.php

Anhang 6: Quelltext des Skriptes publikationen.php

Anhang 7: Quelltext des Skriptes publikationen_nach_mitarbeiter.php

Anhang 8: Quelltext des Skriptes delete_publikationen.php

Anhang 9: Quelltext des Skriptes bibtex.php

Anhang 10: Quelltext für das verwendete Template des IWI

Anhang 11: Projektzeitplan

Anhang 12: Joomla! Schulungskonzept

Anhang 13: Joomla!-Handout zur Mitarbeiterschulung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Motivation und Ziel der Arbeit

(CR & JS) Für das Jahr 2007 kann, ausgehend von den Ergebnissen einer Studie der University of California aus dem Jahre 2003, weltweit mit 18,5 Exabyte an neuen Informationen auf Film, Printmedien sowie magnetischen und optischen Speichermedien gerechnet werden.^[1] Das effiziente Management dieser Informationen, insbesondere deren kunden- und qualitätsorientierte Publikation auf Webseiten oder im Intranet, stellt Unternehmen zunehmend vor große Herausforderungen.

Während in den Anfangszeiten der Internetnutzung Webseiten größtenteils ein Medium zur statischen Präsentation von Informationen waren, erwarten die verschiedenen Anspruchsgruppen von Unternehmen heutzutage aktuelle, dynamische und personalisierte Intra- und Internetauftritte.^[2] In Kombination mit dem exponentiellen Informationswachstum^[3] gestaltet sich deren manuelle Pflege und Verwaltung durch einen Webmaster als zunehmend unpraktikabel.^[4] Ein in diesem Zusammenhang häufig genanntes Beispiel ist die Webseite der Firma ZDNET^[5], die im Jahre 1999 aus 50.000 einzelnen Seiten bestand. Ein Jahr später waren es bereits 240.000 Seiten, bestehend aus über 2 Millionen Elementen, die manuell verwaltet werden mussten.^[6]

Content Management Systeme (CMS) können eingesetzt werden, um diese Probleme bereits im Vorfeld zu vermeiden. Mit ihrer Hilfe kann die Verwaltung von Informationen automatisiert, effizienter gestaltet und aus Sicht der Anspruchsgruppen mit einem nutzenstiftenden Mehrwert im Form von Personalisierung und Aktualität versehen werden.

Die Auswahl eines sinnvollen CMS ist allerdings nicht einfach und hängt von vielen Faktoren ab. Unternehmen, die sich für den Einsatz eines CMS entscheiden, sehen sich allein auf dem deutschen Markt mehreren hundert verschiedenen Produkten gegenüber, sodass der Auswahlprozess durchaus mit Schwierigkeiten verbunden sein kann.^[7] Neben den unterschiedlichen Bezeichnungen der Systeme tragen auch die Hersteller zur Verwirrung bei, die aufgrund hart umkämpfter Marktanteile oft Differenzierungsstrategien zur Produktabgrenzung verfolgen.

In den meisten großen Unternehmen ist die effiziente Nutzung und Bereitstellung von Informationen mithilfe von CMS ein wichtiger Bestandteil der E-Business Strategie. Bei kleinen und mittelständischen Unternehmen hingegen besteht in dieser Hinsicht häufig noch Nachholbedarf, wie aus Abb. 1 ersichtlich wird.^[8]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 : Nutzung von Internet und E-Business in kleinen und mittelständischen Unternehmen

Quelle: Eigene Darstellung in Anlehnung an impulse/IBM (2006), S. 8.

Vor diesem Hintergrund sollen in der vorliegenden Arbeit CMS aus Sicht kleiner und mittelständischer Unternehmen betrachtet werden sowie die mit deren Einsatz verbundenen Anforderungen analysiert werden. Ziel der Arbeit ist es, kleine und mittelständische Unternehmen für die Notwendigkeit des Content Managements und die Potenziale des Einsatzes von CMS zu sensibilisieren, die Möglichkeiten und Vorteile moderner Systeme aufzuzeigen sowie den Einführungs- und Auswahlprozess von CMS zu unterstützen. Dazu werden folgende Fragestellungen in den Mittelpunkt der Untersuchung gestellt:

Was ist Content, warum ist es sinnvoll Content zu managen und welche Werkzeuge können dazu eingesetzt werden?

Welche Schritte sollten bei der Einführung eines CMS in kleinen und mittelständischen Unternehmen beachtet werden? Wie kann der Einführungsprozess beherrschbar gemacht werden?

1.2 Aufbau der Arbeit

(JS) Die vorliegende Arbeit ist in sechs Kapitel unterteilt und wurde zusammen von Christoffer Riemer und Jan Schwenke geschrieben. Zur Kennzeichnung der Autoren wird am Anfang jedes Abschnittes ein Namenskürzel eingefügt. Das Kürzel (CR) kennzeichnet die von Christoffer Riemer geschriebenen Abschnitte. Abschnitte, die mit dem Kürzel (JS) beginnen, wurden von Jan Schwenke verfasst. Die Einleitung und das Fazit wurden zusammen erstellt.

Nach der Darstellung der Motivation für das Thema, der Zielsetzung und des Aufbaus der Arbeit im ersten Kapitel werden in Kapitel zwei die begrifflichen Grundlagen zum Verständnis der Arbeit erläutert. Dazu zählen die Abgrenzung des Begriffs der kleinen und mittelständischen Unternehmen (Abschnitt 2.1), die Darstellung wichtiger Merkmale von Open Source Software unter der Berücksichtigung von Vor- und Nachteilen (Abschnitt 2.2) sowie die Beleuchtung wichtiger Webtechnologien und -standards im Zusammenhang mit CMS (Abschnitt 2.3). Weiterhin wird in Abschnitt 2.4 ausführlich auf das zur Einführung eines CMS genutzte Vorgehensmodell eingegangen.

Im dritten Kapitel der Arbeit wird der Begriff des Contents dargestellt (Abschnitt 3.1) und daraus das der Arbeit zugrunde liegende Content-Verständnis abgeleitet. Die Notwendigkeit des Content Managements wird aufgezeigt und es wird auf wichtige Rahmenbedingungen und Prozesse eingegangen (Abschnitt 3.2). Abschnitt 3.3 stellt die unterschiedlichen Klassen von CMS sowie deren Vor- und Nachteile dar. Daran anschließend werden kritische Erfolgsfaktoren von CMS beleuchtet (Abschnitt 3.4) sowie Open Source CMS und kommerzielle CMS anhand möglicher Vergleichskriterien untersucht (Abschnitt 3.5).

Das vierte Kapitel beinhaltet die Konzeption eines Leitfadens zur Einführung eines CMS in kleinen und mittelständischen Unternehmen, der zur Komplexitätsreduktion während des Einführungsprozesses beitragen und Einführungsbarrieren herabsetzen kann. Dazu werden mithilfe eines Vorgehensmodells mögliche Schritte in den Phasen Projektbegründung (Abschnitt 4.1), Analyse (Abschnitt 4.2), Auswahl und Anschaffung (Abschnitt 4.3), Realisierung (Abschnitt 4.4) und Einführung (Abschnitt 4.5) eines CMS erarbeitet.

Auf den Ergebnissen des vierten Kapitels aufbauend werden im fünften Kapitel relevante Schritte bei der Einführung eines CMS zum Relaunch der Webseite des Instituts für Wirtschaftsinformatik der Leibniz Universität Hannover dargestellt. Zu den Schritten zählen die Projekt-Vorphase (Abschnitt 5.1), die Analyse und Bewertung der alten Webseite (Abschnitt 5.2), die Aufstellung eines Soll-Konzeptes für das einzuführende CMS (Abschnitt 5.3), die Auswahl eines Systems (Abschnitt 5.4) sowie dessen Installation, Anpassung und Einführung (Abschnitte 5.5 und 5.6).

Den Abschluss der vorliegenden Arbeit bildet Kapitel sechs, das die Ergebnisse zusammenfasst und einen Ausblick auf zukünftige Entwicklungstendenzen im Bereich der CMS gibt.

2 Grundlagen

2.1 Kleine und mittelständische Unternehmen

(JS) Da der Begriff der kleinen und mittelständischen Unternehmen in der Literatur nicht einheitlich definiert ist, werden nachfolgend verschiedene Definitionsansätze dargestellt.

Nach der Definitionsempfehlung der Europäischen Kommission beschäftigen kleine und mittelständische Unternehmen weniger als 250 Mitarbeiter und erwirtschaften einen jährlichen Umsatz von höchstens 50 Millionen Euro beziehungsweise eine Jahresbilanzsumme von nicht mehr als 43 Millionen Euro.^[9] Das Institut für Mittelstandsforschung hingegen definiert kleine und mittelständische Unternehmen als Unternehmen, die weniger als 500 Mitarbeiter beschäftigen und weniger als 50 Millionen Euro umsetzen. Die Kreditanstalt für Wiederaufbau wiederum ordnet ein Unternehmen in diesen Sektor ein, wenn es einen Umsatz von bis zu 500 Millionen Euro erzielt.^[10]

Insbesondere in Deutschland stellen kleine und mittelständische Unternehmen einen entscheidenden volkswirtschaftlichen Faktor dar. Je nach Definitionsansatz zählen bis zu 99,8% aller deutschen Unternehmen zum Klein- und Mittelstand.^[11] Sie beschäftigen 23,4 Millionen Arbeitnehmer, hauptsächlich in der Dienstleistungsbranche, dem Baugewerbe und dem verarbeitenden Gewerbe und erwirtschaften einen Anteil von über 50% der deutschen Bruttowertschöpfung.^[12] Vor diesem Hintergrund ist es nicht verwunderlich, dass der Mittelstand oft als die tragende Säule der deutschen Wirtschaft bezeichnet wird.^[13]

2.2 Open Source Software

(JS) Eine aktuelle Studie der Europäischen Kommission aus dem Jahre 2006 unter der Leitung der Universität Maastricht kommt zu dem Ergebnis, dass Open Source Software (OSS) ein relevanter Wirtschaftsfaktor ist. Gemäß der Studie müssten Unternehmen ca. 12 Milliarden Euro oder umgerechnet 131.000 Jahre Programmierarbeit investieren, um die aktuell existierenden qualitativ hochwertigen Open Source Anwendungen selbst zu programmieren sowie eine angemessene Qualitätskontrolle und Distribution sicherzustellen.^[14] OSS ist mittlerweile eine bedeutende Alternative zu kommerziellen Softwareprodukten und wird von immer mehr mittelständischen Unternehmen eingesetzt.^[15] Neben Anwendungen im Back-Office-Bereich als Betriebssystem, Webserver, Sicherheitssoftware oder Office-Anwendung, gewinnt OSS auch im Bereich des Content Managements zunehmend an Bedeutung.^[16] Auf dem Markt für CMS macht sich diese Entwicklung durch eine steigende Anzahl von Open Source CMS bemerkbar.^[17]

Zum besseren Verständnis des Gedankens hinter der Open Source Bewegung und zur Würdigung der Rolle von OSS auf dem Markt für CMS werden im Folgenden die wesentlichen Eigenschaften sowie die Vor- und Nachteile von OSS dargestellt.

2.2.1 Definition und Begriffsabgrenzung

(JS) Der englische Begriff „Open Source“ kann mit „quelloffen“ übersetzt werden und wird auf Software angewendet, deren Quelltext frei zugängig ist. OSS unterscheidet sich damit von proprietärer Software^[18], deren Quelltext nicht frei zugängig ist (closed source).

Die Grundidee hinter der Open Source Bewegung ist die gemeinschaftliche und selbstorganisierte Entwicklung von Software auf freiwilliger Basis. Durch die Vielzahl der Entwickler sowie durch deren Engagement und Motivation bei der Entwicklungsarbeit wird eine qualitativ hochwertige, flexible und herstellerunabhängige Softwareentwicklung angestrebt.^[19] Die Basis für die Open Source Bewegung wurde im Jahre 1984 gelegt, als Richard Stallman das GNU Projekt^[20] gründete, um ein freies, unixartiges Betriebssystem zu entwickeln.^[21] Der Begriff OSS trat allerdings erstmalig im Jahre 1998 auf und wird von der Open Source Initiative^[22] anhand folgender wesentlicher Kriterien definiert:^[23]

- OSS darf an beliebige Dritte weitergegeben werden. Der Autor behält zwar die Urheberrechte an der Software, hat jedoch keine Möglichkeit, die entgeltliche oder unentgeltliche Weitergabe zu verhindern oder einzuschränken.
- Der Quelltext der OSS muss frei zugängig sein, offen gelegt werden und sollte der Software beiliegen. Ist dies nicht der Fall, muss der Quelltext in geeigneter Art und Weise zugängig gemacht werden.
- Der Urheber muss Modifikationen an seiner Software erlauben. Die modifizierte Software muss unter den gleichen Bedingungen verbreitet werden können wie das Original. Zur Sicherung der Integrität der originalen Software kann der Urheber verlangen, dass Modifikationen als separater Patch angeboten werden.
- Es darf keine Diskriminierung von Personen oder Benutzergruppen erfolgen. OSS-Lizenzen dürfen somit weder bestimmte Benutzergruppen noch Personen von der Nutzung der OSS ausschließen. Auch der Verwendungszweck und Einsatz der Software darf nicht eingeschränkt werden.

Eine Software, die alle oben genannten Kriterien erfüllt, stellt OSS im Sinne der Open Source Initiative dar; die Erfüllung eines Kriteriums allein reicht hingegen nicht aus. Mithilfe dieser Merkmale, vor allem der Offenlegung des Quelltextes und dem Recht der freien Weitergabe, kann OSS von anderen Softwarearten abgegrenzt werden.^[24] Hierbei sind proprietäre beziehungsweise kommerzielle Software, Shareware, kommerzielle OSS und Freeware zu nennen.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: Abgrenzung von OSS und anderen Softwarearten

Quelle: Eigene Darstellung in Anlehnung an Berlecon Research (2002), S. 11; Kooths/Langenfurth/Kalwey (2003), S. 33.

Proprietäre beziehungsweise kommerzielle Software ist nicht quelloffen sodass Modifikationen nicht möglich sind oder durch den Urheber verboten werden^{[25] [26] [27] [28] [29] [30] [31]}. Die kostenlose Weitergabe ist in der Regel lizenzrechtlich untersagt. Shareware räumt dem Anwender ein zeitlich oder funktional eingeschränktes, kostenloses Nutzungsrecht ein. Nach Ablauf dieses Nutzungszeitraums oder zur Aktivierung des vollen Funktionsumfangs müssen Lizenzgebühren an den Urheber entrichtet werden. Kommerzielle OSS wird zwar gegen ein Entgelt veräußert, aufgrund der OSS-Lizenz können allerdings keine Eigentumsrechte durchgesetzt werden, sodass eine unentgeltliche Redistribution des Produktes möglich ist.^[32] Der Verkauf von OSS ist das Geschäftsmodell von so genannten OSS-Distributoren.^[33] Bei Freeware erteilt der Urheber einer Software dem Anwender ein kostenloses Nutzungs- und Weitergaberecht; der frei verfügbare Quelltext und das Recht zur Modifikation sind dagegen keine zwingend notwendigen Merkmale von Freeware.^[34]

2.2.2 Open Source Software Lizenzen

(JS) OSS ist nicht lizenzfrei und gehört dem Urheber. In einer Vielzahl spezieller Lizenzen werden die rechtlichen Rahmenbedingungen zur Nutzung, Modifikation, Analyse und Weitergabe der Software festgelegt, die der Urheber den Anwendern einräumt.^[35] Im Gegensatz zu Lizenzen für proprietäre Software schützen OSS-Lizenzen nicht überwiegend die Interessen des Urhebers.^[36] Vielmehr ist es ein besonderes Merkmal von OSS-Lizenzen die Rechte des Anwenders zu stärken und ihm über die reine Nutzung hinaus zusätzliche Rechte einzuräumen, wie beispielsweise die Modifikation und Weitergabe der Software.^[37] Aktuell existiert eine ständig wachsende Anzahl unterschiedlicher, von der Open Source Initiative zertifizierter OSS-Lizenzen.^[38] Abb. 3 gibt einen Überblick über die relative Verteilung der Lizenzen im OSS-Projektportal SourceForge.net.^[39]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Verteilung der OSS-Lizenzen bei SourceForge

Quelle: Eigene Darstellung in Anlehnung an SourceForge (2007), S. 2.

Zu den wichtigsten Lizenzen zählen die GNU General Public License^[40] (GPL), die Lesser GNU General Public License^[41] (LGPL) und die Berkeley Software Distribution License^[42] (BSD). Das wesentliche Unterscheidungsmerkmal der Lizenzen ist das Copyleft^[43]. Unter dem Begriff Copyleft versteht man die Art und Weise, wie bei Modifikationen des Quelltextes von OSS sowie dessen Kombination mit proprietärer und kommerzieller Software vorzugehen ist.^[44]

Die GPL wurde als Grundlage für das GNU Projekt von Richard Stallman entworfen und erfüllt alle wesentlichen Kriterien für OSS^[45]. Darüber hinaus enthält sie weitere wichtige Klauseln bezüglich des Copylefts. Derivate, also Programme, die Quelltextbestandteile GPL-lizenzierter OSS enthalten und die zur Weitergabe bestimmt sind, müssen als Gesamtprodukt wiederum der GPL unterliegen.^[46] Der Quelltext von GPL-lizenzierter Software darf somit nicht in proprietärer (closed source) zum Verkauf bestimmter Software verwendet werden. Wenn die Derivate nicht für die kommerzielle Weiterverbreitung bestimmt sind, sondern unternehmensintern verwendet werden sollen, so besteht die Möglichkeit Quelltextbestandteile aus GPL-lizenzierter Software mit proprietärer Software zu kombinieren und Modifikationen vorzunehmen. Für den Quelltext des Gesamtproduktes besteht in diesem Fall kein Veröffentlichungszwang.^[47]

Eine abgeschwächte Version der GPL ist die LGPL. Sie ermöglicht die Verwendung LGPL-lizenzierter OSS-Bestandteile in proprietären Softwareprodukten. Wird ein der LGPL unterliegender OSS-Bestandteil verändert, muss die modifizierte Version des Bestandteils wiederum der LGPL unterliegen sofern sie zur Weiterverbreitung bestimmt ist.^[48]

Die BSD Lizenz, ursprünglich von der University of California entwickelt, ist im Vergleich zur GPL oder LGPL weitaus liberaler formuliert und sieht einen Offenlegungszwang des Quelltextes nicht vor.^[49] BSD-lizenzierte Softwareprodukte dürfen in jeder Form, auch in Binärform, weitergegeben werden und ihre Bestandteile dürfen in kommerzieller Software verwendet werden. Modifikationen und modifizierte BSD-Bestandteile müssen nicht zwingend wieder der BSD Lizenz unterliegen.^[50]

2.2.3 Vor- und Nachteile von Open Source Software

(JS) Der Einsatz von OSS in Unternehmen ist mit verschiedenen Vor- und Nachteilen verbunden, die von IT-Entscheidungsträgern berücksichtigt werden sollten. Tab. 2 stellt mögliche Vor- und Nachteile in einer Übersicht dar:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2: Vor- und Nachteile von Open Source Software

Quelle: Eigene Darstellung in Anlehnung an Renner et al. (2005), S. 19.

2.2.3.1 Vorteile von Open Source Software

(JS) Im Gegensatz zu kommerzieller Software fallen für die Nutzung von OSS, unabhängig von der Anzahl der genutzten Installationen, keine Lizenzgebühren an. Obwohl dieses Merkmal von der Mehrheit der Anwender als wichtigster Vorteil angesehen wird, wie aus Abb. 3 ersichtlich wird, sind zur Beurteilung der langfristigen Wirtschaftlichkeit von OSS über die Lizenzgebühren hinaus die Total Cost of Ownership (TCO) zu beachten.^[51] Unter den TCO versteht man die Berücksichtigung aller Kosten, die in Zusammenhang mit der Anschaffung und dem Betrieb einer IT-Komponente stehen. Dazu zählen auch Benutzerbetreuung und Wartung. Durch die Einbeziehung der Gesamtkosten und des Gesamtnutzens über die Nutzungsdauer hinweg wird es ermöglicht, verschiedene Softwareprodukte besser zu vergleichen und eine realistische Einschätzung der Wirtschaftlichkeit zu treffen.^[52]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3 : Wahrnehmung der Vorteile von OSS aus Sicht der Anwender

Quelle: Eigene Darstellung in Anlehnung an Pols et al. (2004), S. 55.

Der offene Quelltext und die in den OSS-Lizenzen verankerten Rechte zur Modifikation und Erweiterung erlauben eine einfache Anpassung der Software an die individuellen Bedürfnisse von Unternehmen. Aufbauend auf den Basisfunktionen der Software können so unternehmensinterne Anpassungen, beispielsweise an spezielle Geschäftsprozesse oder Arbeitsabläufe, vorgenommen werden. Die verwendeten offenen Standards in Form von Dateiformaten, Schnittstellen und Programmiersprachen ermöglichen eine hohe Kompatibilität mit anderer Software.^[53]

Ein weiterer wichtiger Vorteil von OSS ist das von Eric Raymond geprägte „peer-review“-Prinzip^[54]. Demzufolge wird bei der Entwicklung von OSS ein spezielles Vorgehensmodell eingesetzt, das von ihm als „bazaar-style“ bezeichnet wird. Kennzeichnend dafür ist, dass der offene Quelltext der OSS von einer Vielzahl von Experten begutachtet, analysiert und kontinuierlich weiterentwickelt wird. Fehler und Sicherheitslücken können somit schneller erkannt und beseitigt werden als bei klassischer Softwareentwicklung, sodass OSS häufig eine hohe Qualität zugesprochen wird.^[55]

Ferner unterliegt OSS, im Unterschied zu kommerzieller Software, keinen Marktzwängen; insbesondere gibt es keine festen Veröffentlichungstermine, sodass sich auch der fehlende Termindruck während der Entwicklung positiv auf die Qualität der Software auswirken kann.^[56]

Die Wiederverwendbarkeit von Quelltextbestandteilen und Komponenten von OSS bei Softwareentwicklungen und -modifikationen ermöglicht die Einsparung von Entwicklungszeiten, da bewährte Komponenten nicht jedes Mal neu programmiert werden müssen. Die Analyse des Quelltextes erlaubt es weiterhin, bereits vorhandene Problemlösungen nachzuvollziehen und daraus zu lernen. Es werden somit Lernprozesse angeregt und ein Know-how-Transfer zwischen den Entwicklern findet statt.^[57]

Im Gegensatz zu kommerzieller Software zwingt OSS die Anwender nicht in ein Abhängigkeitsverhältnis zu einem Hersteller. Insbesondere bei häufigen Releasewechseln, ungünstiger Lizenzpolitik, Weiterentwicklungseinstellung oder drohender Insolvenz eines Herstellers können bei hoher Abhängigkeit erhebliche Kosten für Anwender entstehen. Anwender von OSS sind relativ herstellerunabhängig, da die erweiterten Nutzungsrechte die eigene Weiterentwicklung der Software erlauben.^[58]

2.2.3.2 Nachteile von Open Source Software

(JS) Anwender von OSS können in der Regel keine Gewährleistungs- und Haftungsansprüche gegen die Entwicklergemeinde geltend machen. Weiterhin wird auch keine Garantie für die Funktionstüchtigkeit und die Verfügbarkeit der Software übernommen, was insbesondere bei unternehmenskritischen Anwendungen problematisch sein kann.^[59]

In vielen Bereichen hat kommerzielle Software noch einen relativ hohen Marktanteil, so dass die Anwender mit der Bedienung dieser Programme vertraut sind. Wenn die Entscheidung für den Einsatz von OSS fällt, muss entsprechendes Know-how im Unternehmen aufgebaut oder extern auf dem Markt eingekauft werden. Es kann daher von einem erhöhten Schulungsaufwand im Vergleich zu kommerzieller Software ausgegangen werden, wenn OSS im Unternehmen eingeführt wird.^[60]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4 : Wahrnehmung der Nachteile von OSS aus Sicht der Anwender

Quelle: Eigene Darstellung in Anlehnung an Pols et al. (2004), S. 56.

Da die Entwickler von OSS keinen Verpflichtungen zur Pflege und Weiterentwicklung ihrer Software unterliegen, kann es vorkommen, dass die Arbeit an Projekten eingestellt wird. Insbesondere kleinere Open Source Projekte haben häufig Schwierigkeiten, eine kompetente Entwicklergemeinde zur langfristigen Mitarbeit zu motivieren.^[61]

Weiterhin wird häufig der fehlende professionelle Support für OSS seitens der Entwickler als Nachteil angeführt. Da allerdings immer mehr professionelle Dienstleister für OSS in diesem Bereich tätig werden, ist dieser Nachteil zu relativieren.^[62]

Weitere Nachteile, die mit dem Einsatz von OSS verbunden sein können, liegen in der Verfügbarkeit OSS-kompatibler Applikationen sowie in der eingeschränkten Interoperabilität von OSS mit kommerzieller Software. Ursächlich dafür sind häufig das fehlende Interesse von Herstellern kommerzieller Software an einer Kompatibilität und Interoperabilität ihrer Produkte mit OSS, der Einsatz proprietärer Dateiformate oder die Verwendung von nicht offen gelegten Schnittstellen.^[63]

2.2.4 Open Source Geschäftsmodelle

(JS) Der Verkauf von OSS ist zwar nicht untersagt, gestaltet sich aber durch die lizenzrechtlich festgelegte Möglichkeit der freien Weitergabe als schwierig umsetzbar.

Dennoch haben sich verschiedene OSS-Geschäftsmodelle entwickelt, die OSS als Grundlage für kostenpflichtige Dienstleistungen und Zusatzprodukte nutzen.^[64] Die Geschäftsmodelle können grob in die Kategorien Produkt-, Dienstleistungs- und Mediator-Geschäftsmodelle eingeteilt werden.^[65] In der Regel treten die Geschäftsmodelle allerdings nicht isoliert auf sondern als Mischformen und Überschneidungen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Open Source Geschäftsmodelle

Quelle: Eigene Darstellung in Anlehnung an Leiteritz (2004), S. 141 – 157.

OSS-Produkt-Geschäftsmodelle umfassen die Bereiche der Distributoren, der Applikationsanbieter und der Appliance-Hersteller. Distributoren wählen OSS-Komponenten aus und stellen diese auf Datenträgern zusammen. Durch die Programmierung von zusätzlichen Installations- und Administrationsroutinen werden die einzelnen Komponenten als Gesamtprodukt nutzbar.^[66] Das Geschäftsmodell der Distributoren besteht aus den Bereichen Zusammenstellung, Abstimmung, Test, Optimierung und Dokumentation von OSS-Komponenten sowie aus der Vermarktung und dem Vertrieb der Komplettprodukte.^[67]

Im Bereich der OSS-Applikationsanbieter können drei Fälle unterschieden werden:^[68] Im ersten Fall wird der Quelltext einer ehemals proprietär entwickelten Software vom Urheber freigegeben und von der Open Source Bewegung unter einer OSS-Lizenz weiterentwickelt. Die zweite Möglichkeit ist, dass ein Unternehmen eine ehemals kommerzielle Software ab einem bestimmten Zeitpunkt unter einer OSS-Lizenz weiterentwickelt. Der dritte Fall ist, wenn eine bereits existierende OSS ab einem bestimmten Zeitpunkt kommerziell von einem Unternehmen betreut wird. Mögliche Geschäftsmodelle von Applikationsanbietern sind der Verkauf komplementärer kommerzieller Softwarekomponenten zur Erweiterung der Funktionalitäten von OSS sowie der Vertrieb von OSS unter verschiedenen Lizenzmodellen, Versionen und Leistungsumfängen.^[69]

Appliances sind Gerätekombinationen aus Hardware, Software und Betriebssystemen. Appliance-Hersteller passen OSS an bestimmte Hardwareplattformen und Anforderungen an und entwickeln eigene Software für Benutzerschnittstellen. Erlöse werden durch den Verkauf der Appliances sowie durch den Abschluss von Service- und Supportverträgen generiert.^[70]

Unternehmen mit Dienstleistungs-Geschäftsmodellen bieten Dienstleistungen rund um bereits existierende OSS an. Geschäftsfelder sind die Bereiche Beratung, Analyse, Konzeption, Integration, Administration, Sicherheit, Implementierung, Support, Wartung und Schulung von und für OSS.^[71]

Das Geschäftsmodell der OSS-Mediatoren beinhaltet die Bereitstellung eines elektronischen Marktplatzes zur Kommunikation zwischen den verschiedenen Interessensgruppen auf dem OSS-Markt. Mögliche Interessensgruppen sind beispielsweise Entwickler, Dienstleister und Anwender von OSS. Erlöse werden hauptsächlich durch Online-Werbung^[72] und den Vertrieb weiterführender, kommerzieller Produkte wie Bücher oder Datenträger erzielt.^[73]

2.3 Webtechnologien und -standards

(JS) Moderne CMS basieren auf vom World Wide Web-Consortium^[74] (W3C) standardisierten Webtechnologien wie XML^[75], HTML^[76], XHTML^[77], CSS^[78], PHP^[79], Java und Javascript.^[80] Die Einhaltung dieser Standards ermöglicht die Erstellung von barrierefreien und im Sinne des W3C validen Webseiten sowie den Einsatz der CMS auf unterschiedlichen Hard- und Softwareplattformen. Im Folgenden soll eine ausführliche Darstellung dieser Webtechnologien erfolgen.

2.3.1 SGML – Standard Generalized Markup Language und XML – Extensible Markup Language

(CR) Die Standard Generalized Markup Language SGML wurde 1986 von der International Standardization Organization (ISO) als ISO 8879 veröffentlicht. SGML ist eine Metasprache^[81], die beschreibt, wie in einem Dokument die Struktur des Inhalts von seiner Darstellungsform getrennt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Zusammenhang von SGML, XML, HTML und CSS

Quelle: Eigene Darstellung in Anlehnung an Behme/Mintert (2000), S. 3.

Aufgrund der hohen Komplexität und des Umfangs von SGML wurde 1996 die Extensible Markup Language (XML) als eingeschränkte Form der SGML veröffentlicht.^[82] XML wurde von einer XML-Arbeitsgruppe unter Schirmherrschaft des W3C entwickelt^[83] und bedeutet erweiterbare Auszeichnungssprache. Folgende Ziele helfen XML zu verstehen:^[84]

- XML soll sich im Internet auf einfache Weise nutzen lassen.
- XML soll ein breites Spektrum von Anwendungen unterstützen.
- XML soll zu SGML kompatibel sein.
- Es soll einfach sein Programme zu schreiben, die XML-Dokumente verarbeiten.
- XML-Dokumente sollten für Menschen lesbar und angemessen verständlich sein.
- Der XML-Entwurf sollte zügig abgefasst sein.
- Der Entwurf von XML soll formal und präzise sein.
- XML-Dokumente sollen leicht zu erstellen sein.

XML ist ein Standard zur Modellierung von Daten in Form einer Baumstruktur, wie in Abb. 7 veranschaulicht. Er definiert Regeln für den Aufbau von Dokumenten. Somit ist XML eine Metasprache, die es ermöglicht, Auszeichnungssprachen - wie z. B. XHTML - zu erzeugen. Ein XML-Dokument enthält Entitäten^[85] und eine Dokumenttypdefinition^[86], um Entitäten und den Aufbau des Dokuments zu spezifizieren. Außerdem verfügt es über eine XML-Deklaration, die Versionsangaben sowie Zeichenkodierungs- und Verarbeitungsanweisungen ohne Dokumenttypdefinition enthält.^[87]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 7 : Beispiel der XML-Baumstruktur

Quelle: Eigene Darstellung in Anlehnung an Rottmann/Riedl (2002), S. 7.

Inhalte werden durch Auszeichnungselemente definiert, die durch spitze Klammern gekennzeichnet sind, z. B.: <institut>. Im Gegensatz zu HTML sind bei XML die Auszeichnungselemente nicht festgelegt sondern können frei gewählt werden. Die Gesamtheit der Auszeichnungselemente wird als Markup bezeichnet.^[88]

2.3.2 (X)HTML – (Extensible) HyperText Markup Language

(JS) HTML ist eine standardisierte Auszeichnungssprache zur Definition und Strukturierung des Erscheinungsbildes von Textdokumenten für das World Wide Web. Mit HTML können die Elemente von Textdokumenten, wie Überschriften, Listen oder Tabellen, als solche ausgezeichnet werden. Inhalt, Auszeichnungen und Formatierungsangaben werden im Quelltext von HTML-Dokumenten gespeichert und können plattformunabhängig durch einen Web-Browser interpretiert werden.^[89]

Die Entwicklung von HTML begann in den frühen 90er Jahren des 20. Jahrhunderts im europäischen Hochenergieforschungszentrum CERN in Genf und wurde do0rt von Tim Berners-Lee vorangetrieben.^[90] Die letzte Version von HTML, die Version 4.01, wurde im Jahre 1999 veröffentlicht. Im Anschluss daran wurde mit der Arbeit an XHTML begonnen, die eine Anpassung an moderne Standards wie XML darstellt. Aktuell liegt XHTML in der Version 1.1 vor. Bei der Erstellung von XHTML-validen Dokumenten müssen strengere syntaktische Regeln eingehalten werden als bei HTML: Die Elemente müssen korrekt verschachtelt sein und es darf zu keinen Überschneidungen kommen. Die Element- und Attributnamen von XHTML müssen stets klein geschrieben werden. Weiterhin ist es für die Validität der Dokumente relevant, dass sowohl Elemente mit Inhalt als auch leere Elemente immer korrekt geschlossen werden und Attributswerte stets in Anführungszeichen stehen und ausgeschrieben werden.^[91]

Webseiten, die ausschließlich auf (X)HTML basieren, haben einen statischen Charakter. Zur Steigerung von Interaktivität und Dynamik bietet sich aus diesem Grund die Kombination von (X)HTML mit PHP oder Javascript an, worauf in den folgenden Abschnitten eingegangen wird.

2.3.3 PHP – Hypertext Preprocessor

(JS) PHP ist eine serverseitig interpretierte Skriptsprache zur Erstellung dynamischer Webseiten. Die erste Version wurde 1994 von Rasmus Lerdorf entwickelt. 1997 wurde sein Projekt von der Open Source Gemeinde aufgenommen und wird seitdem kontinuierlich weiterentwickelt. Bis zur Version 3.0 wurde PHP unter der GPL lizenziert. Seit der Version 4.0 wird PHP unter einer speziellen PHP-Lizenz^[92] verbreitet, welche die freie Verwendung und Modifikation des Quelltextes erlaubt. Ansätze objektorientierter Programmierung werden seit der Version 4.0 unterstützt. Aktuell befindet sich PHP in der Version 5.20 mit deutlich erweiterten Möglichkeiten objektorientierter Programmierung.^[93] Die Arbeitsweise von PHP kann anhand nachstehender Abbildung verdeutlicht werden:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 8: Arbeitsweise von PHP und (X)HTML

Quelle: Eigene Darstellung in Anlehnung an Krause (2005), S. 35 – 36; RRZN/Universität Hannover (2005), S. 5.

Über den Webbrowser kann der Benutzer eine Anfrage an einen Webserver senden, die ein PHP-Skript oder eine (X)HTML-Seite aufruft. In letzterem Fall wird die angeforderte (X)HTML-Seite vom Webserver direkt an den Browser weitergeleitet. Bei Aufruf eines PHP-Skripts hingegen wird der entsprechende Programmcode durch den PHP-Interpreter auf dem Webserver ausgeführt. Bei Bedarf können auch Datenbankabfragen in das PHP-Skript eingebunden werden. Die Programmergebnisse werden vom PHP-Interpreter an den Webserver übermittelt, der sie als reinen (X)HTML-Quelltext an den Browser des Benutzers zurücksendet.^[94] Diese Arbeitsweise hat den Vorteil, dass PHP-Skripte hardware- und plattformunabhängig von jedem HTML-fähigen Browser aufgerufen werden können, da das Verarbeiten des Skriptes auf dem Webserver stattfindet.^[95]

PHP-Quelltext lässt sich problemlos in einen (X)HTML-Quelltext einbinden. Durch die Möglichkeit, mit PHP auf Dateien schreibend und lesend zuzugreifen, Datenbankabfragen auszuführen sowie dynamisch auf Benutzereingaben zu reagieren, können interaktive und personalisierte Webseiten programmiert werden, die nur mit (X)HTML nicht realisierbar wären.^[96]

2.3.4 CSS – Cascading Stylesheets

(JS) Bei CSS handelt es sich um eine Formatierungssprache für strukturierte Dokumente. Sie wird vor allem in Kombination mit (X)HTML oder XML eingesetzt und ermöglicht die Trennung der Struktur sowie des Inhalts eines Dokuments von den Darstellungs- und Formatierungsinformationen. Mithilfe von CSS können einzelne (X)HTML-Elemente beliebig formatiert und positioniert werden.^[97] Die Formatierungsangaben, auch als Stylesheets bezeichnet, können sich auf ein einzelnes (X)HTML-Dokument beziehen oder in eine externe Datei ausgelagert werden und somit zentral in alle gewünschten (X)HTML-Dokumente eingebunden werden.^[98] Die Möglichkeit, Stylesheets in einer externen Datei festzulegen und so die Formatierungen einer Webseite zentral zu steuern, ist bei konsequenter Einhaltung eine große Hilfe bei der Realisierung und Pflege eines konsistenten Layouts.^[99]

Problematisch ist allerdings, dass bestimmte Stylesheets von unterschiedlichen Browsern oder Browserversionen verschieden interpretiert und dargestellt werden können.^[100] Beim Einsatz von CSS auf Webseiten sollte daher stets darauf geachtet werden, dass diese keine Zugangsbarriere für Benutzer mit älteren Browsern oder deaktiviertem CSS darstellen.^[101]

2.3.5 Java und Javascript

(CR) Java ist eine objektorientierte Programmiersprache, die es ermöglichen soll, Quelltext aus entfernten Quellen sicher auszuführen. Programme werden plattformunabhängig durch die zu installierende Java Virtual Machine ausgeführt, welche den Quelltext interpretiert.^[102]

Die Urversion von Java - auch Oak genannt - wurde in den Jahren 1991/1992 von Sun Microsystems entwickelt und sollte ursprünglich der Steuerung von Elektrogeräten dienen. Den Durchbruch erzielten die Entwickler von Java im Jahre 1995 durch die Integration in den Browser Netscape Navigator.^[103]

JavaScript ist von Java trotzt des ähnlichen Namens grundlegend verschieden. Es handelt sich bei JavaScript um eine objektorientierte Skriptsprache, die von Sun Microsystems und Netscape entwickelt wurde. Sie wird vom Browser interpretiert, sofern dieser JavaScript unterstützt.^[104] JavaScript ist nicht direkt in (X)HTML enthalten und somit eine eigenständige Programmiersprache.^[105] Im Quelltext einer Webseite können (X)HTML-Elementen Funktionen zugeordnet werden. JavaScript ist nicht zu der von Microsoft entwickelten Skriptsprache JScript^[106] kompatibel.

Da der Browser die Sprache interpretiert wird der Server entlastet und ein erneutes Laden der Seite vermieden. So kann JavaScript beispielsweise den Inhalt oder das Aussehen einer Seite verändern. JavaScript kann nach dem Laden und Darstellen einer Seite auf alle Elemente zugreifen, diese verändern und neue erzeugen. Dieses wird als Dynamic HTML bezeichnet. Typische Anwendungsgebiete sind Plausibilitätsprüfungen von Formulareingaben vor dem Absenden, Umgang mit Frames, Veränderung von Grafiken, Banner und Laufschriften sowie der Einsatz von Ajax-Technologie^[107]. Doch auch Skripte, die den Aufbau einer Seite verschleiern oder andere vom Benutzer unerwünschte Funktionen ausführen, können mit JavaScript realisiert werden.^[108]

2.4 Vorgehensmodelle zur Systementwicklung und -implementation

(CR) „Allgemein beschreibt jedes Vorgehensmodell die Folge aller Aktivitäten, die zur Durchführung eines Projekts erforderlich sind. Vorgehensmodelle für die Systementwicklung […] geben an, wie die Prinzipien, Methoden, Verfahren und Werkzeuge der System- und Softwareentwicklung einzusetzen sind.“^[109] Durch Vorgehensmodelle soll in der Softwareentwicklung die Komplexität beherrschbar und der Entwicklungsprozess übersichtlicher gestaltet werden. Dieser wird dabei in überschaubare, zeitlich und inhaltlich abgrenzbare Phasen unterteilt. Diese Phasen können einmal durchlaufen werden, wie beispielsweise beim Wasserfallmodell, oder mehrmals, wie es beim Spiralmodell der Fall ist. Man kann zwischen drei Typen von Vorgehensmodellen unterscheiden. Dies sind Softwareentwicklungsprozesse, Software-Lebenszyklusmanagement und Softwareentwicklungs-Philosophie.^[110]

Software-Entwicklungsprozesse sollen die Steuerung einer Softwareentwicklung von der Konzeption bis zum Einsatz ermöglichen. Beim Software-Lebenszyklusmanagement werden die Entwicklungsphasen über den gesamten Lebenszyklus erweitert. Softwareentwicklungs-Philosophien hingegen beschreiben, wie Software am Besten entwickelt werden sollte, beispielsweise extreme Programmierung^[111] und Prototyping^[112].

2.4.1 Phasenmodell der Systementwicklung

(CR) Für viele Vorgehensmodelle bildet das Phasenkonzept der Systemtechnik die Grundlage. Durch die Phaseneinteilung wird die Komplexität eines IT-Projektes reduziert, da es in überschaubare, zeitlich aufeinander folgende Teilaufgaben zerlegt wird. Durch das Vorgeben von Phasenzielen in Form von Meilensteinen können eventuelle Änderungen rechtzeitig eingearbeitet werden, Fehler erkannt und beseitigt oder das Projekt gar abgebrochen werden, wenn ein Erfolg unwahrscheinlich erscheint. Damit kann die Einhaltung von Vorgaben überprüft, der Entwicklungsaufwand überwacht und steuernde Maßnahmen eingeleitet werden. Für jede Phase muss festgelegt werden, was zu tun ist und wie es zu tun ist. Für eine sinnvolle Verantwortungsvergabe muss des Weiteren festgelegt werden wer etwas zu tun hat, wann etwas zu tun ist und welche Kosten dabei höchstens entstehen dürfen.^[113]

Die vier Phasen Analyse, Entwurf, Realisierung und Einführung liegen fast allen Vorgehensmodellen zugrunde. In der Vorphase Projektbegründung werden zunächst der Projektauftrag und die Zielvorstellungen definiert.^[114]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 9 : Das Phasenmodell der Systementwicklung

Quelle: Eigene Darstellung in Anlehnung an Stahlknecht/Hasenkamp (2002), S. 221; Breitner (2006a), S.16.

2.4.1.1 Analysephase

(CR) Im ersten Schritt der Analysephase wird eine Ist-Analyse durchgeführt. Dabei wird der Ist-Zustand erhoben und beschrieben um vor allem Schwachstellen und unerwünschte Zustände analysieren und bewerten zu können. Zu Beginn der Analyse müssen die Erhebungstechniken bestimmt und die Darstellungsform der Ergebnisse festgelegt werden. Von besonderem Interesse sind hierbei ausgewählte Geschäftsprozesse und Arbeitsabläufe im Unternehmen. Um die benötigten Daten zu erhalten und darzustellen, können dabei die in Tab. 3 dargestellten Techniken eingesetzt werden.^[115]

Abbildung in dieser Leseprobe nicht enthalten

Tab. 3: Erhebungs- und Darstellungstechniken

Quelle: Eigene Darstellung in Anlehnung an Stahlknecht/Hasenkamp (2002),

S. 235 – 238.

Festgestellte Mängel sollen mit dem zu entwickelnden System behoben oder zumindest vermindert werden. Verbesserungsvorschläge sollten schon während der Ist-Analyse festgehalten werden. In der Regel wird die Ist-Analyse mit einem schriftlichen Bericht und einem Meilenstein für Entscheider abgeschlossen, an dem entschieden wird, ob die nächste Phase begonnen werden kann, Nachbesserungen nötig sind oder das Projekt gar abgebrochen wird.

Im zweiten Schritt der Analyse ist ein Soll-Konzept zu entwickeln. Hierfür werden Anforderungen und Ziele für das System formuliert. Es wird zuerst ein Fachentwurf erstellt, der beschreibt, was das Anwendungssystem leisten soll. Die hier beschriebenen funktionalen Anforderungen betreffen den Leistungsumfang des Systems und werden mit den Erhebungstechniken und Darstellungstechniken festgehalten, die auch bei der Ermittlung des Ist-Zustands eingesetzt werden. Des Weiteren werden die Schnittstellen definiert, über die Benutzer mit dem System kommunizieren werden. Nach dem Fachentwurf wird ein Grobentwurf erstellt, der beschreibt, wie das System realisiert werden soll. Diese nicht-funktionalen Anforderungen betreffen die Realisierung, die Systemeinführung, die Qualität und das Projektmanagement. Die Vorgehensweise zur Erstellung des Grobentwurfs ist stark davon abhängig, ob eine funktions-, daten- oder objektorientierte Sichtweise der Programmierung gewählt wird sowie von äußeren Rahmenbedingungen, beispielsweise Betriebssystemen, Datenbankverwaltungssystemen, Programmiersprachen und Softwareentwicklungswerk-zeugen.^[116]

Alle aus Sicht der Kunden wünschenswerten Softwareeigenschaften werden im so genannten Lastenheft dokumentiert. Es enthält Wünsche der Auftraggeber an die Leistungen des Systems. Sämtliche Leistungsanforderungen des Lastenheftes, die für eine Erfüllung des Projektes notwendig sind, werden präzisiert, vervollständigt, nachvollziehbar gemacht, mit technischen Festlegungen verknüpft und vom Auftragnehmer im so genannten Pflichtenheft festgehalten.^[117] Am Ende der Analysephase folgt ein weiterer Meilenstein, an dem Entscheidungsträgern das Soll-Konzept präsentiert und über die Fortführung des Projektes entschieden wird.^[118]

2.4.1.2 Eigenentwicklung oder Standardsoftware?

(CR) Nach der Bestimmung des Soll-Konzeptes muss entschieden werden, ob ein eigenes System entwickelt oder eine Standardsoftware erworben wird. Eine Eigenentwicklung ist vor allem dann notwendig, wenn keine den Anforderungen entsprechende Standardsoftware vorhanden ist und durch den Einsatz einer Eigenentwicklung Wettbewerbsvorteile erwartet werden können. Vorteile durch den Erwerb einer Standardsoftware können sich daraus ergeben, dass der Kauf meist kostengünstiger ist als die eigene Produktion und Standardsoftware häufig sofort verfügbar ist und schneller eingesetzt werden kann. Weiterhin sind bei Einsatz von Standardsoftware keine oder weniger IT-Spezialisten im eigenen Unternehmen notwendig und die Risiken der Eigenentwicklung können umgangen werden. Oft werden professionelle Schulungen angeboten. Ferner verfügt Standardsoftware aufgrund einer hohen Nachfrage und einer relativ langen Laufzeit häufig über eine höhere Qualität. Den Vorteilen stehen folgende Nachteile gegenüber: Es sind oft erhebliche Anpassungen der Standardsoftware nötig, da der Anwender besondere Anforderungen hat. Die Ablauforganisation muss teilweise an die Standardsoftware angepasst werden. Sie kann zu allgemein entwickelt sein, was zu Effizienz- und Performanceverlusten führen kann. Außerdem kann es zu Schnittstellen- und Identifikationsproblemen sowie zu einer ungewollten Abhängigkeit vom Hersteller der Software kommen.^[119]

2.4.1.3 Entwurfsphase bei Eigenproduktion

(CR) In der Entwurfsphase werden die Vorraussetzungen für die darauf folgende Realisierungsphase geschaffen. Es werden dabei drei Schritte durchlaufen. Zuerst wird ein strukturierter Systementwurf erstellt. Daran anschließend werden die Programmspezifikationen in Form eines erneuten Pflichtenheftes festgehalten. Diese enthalten detaillierte Vorgaben für einen Programmentwurf. Im letzten Schritt erfolgt die Erarbeitung eines systematischen und möglichst strukturierten Programmentwurfs anhand der Programmspezifikationen.^[120]

Der Systementwurf wird aus dem Grobkonzept der Analysephase abgeleitet. Er besteht bei strukturierter Vorgehensweise aus dem Datenbankentwurf, dem Funktionsentwurf und dem Prozessentwurf. Aus dem Systementwurf werden die Programmspezifikationen für den Programmentwurf festgelegt. Sie enthalten Informationen über die Datenorganisation, Eingabedaten, Verarbeitungsinformationen und Ausgabedaten. Aus den Programmspezifikationen wird entweder ein Programmablaufplan oder ein Struktogramm erstellt, das in der Realisierungsphase in die Programmiersprache übertragen wird. Bei objektorientierter Vorgehensweise werden Daten und Funktionen zu Objekten zusammengefasst und mit Methoden der objektorientierten Systementwicklung bearbeitet.^[121] Bei dem an die Entwurfphase anschließenden Meilenstein wird über die weitere Vorgehensweise entschieden.

2.4.1.4 Entwurfsphase bei Standardsoftware

(CR) Da der Erwerb einer Standardsoftware meist sehr kostenintensiv ist und nicht einfach wieder rückgängig gemacht werden kann, sollte die Auswahl sehr sorgfältig getroffen werden. Der Auswahlprozess sollte dabei die Punkte Ausschreibung und Angebotseinholung, Grob- und Feinbewertung der Angebote sowie Endauswahl enthalten.

Im ersten Schritt muss eine ausreichende Anzahl von Angeboten eingeholt werden. Bei der Grobbewertung sollten zuerst Angebote, die so genannte K.O.-Kriterien nicht erfüllen, ausgeschlossen werden. Danach sollte über weitere Kriterien die Auswahl bis auf ca. drei bis fünf Angebote eingegrenzt werden. Für die Feinbewertung kann z. B. eine Nutzwertanalyse durchgeführt werden. Dabei werden alle relevanten Kriterien zusammengestellt und gewichtet.^[122] Um über die Fortführung des Projektes entscheiden zu können, sollten Wirtschaftlichkeitsvergleiche angestellt werden. Dabei können reine Kostenvergleiche und Kosten/Nutzen-Vergleiche erstellt werden. Bei den Kosten ist zwischen einmaligen und laufenden Kosten zu unterscheiden.^[123]

2.4.1.5 Realisierungsphase bei Eigenentwicklung

(CR) Bei der Realisierung stehen die eigentliche Programmierarbeit und der Programm- und Systemtest im Vordergrund. Der Verlauf der Programmierung ist abhängig von den eingesetzten Programmen sowie von den benutzten Prinzipien, Methoden und Verfahren.^[124]

Nach der Programmierung erfolgt das Testen. Es ist vorteilhaft, wenn die Anwendung schon während der Programmierung auf Fehler kontrolliert wird. „Unter Testen im engeren und klassischen Sinne versteht man die Prüfung von codierten Programmen auf korrekte Formulierung und Ausführung.“^[125] Ein Software-Test ist ein mögliches Verfahren zur Verifikation und Validierung eines Programms. Unter Verifikation versteht man den mathematischen Beweis, dass das entwickelte Programm den vorher festgelegten Spezifikationen entspricht,^[126] wohingegen bei der Validierung die Eignung beziehungsweise der Wert einer Software bezogen auf ihren Einsatzzweck überprüft wird.^[127] Zum Testen können unterschiedlichste Verfahren angewendet werden. Neben der Überprüfung des Programmcodes sollte unter anderem ein Modultest, ein Komponententest, ein Systemtest und ein Abnahmetest mit allen Personen, die mit dem Programm arbeiten werden, durchgeführt werden. Die Bewertung der Ergebnisse des Tests führt zu weiteren Maßnahmen (z. B. Bugfixing).^[128] Am Ende der Realisierungsphase folgt ein weiterer Meilenstein, an dem über die Fortführung des Projektes entschieden wird.

2.4.1.6 Realisierungsphase bei Standardsoftware

(CR) In der Realisierungsphase wird die erworbene Software zuerst auf das System des Unternehmens aufgespielt. Danach muss die Standardsoftware an die Anforderungen des Auftraggebers angepasst werden. Die Anpassungsmaßnahmen enthalten im Wesentlichen Aufgaben der Parametrisierung, Konfigurierung und Individualprogrammierung.

Bei der Parametrisierung wird das Programm durch die Änderung von Parametern eingestellt. Durch eine Konfigurierung werden benötigte Module hinzugefügt. Individualprogrammierung bietet die beste Möglichkeit, das System auf die Anforderungen abzustimmen; es ist allerdings auch die kostenaufwendigste Anpassungsmaßnahme. Anpassungen und Erweiterungen werden individuell erstellt.^[129]

2.4.1.7 Einführungsphase

(CR) Die letzte Phase startet mit einer formalen Systemfreigabe, bei der die Dokumentationen und die Unterlagen des Projekts auf Vollständigkeit überprüft werden. Die darauf folgende Systemeinführung entspricht einer formalen Übergabe des Systems an den Auftraggeber. Sie erfolgt bei einer Eigenentwicklung nach einem erfolgreich abgeschlossenen Abnahmetest und bei der Anschaffung von Standardsoftware nach Abschluss der Anpassungsmaßnahmen.^[130] Die Systemeinführung ist mit einer Unterweisung aller Beteiligten verbunden, wobei eventuell notwendige Schulungsmaßnahmen möglichst früh durchgeführt werden sollten. Es ist ein Umstellungsplan aufzustellen, der eine klare Aufgaben- und Kompetenzverteilung beinhaltet. Der Datenübernahme kommt hierbei eine besondere Bedeutung zu. Vorhandene Daten werden in das System eingepflegt. Die Einführung des Systems kann zu einem Stichtag bei gleichzeitiger Beendigung des alten Systems (Big Bang) oder stufenweise mit nur einem Teil des Systems oder der Daten erfolgen. Außerdem gibt es die Möglichkeit das neue und das alte System parallel laufen zu lassen. Während bei der schnellen Einführung die Gefahr höher ist, dass das Projekt scheitert, können bei der stufenweisen Einführung zusätzliche Kosten entstehen.^[131]

Nach der Einführung geht die Anwendung in den Produktivbetrieb über, wobei Wartungs- und Pflegearbeiten notwendig sein können. Dabei sollen auftretende Fehler behoben und die Qualität verbessert werden. Außerdem soll das System an veränderte Anforderungen angepasst und um neue Funktionen erweitert werden.^[132]

2.4.1.8 Kritik des Phasenmodells

(CR) Das Phasenmodell bildet eine nachvollziehbare Basis für Softwareentwicklungen und ist Grundlage vieler Vorgehensmodelle. Gegen ein strenges Phasenkonzept spricht, dass Änderungen auf Grund äußerer Einflüsse und neuer Erkenntnisse oft schon während der Erstellung des Soll-Konzeptes und des Systementwurfs notwendig sind. Außerdem sind viele Programmspezifikationen im Vorfeld schwer oder gar nicht abschätzbar. Um auf die Kritikpunkte einzugehen, werden die einzelnen Phasen oder mehrere zusammenhängende Phasen bei manchen Modellen iterativ wiederholt (z. B. beim Wasserfallmodell). Bei der objektorientierten Systementwicklung kann die strenge Einteilung durch fließende Phasenübergänge aufgehoben werden.^[133]

2.4.2 Wasserfall- und V-Modell

(CR) Im Vergleich zum starren Phasenmodell wurde das Wasserfallmodell mit Rückkoppelungen zum Beginn einer Phase und zu vorhergehenden Phasen erweitert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 10 : Beispiel eines Wasserfallmodells

Quelle: Eigene Darstellung in Anlehnung an Stein (2004), S. 3.

Das Modell versucht, den gesamten Software-Lebenszyklus darzustellen.^[134] Während das klassische Wasserfallmodell nur Iterationen zwischen zwei aufeinander folgenden Phasen erlaubt, sind bei neueren Modellen auch Sprünge zu früheren Phasen möglich.^[135]

Die standardisierte Vorgehensweise des V-Modells soll IT-Projekte plan- und nachvollziehbar machen und Ergebnisse von hoher Qualität sicherstellen. Die aktuelle Version, das V-Modell XT, wurde vom Bundesministerium des Inneren entwickelt und ist für Bundesbehörden verbindlich vorgeschrieben. Statt der Phasen des Phasenmodells basiert das V-Modell auf Aktivitäten und Ereignissen, die nicht zwingend in einer zeitlichen Abfolge durchlaufen werden müssen.^[136]

Das Vorgehen beim V-Modell variiert durch verschiedene Projekttypen, die abhängig von den Parametern des Projekts sind. Für jeden Projekttyp sind individuelle Projektdurchführungsstrategien vordefiniert. Es werden dabei individuell Vorgehensbausteine zusammengestellt, wobei bestimmte Bausteine bei jedem Projekttyp notwendig sind, um ein Mindestmaß an Qualität zu sichern. Diese Bausteine bilden den V-Modell-Kern.^[137]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 11: Auszug der Projektdurchführungsstrategien des V-Modells

Quelle: BRD (2004), S. 18.

[...]

---

^[1] Vgl. Lyman/Varian (2003), S. 1 – 2.

^[2] Vgl. Julich (2002), S. 399.

^[3] Vgl. Lyman/Varian (2003), S. 1 – 2.

^[4] Vgl. Bager (2002), S. 172.

^[5] http://www.zdnet.de/.

^[6] Vgl Weinstein (2000), S. 38 – 39 zitiert nach Christ (2003), S. 1.

^[7] Vgl. Nix (2005), S. 11.

^[8] Vgl. Mosch (2004), S. 15.

^[9] Vgl. Europäische Kommission (2003), S. 4.

^[10] Vgl. Jacoby (2007), S. 17.

^[11] Vgl. Jacoby (2007), S. 17.

^[12] Vgl. Jacoby (2007), S. 15 – 16; Mosch (2004), S. 14.

^[13] Vgl. impulse/Institut für Mittelstandsforschung (2004), S. 10.

^[14] Vgl. Europäische Kommission (2006), S. 10.

^[15] Vgl. Mosch (2004), S. 21.

^[16] Vgl. Pols et al. (2004), S. 55.

^[17] Vgl. Staaden (2006), S. 1.

^[18] „Proprietary software is software that is not free or semi-free. Its use, redistribution or

modification is prohibited, or requires you to ask for permission, or is restricted so much that you effectively can't do it freely.“ (GNU (o. J.b), S. 5 – 6).

^[19] Vgl. Nix et al. (2005), S. 64 – 65; Freyermuth (2001), S. 177.

^[20] GNU ist ein rekursives Akronym für „GNU´s Not Unix“ (vgl. GNU (o. J.a), S. 1). Weitere Informationen zum GNU Projekt sind im Internet unter der Adresse http://www.gnu.org zu finden.

^[21] Vgl. Stallman o. J., S. 8 – 9; GNU (o. J.a), S. 1.

^[22] Die Open Source Initiative (http://www.opensource.org) ist eine Organisation zur Förderung von Open Source Software.

^[23] Vgl. Open Source Initiative (2007), S. 1 – 5; Renner et al. (2005), S. 12 – 13.

^[24] Vgl. Renner et al. (2005), S. 12 – 13.

^[25] http://www.ubuntu.com/.

^[26] http://www.joomla.org/.

^[27] http://www.adobe.com/de/products/reader/.

^[28] http://www.winamp.com/.

^[29] http://www.turbolinux.com/.

^[30] http://www.redhat.com/.

^[31] http://www.microsoft.com/germany/windows/products/windowsvista/default.mspx.

^[32] Vgl. Franck (2003), S. 527.

^[33] Vgl. Abschnitt 2.2.4 für mehr Informationen zu OSS-Geschäftsmodellen.

^[34] Vgl. Renner et al. (2005), S. 14 – 15.

^[35] Vgl. Renner et al. (2005), S. 19; Heinze/Keller (2004), S. 41.

^[36] „The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software to make sure the software is free for all its users.“ (Free Software Foundation (1991), S. 2).

^[37] Vgl. Kleijn (2006), S. 1.

^[38] Die Open Source Initiative listet aktuelle OSS-Lizenzen unter der Adresse

http://www.opensource.org/licenses/index.php.

^[39] http://sourceforge.net/.

^[40] Vgl. vertiefend http://www.gnu.org/copyleft/gpl.html.

^[41] Vgl. vertiefend http://www.gnu.org/copyleft/lesser.html.

^[42] Vgl. vertiefend http://www.opensource.org/licenses/bsd-license.php.

^[43] Zum Begriff des Copyleft vgl. vertiefend http://www.gnu.org/copyleft/.

^[44] Vgl. OpenFacts (2006), S. 9.

^[45] Vgl. Abschnitt 2.2.1.

^[46] Vgl. Heinze/Keller (2004), S. 43.

^[47] Vgl. Reiter (2004), S. 86; Renner et al. (2005), S. 20 – 21; OpenFacts (2006), S. 3 – 4.

^[48] Vgl. Reiter (2004), S. 86; Renner et al. (2005), S. 21; OpenFacts (2006), S. 4 – 5.

^[49] Vgl. Heinze/Keller (2004), S. 43.

^[50] Vgl. Renner et al. (2005), S. 21; OpenFacts (2006), S. 5 – 6.

^[51] Vgl. Renner et al. (2005), S. 17.

^[52] Vgl. Hansen/Neumann (2005), S. 537.

^[53] Vgl. Renner et al. (2005), S. 16 – 17.

^[54] Das „peer-review“ ist eine wissenschaftliche Basistechnik, bei der Experten die Arbeit von Kollegen begutachten (vgl. Freyermuth (2001), S. 183).

^[55] Vgl. Wieland (2004), S. 3; Raymond (1998), S. 1 – 2.

^[56] Vgl. Renner et al. (2005), S. 16.

^[57] Vgl. Renner et al. (2005), S. 16.

^[58] Vgl. Renner et al. (2005), S. 16; Wieland (2004), S. 7.

^[59] Vgl. Renner et al. (2005), S. 17; Wieland (2004), S. 4.

^[60] Vgl. Renner et al. (2005), S. 18.

^[61] Vgl. Wieland (2004), S. 9.

^[62] Vgl. Renner et al. (2005), S. 17.

^[63] Vgl. Renner et al. (2005), S. 18.

^[64] Vgl. Kooths/Langenfurth/Kalwey (2003), S. 47.

^[65] Vgl. Leiteritz (2004), S. 3.

^[66] Vgl. Leiteritz (2004), S. 3.

^[67] Vgl. Kooths/Langenfurth/Kalwey (2003), S. 48 – 50.

^[68] Vgl. Leiteritz (2004), S. 9 – 11.

^[69] Vgl. Leiteritz (2004), S. 9 – 11. Als Beispiel kann an dieser Stelle das Unternehmen eZ systems genannt werden, das sein CMS eZ publish einerseits kostenlos unter der GPL anbietet, andererseits aber auch eine Version unter einer kostenpflichtigen „Professional License“ vertreibt (vgl. Nix (2005a), S. 1).

^[70] Vgl. Leiteritz (2004), S. 12 – 14.

^[71] Vgl. Leiteritz (2004), S. 14 – 17.

^[72] Online-Werbung umfasst alle Werbemaßnahmen, die mittels Webseiten im World Wide Web durchgeführt werden. Zur weiteren Vertiefung vgl. Homburg/Krohmer (2006), S. 818 – 819.

^[73] Vgl. Leiteritz (2004), S. 17 – 19. Ein Beispiel für einen Mediator ist das OSS Projektportal SourceForge.net.

^[74] http://www.w3.org.

^[75] XML ist ein rekursives Akronym für Extensible Markup Language.

^[76] HTML steht für Hypertext Markup Language.

^[77] Die Lettern XHTML stehen für Extensible Hypertext Markup Language.

^[78] CSS ist ein rekursives Akronym für Cascading Style Sheets.

^[79] Ursprünglich als Abkürzung Personal Home Page steht PHP heutzutage für Hypertext Preprocessor (vgl. Freyermuth, (2001), S. 183).

^[80] Vgl. Graf (2006a), S. 210.

^[81] Eine Metasprache ist eine Sprache, mit der eine andere Sprache erklärt oder definiert wird.

^[82] Vgl. Hofmann/Raitelhuber (1998), S. 3.

^[83] Vgl. World Wide Web Consortium (2006), S. 5.

^[84] Vgl. Mintert (2004), S. 8.

^[85] Entitäten sind abstrakte Konzepte oder auch konkrete Objekte, denen Informationen zugeordnet werden können (vgl. Schreier (2001), S. 184).

^[86] In Dokumenttyp-Definitionen werden Regeln für die Elemente, Attribute und Verschachtelungsmöglichkeiten einer XML-Sprache festgehalten.

^[87] Vgl. Selfhtml (2007), S. 3 – 4.

^[88] Vgl. Dobratz (1999), S. 4.

^[89] Vgl. Kobert (2000), S. 45.

^[90] Vgl. Münz/Nefzger (2002), S. 11 – 12.

^[91] Vgl. World Wide Web Consortium (2002), S. 9.

^[92] Vgl. vertiefend zur PHP-Lizenz: http://php.zend.com/license/3_01.txt.

^[93] Vgl. Krause (2005), S. 25 – 27; RRZN/Universität Hannover (2005), S. 7.

^[94] Vgl. Krause (2005), S. 36.

^[95] Vgl. Graf (2006a), S. 25.

^[96] Vgl. RRZN/Universität Hannover (2005), S. 5.

^[97] Vgl. Münz/Nefzger (2002), S. 26 – 27.

^[98] Vgl. RRZN/Universität Hannover (2005), S. 12; Münz/Nefzger (2002), S. 26.

^[99] Vgl. Voss (2005), S. 222 – 223.

^[100] Vgl. vertiefend: css4you (2007), S. 1 – 7.

^[101] Vgl. Heuer (2001), S. 44 – 45; Kesper et al. (2004), S. 20.

^[102] Vgl. IT Wissen (2007a), S. 1 – 2.

^[103] Vgl. D Punkt (2007), S. 1 – 2.

^[104] Vgl. IT Wissen (2007b), S. 1.

^[105] Vgl. Kritzner (2006), S. 1.

^[106] Vgl. vertiefend: http://msdn2.microsoft.com/de-de/library/72bd815a(vs.80).aspx.

^[107] Der Begriff AJAX steht für Asynchronous JavaScript And XML (vgl. Wenz (2007), S. 391). Ajax-Technologien ermöglichen die Programmierung dynamischer Webseiten.

^[108] Vgl. Universität Ulm (2007), S. 9 – 10.

^[109] Vgl. Breitner (2006a), S. 5.

^[110] Vgl. Wapedia (2007), S. 1 – 2.

^[111] Extreme Programmierung ist ein Softwareentwicklungsprozess, der durch kurze Zyklen mit häufigen Rückkopplungen und die kontinuierliche Überprüfung von realisierten mit spezifizierten Anforderungen gekennzeichnet ist. Weiterhin wird der Entwicklungsprozess nicht im Detail geplant, sondern an veränderte Anforderungen angepasst und umfasst den gesamten Lebenszyklus einer Software (vgl. Heinrich et al (2004), S. 244).

^[112] Prototyping ist ein Ansatz zur Softwareentwicklung mit ausgeprägter Benutzerbeteiligung. Vgl. vertiefend Heinrich et al. (2004), S. 532 – 533.

^[113] Vgl. Stahlknecht/Hasenkamp (2002), S. 222; Mertens et al. (2005), S. 160.

^[114] Vgl. Stahlknecht/Hasenkamp (2002), S. 214.

^[115] Vgl. Stahlknecht/Hasenkamp (2002), S. 229 – 230.

^[116] Vgl. Stahlknecht/Hasenkamp (2002), S. 247 – 250.

^[117] Vgl. Hasenkamp (2007), S. 2 – 3.

^[118] Vgl. Stahlknecht/Hasenkamp (2002), S. 257.

^[119] Vgl. Stahlknecht/Hasenkamp (2002), S. 302 – 303; Amberg (2007), S. 9.

^[120] Vgl. Stahlknecht/Hasenkamp (2002), S. 258.

^[121] Vgl. Stahlknecht/Hasenkamp (2002), S. 257; Stahlknecht/Hasenkamp (2002), S. 278.

^[122] Vgl. Stahlknecht/Hasenkamp (2002), S. 304 – 310.

^[123] Vgl. Waehlert (2007), S. 35 – 37.

^[124] Vgl. Stahlknecht/Hasenkamp (2002), S. 288.

^[125] Vgl. Stahlknecht/Hasenkamp (2002), S. 295.

^[126] Vgl. IT Wissen (2007c), S. 1.

^[127] Vgl. Meyers Lexikon Online (2007), S. 1.

^[128] Vgl. Floyd/Oberquelle (2004), S. 8.

^[129] Vgl. Stahlknecht/Hasenkamp (2002), S. 303 – 304.

^[130] Vgl. Stahlknecht/Hasenkamp (2002), S. 321.

^[131] Vgl. Stahlknecht/Hasenkamp (2002), S. 323; Mertens et al. (2005), S. 164.

^[132] Vgl. Stahlknecht/Hasenkamp (2002), S. 324.

^[133] Vgl. Breitner (2006b), S. 62 – 63.

^[134] Vgl. Stein (2004), S. 1.

^[135] Vgl. Horn (2007), S. 4.

^[136] Vgl. BRD (2004), S. 5 – 10.

^[137] Vgl. BRD (2004), S. 4 – 10.