Georg-August-Universität
Göttingen
Zentrum für Informatik
ISSN 1612-6793
Nummer ZFI-BM-2004-30
Bachelorarbeit
im Studiengang "Angewandte Informatik"
Entwicklung eines Prototyps
zur interaktiven Telekommunikation
von Berufsinformationen für Jugendliche
Alexander Willner
am Zentrum für
interdisziplinäre Medienwissenschaft
Bachelor- und Masterarbeiten
des Zentrums für Informatik
an der Georg-August-Universität Göttingen
29. Dezember 2004

Georg-August-Universität Göttingen
Zentrum für Informatik
Lotzestraße 16-18
37083 Göttingen
Germany
Tel. +49 (5 51) 39-1 44 14
Fax +49 (5 51) 39-1 44 15
Email office@informatik.uni-goettingen.de
WWW www.informatik.uni-goettingen.de

Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Göttingen, den 29. Dezember 2004

Bachelorarbeit
Entwicklung eines Prototyps
zur interaktiven Telekommunikation
von Berufsinformationen für Jugendliche
Alexander Willner
29. Dezember 2004
Verantwortlicher Hochschullehrer: Prof. Dr. Bernd Schmidt
Betreut durch: Martin Traub
Akademischer Direktor und Leiter der Zentralen Einrichtung Me-
dien der Universität Göttingen. Zweitmitglied des Zentrums für in-
terdisziplinäre Medienwissenschaft.
Zentrum für interdisziplinäre Medienwissenschaft
Georg-August-Universität Göttingen

Gegenstand der vorliegenden Arbeit ist die Entwicklung einer interaktiven Kommu-
nikationsplattform. Ausgehend von dem Projekt „Jobs in Motion - Medien zur Berufsin-
formation“1 der Zentralen Einrichtung Medien der Universität Göttingen wird ein inter-
disziplinäres Anforderungsprofil für die interaktive Kommunikationsplattform abgeleitet.
Aufbauend auf technischen Analysen werden mögliche Lösungsansätze beschrieben und
ein ausgewählter Weg beispielhaft umgesetzt.
„So eine Arbeit wird eigentlich nie fertig, manmuß sie für fertig erklären, wenn
man nach Zeit und Umständen das Mögliche getan hat.“
[J.W. von Goethe, Italienische Reise, 16. März 1787]
1http://www.jobs-in-motion.de

Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen 4
2.1 Softwareengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Interaktivität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Medienkonvergenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Interaktives Fernsehen . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.4 Mobilfunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Analyse 9
3.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Produkt-Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Produkt-Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4 Produkt-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.5 Produkt-Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.6 Qualitäts-Zielbestimmung und Ergänzungen . . . . . . . . . . . . . . 18
3.2 Technische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Videostreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Übertragungstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Suchverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.5 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
i

Inhaltsverzeichnis
4 Design 34
4.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1 Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.2 Übertragungstechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.4 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Ausgewählte Produktleistungen . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.3 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4 Programmklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Implementierung 43
5.1 Ziel der Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 Test, Betrieb und Wartung 48
7 Zusammenfassung und Ausblick 49
Abkürzungsverzeichnis 50
Abbildungsverzeichnis 52
Literaturverzeichnis 53
ii

1 Einleitung
1.1 Motivation
Für Jugendliche ist die eigene Berufswahl ein kulturelles Ritual mit vielen Hürden. Dieser
gesellschaftliche Integrationsprozess wird von allen Personen zwischen 14 und 21 Jahren
durchlaufen. Berufsinformation und -orientierung wird an den Schulen von den Jugendli-
chen nur selten angenommen. Zudem sind viele Ausbildungsberufe aufgrund der großen
Vielfalt unbekannt. Unter der Bezeichnung eines Berufsfeldes wie beispielsweise dem ei-
nes "Verfahrensmechanikers für Kunststoff- und Kautschuktechnik"können sich Jugendli-
che nur wenig vorstellen.
Das Projekt "Jobs in Motion - Medien zur Berufsinformation"1 der Zentralen Einrichtung
Medien der Universität Göttingen hat sich zur Aufgabe gemacht, die Berufsfelder ver-
schiedener Ausbildungsberufe in Bild und Ton zielgruppengerecht aufzuarbeiten.Mehrere
kompakte Videos, sog. Clips, sollen einen ersten Eindruck der Berufe und die damit ver-
bundenen Ausbildungsmöglichkeiten vermitteln. Diese Clips erheben keinen Anspruch
auf Vollständigkeit oder Objektivität. Sie setzen bewusst auf Neugier und Emotionen der
Jugendlichen, um auf eine unterhaltende Art und Weise Aufmerksamkeit zu erregen und
Impulse zur weiteren Information über Berufe zu geben.
Die zentrale Einrichtung Medien hat in Zusammenarbeit mit dem Zentrum für interdis-
ziplinäre Medienwissenschaft - zum Zeitpunkt meiner Arbeit - bislang 31 kurze Videoclips
erstellt - eine deutliche Erweiterung des Angebotes ist in Planung. Im Oktober 2004 hat der
niedersächsische Ministerpräsident Christian Wulff die Schirmherrschaft über das Projekt
übernommen.
Jedoch erfolgte die Verteilung dieser Clips bislang lediglich über DVDs und der Bereit-
stellung im Internet. Es existiert z. Z. keine Möglichkeit für die Jugendlichen, interaktiv
auf den motivierenden Charakter der Videos einzugehen und damit direkt weitere Infor-
mationen abzurufen.
1.2 Zielsetzung
Das Ziel der vorliegenden Arbeit ist der Entwurf einer modernen, technischen Kommuni-
kationsplattform für die o.g. Videoclips. Diese Plattform soll es dem Jugendlichen ermög-
1http://www.jobs-in-motion.de
1

1 Einleitung
lichen, die Clips vollständig audio-visuell zu erschließen und bei Interesse direkt weitere
Informationen abrufen zu können.
Die damit zusammenhängenden technischen Voraussetzungen für solch eine individu-
elle, interaktive Kommunikation sind zu suchen und die geeignete Lösungen auszuwäh-
len. Die komplexe Wechselbeziehung zwischen der eigentlichen Berufsinformation und -
orientierung und dem Jugendlichen integriert eine Vielzahl von Bereichen. So hat beispiels-
weise der Übertragungsweg der Videos und das kommunikative Umfeld der Anwendung
den Rezeptionsgewohnheiten der Jugendlichen zu entsprechen.
1.3 Methodik
Die Entwicklung einer technischen Umsetzung mit der gegebenen Zielsetzung erfordert
ein interdisziplinäres Vorgehen und eine Auseinandersetzung mit verschiedenen Frage-
stellungen. So sind rechtliche Aspekte, die betriebswirtschaftliche Rentabilität, die markt-
analytischen Perspektiven, die zielgruppengerechte audio-visuelle Aufbereitung, techni-
sche Gesichtspunkte der Informatik sowie weitere sozial-, medien- und kommunikations-
wissenschaftliche Aspekte zu berücksichtigen.
Im Rahmen dieser Arbeit kann jedoch aus zeitlichen Gründen nicht auf alle Bereiche
eingegangen werden. Auch aufgrund von Problemen in der fachspezifischen Strukturie-
rung und Terminologie einzelner Reflexionsebenen bedarf es einer strikten Eingrenzung
der Thematik. Der Schwerpunkt meiner Arbeit liegt in der Entwicklung der Systemarchi-
tektur für eine interaktive Telekommunikation. Das gegebene Ziel ist somit ein Gegenstand
der Informatik, insbesondere des Teilbereichs Softwareengineering.
Im Bereich desWeb- oder Softwareengineerings existieren verschiedene Konzepte,Werk-
zeuge und Techniken mit jeweils unterschiedlichen Schwerpunkten. Auf die Interdiszi-
plinarität dieses fächerübergreifenden Projektes muss mittels entsprechender Methoden
der Informatik Rücksicht genommen werden. So wurde als weiteres Vorgehen ein itera-
tiv, inkrementelles Modell (basierend auf dem Spiralmodell und dem Rapid Prototyping)
zur Softwareentwicklung gewählt. Daher werden schrittweise Zwischenergebnisse prä-
sentiert, die während der Entwicklung eine kontinuierliche und effektive Kommunikati-
on zwischen den beteiligten Gruppen gewährleisten. Auf veränderte Anforderungen oder
Missverständnisse kann so flexibel reagiert werden.
Die drei Kernabschnitte der Softwareentwicklung (i) Analyse, (ii) Design und (iii) Imple-
mentierung werden im Rahmen dieser Arbeit einmal durchlaufen und exemplarisch um-
gesetzt. Der Prototyp folgt im allerersten Iterationsschritt dem Modell des „Rapid Prototy-
ping“, d.h. die Programmteile selbst haben keinen Anspruch auf Wiederverwendbarkeit.
Die Machbarkeit des Entwurfes soll lediglich dargestellt und ggf. unklare Formulierungen
in der Anforderungsdefinition verdeutlicht werden.
Weitere Iterationsschritte, die nicht mehr Inhalt der vorliegenden Arbeit sind, enden je-
2

1 Einleitung
weils in Prototypen, dessen Programmteile für neue Entwicklungen übernommen, d.h. in-
krementell erweitert werden können. Diese werden in jedem Schritt durch Unit- und Inte-
grationstests auf ihre Funktionsfähigkeit und korrekte Interaktion mit anderen Programm-
teilen überprüft. Im letzten Iterationsschritt folgen nach dem System- und Abnahmetest,
der die Erfüllung aller Anforderungen des Projekts überprüft, die Phasen des Betriebs und
der Wartung.
1.4 Aufbau
Das oben beschriebene Vorgehen, der inkrementellen, iterativen Softwareentwicklung, wird
im weiteren Verlauf dieser Arbeit umgesetzt und spiegelt sich in der Gliederung wider.
Nach der einleitenden Beschreibung der Thematik, der Motivation und des Umfeldes zu
der Arbeit werden Konzepte und Begrifflichkeiten kurz erläutert und in den Zusammen-
hang der Arbeit gebracht. Mit Blick auf die Integrationsmöglichkeiten verschiedener Fach-
gebiete wird ein Anforderungsprofil abgeleitet. Eine detaillierte Analyse möglicher Tech-
niken und Wege bildet im Anschluss die Grundlage für den eigentlichen Entwurf des Sys-
tems und der Implementierung. Zum Ende wird die Arbeit kritisch betrachtet, ein Fazit
gezogen und ein Ausblick gegeben.
3

2 Grundlagen
Um fachfremden Lesern das Verständnis der vorliegenden Arbeit zu erleichtern, werden
im Folgenden einige grundlegende Begriffe erläutert und ihre Zusammenhänge systema-
tisch beschrieben.
2.1 Softwareengineering
Das Grundgerüst der Arbeit basiert auf den Kernabschnitten des klassischen, nicht agilen
Softwareengineerings: Anforderungen, Analyse, Design, Implementierung, Test, Betrieb
und Wartung. Dieser Teilbereich der Informatik beschreibt die ingenieurmäßige Herstel-
lung von Softwaresystemen und hat ihren Ursprung in der sog. Softwarekrise der 60er
Jahre. Der Komplexität der Softwareentwicklung soll mit verschiedenen Konzepten, Werk-
zeugen und Techniken entgegnet werden, um Software zielgerichteter, schneller und qua-
litativ hochwertiger zu gestalten (vgl. [1; 2]). Insgesamt werden nur 34% aller Software-
Projekte in Unternehmen rechtzeitig im geplanten Kostenrahmen und mit der kompletten
spezifischen Funktionalität durchgeführt1, immerhin jedoch eine Verdopplung der erfolg-
reich durchgeführten Projekte gegenüber 1994.
„Softwareengineering (= Software-Technik) ist die Entwicklung, die Pflege und
der Einsatz qualitativ hochwertiger Software unter Einsatz von wissenschaft-
lichen Methoden, wirtschaftlichen Prinzipien, geplanten Vorgehensmodellen,
Werkzeugen und quantifizierbaren Zielen.“[2]
Das Ziel dieser Arbeit ist ein Softwaresystem zu entwickeln, das als Basis für weiter-
führende Entwicklungen dienen kann. Die Methoden und Verfahren des Softwareengi-
neerings helfen hierbei, diese Plattform systematisch und zielgerichtet zu entwerfen und
weitere Entwicklungen zu berücksichtigen.
2.2 Interaktivität
Der Bereich der Berufsorientierung erfordert aufgrund der engen Verknüpfung mit der
persönlichen Wertorientierung ein hohes Maß an individueller Kommunikation. Diesem
Anspruch können herkömmliche Massenmedien nur schwer gerecht werden.
1Laut Pressebericht vom 25. März 2003 von CHAOS, The Standish Group International, Inc.
4

2 Grundlagen
„Interaktion [lat.], die Wechselbeziehung zwischen den Individuen innerhalb
der Gesellschaft, besonders die Kommunikation in Gruppen. Zwei Personen
interagieren, wenn die Aktion des einen Partners durch die des anderen hin-
sichtlich ihrer Art undMenge beeinflusst werden. Das Verhältnis kann einseitig
sein, zweiseitig, öfter aber auch reziprok.“[3]
Der Grad der Interaktivität, den ein Medium mit sich bringt, kann sehr unterschied-
lich sein. Ein Medium kann dementsprechend als Push- oder Pull-Medium klassifiziert
werden. So sind klassische Medien wie etwa Zeitung, Radio oder Fernsehen generell den
Push-Medien zugeordnet. Das Internet wird als typisches Pull-Medium bezeichnet.
Die fortschreitende Medienkonvergenz bedingt einen Angleich der Interaktionsmög-
lichkeiten verschiedener Medien auf hohem Niveau. Diese Weiterentwicklung und An-
gleich der Medien eröffnen neue Möglichkeiten der Berufsinformation, die so technisch
bislang noch nicht möglich gewesen sind. Diesem Sektor widmet sich diese Arbeit.
2.3 Medienkonvergenz
In der Digitalisierung liegt ein entscheidender Faktor im Wandel der Medien. Die Um-
wandlung von analogen zu digitalen Signalen hat die Information von der eigentlichen
physischen Existenz losgelöst. Die verlustfreie Kopierbar- und Übertragbarkeit von Infor-
mationen über Mediengrenzen hinweg hat zu einer Annäherung verschiedener Einzelme-
dien geführt. Diese Annäherung wird im allgemeinen als Medienkonvergenz bezeichnet.
Grundlage für diese Konvergenz ist die Auslöschung und Entwicklung diverser Medien,
wie etwa die Ablösung der analogen Schallplatte durch die digitale Compact Disc (CD).
Die Substitution der CD durch neue Speichermedien und die Verbreitung der Daten über
digitale Medien ist bereits in Sicht2.
„Das Medium ist die Botschaft“. [McLuhans, 60er Jahre]
Das Image eines Mediums ist für die Kommunikation mit Jugendlichen von wichtiger
Bedeutung. Durch die Rezeption über modernere Medien kann die Botschaft entsprechen
aufgewertet werden. In Bezug zu dieser Arbeit sind zwei Entwicklungen im Bereich der
Medien von besonderem Interesse, das interaktive Fernsehen und Mobilfunktelefone. Bei-
de nutzen das Internet als gemeinsames Medium und sind von diesem direkt beeinflusst.
Auf andere Endgeräte, wie etwa digital Terminkalender (PDA), die nur selten von der Ziel-
gruppe Jugend genutzt werden, wird im Rahmen dieser Arbeit nicht weiter eingegangen.
Diese sind als Endgeräte jedoch nicht kategorisch auszuschließen.
2Derzeitig ist das Modell, welches heute z.B. die Produkte der Firma Apple mittels iPod und iTunes umsetzt,
mögliche Konkurrenten der klassischen CD-Distribution
5

2 Grundlagen
Fähigkeit PC iTV Handy
Verbreitung + - +
Verfügbarkeit o o +
Mobilität o o +
Leistungsfähigkeit + o -
Bildschirm + + -
Eingabemöglichkeiten + o -
Telekomm.fähigkeit + o +
Tabelle 2.1: Vor- und Nachteile unterschiedlicher Endgeräte
2.3.1 Internet
Die in diesem Zusammenhang wohl wichtigste Entwicklung war die Entstehung des In-
ternets in den 60er Jahren. Dieses gewann 1990 durch den Entwurf des Protokolls HTTP
durch Tim Berners-Lee am CERN und der damit zusammenhängenden Verbreitung des
WWW deutlich an Popularität.
Durch die Entwicklung der mobilen und immobilen Internetzugänge zu breitbandigen
Anschlüssen3 können verschiedeneMedien in das Internet eingebettet werden. So sind bei-
spielsweise Internetradio, Internettelefon oder Internetfernsehen neue Nutzungsformen,
die sich im laufe der Zeit vermutlich weiterer Beliebtheit erfreuen werden.
2.3.2 PC
Der Computer gehört zu den wohl bekanntesten Endgeräten für den Zugang zum Inter-
net. Die Nutzung des WWW und E-Mails von zu Hause oder in sog. Internetcafés gehört
zu den beliebtesten Anwendungen. 51 % aller Haushalte in Deutschland besitzen einen
PC (vgl. [4]). Im Rahmen dieser Arbeit werden unterschiedliche Arten von tragbaren wie
stationären Computer gemeinsam als PC (Personal Computer) bezeichnet.
Der Vorteil des Computers liegt in seiner Verbreitung, Leistungsfähigkeit, guter Bild-
schirme und breiten Eingabemöglichkeiten (vgl. 2.1). Die Nutzung des Internet durch die
o.g. Dienste gehören zum alltäglichen Leben vieler Menschen. Der Computer bietet meist
viele Möglichkeiten eine Verbindung zum Internet aufzubauen.
2.3.3 Interaktives Fernsehen
Oft greift die klassische Unterscheidung zwischen Pull- und Push-Medien nicht mehr. Dies
spiegelt sich insbesondere bei der Entwicklung des allgegenwärtigen Mediums Fernsehen
3Pressemitteilung der Deutschen Telekom Januar 2004: Über 4 Mio. T-DSL Kunden, 40% Zuwachs zum Vor-
jahr.
6

2 Grundlagen
mehr handelt es sich um hochtechnologische und in der breiten Gesellschaft akzeptierte
Mehrzweckgeräte. Sie können Fernsehgerät, Ortungssystem, Spiele- und Arbeitscompu-
ter, Musikabspielgerät, Breitband-Internetzugang und Video- bzw. Fotokamera mit inte-
grierter Lasertastatur in einem sein.
Aus einem am 09. Dezember 2004 veröffentlichten Bericht der ITU geht hervor, dass
sich die Zahl der Mobilfunk-Abonnenten seit dem Jahr 2000 auf weltweit 1,48 Milliarden
verdoppelt hat. Damit übersteigt die Zahl der Mobilfunkteilnehmer die Zahl der Festnetz-
anschlüsse von Weltweit 1,18 Milliarden.
Der Mobilfunk reicht in die 20er Jahre zurück und wird seit der Entstehung des ersten
zivilen Funknetzes 1946 in den USA ständig weiterentwickelt6. Im Zusammenhang mit
meiner Arbeit sind aktuelle und zukünftige Entwicklungen von besonderer Bedeutung.
Seit 2002 das erste UMTS-Netz in Europa in Betrieb genommen wurde, ist für das Jahr
2005 ein Durchbruch dieser Technologie in Deutschland zu erwarten. Die erhöhte Über-
tragungsgeschwindigkeiten der Netze und die erhöhte Leistungsfähigkeit der Mobilfunk-
telefone erlauben nun die Übertragung von Videos. Eine Interaktion über das Internet ist
durch die vorhandene Netzstruktur bereits gegeben.
Erweiterungen der Übertragungsgeschwindigkeiten (z.B. HSDPA) dieser Mobilfunknet-
ze der sog. dritten Generation (3G) werden bereits entwickelt und getestet (vgl. Grafik
3.4). Die vierte Generation soll vollständig IP-basierend sein und somit nahtlos in die In-
frastruktur des Internets und anderer IP-basierter Funknetze (z.B. WLAN-Hotspots) inte-
griert werden.
Der Vorteil des Mobilfunktelefons liegt in seiner Mobilität, der großen Verbreitung, ein-
gebetteter interaktiver Telekommunikationsfähigkeit und steten Verfügbarkeit. Die Nach-
teile liegen im technischen Bereich. So zeichnen sich diese Endgeräte durch geringe Leis-
tungsfähigkeit und Speicherkapazität, kleine Bildschirme, meist teure oder langsame Da-
tenverbindungen oder limitierte Eingabemöglichkeiten aus.
6Vgl. Prof. Dr. Hogrefe, Vorlesung „Mobilkommunikation I“, 2003, Universität Göttingen
8

3 Analyse
3.1 Anforderungsanalyse
Die Anforderungsanalyse spielt für den Erfolg von Software-Projekten eine entscheidende
Rolle. Fehlende, ungenaue oder missverständliche Anforderungen haben oft kosteninten-
sive Nachbesserungen in späteren Projektphasen zur Folge und führen nicht selten zum
Scheitern von Projekten. Ziel der Anforderungsanalyse ist die Beschreibung eines Modells
der Anforderungen an das System. Dieses kann, im Rahmen nachfolgender Arbeiten, in
einzelnen Iterationsschritten jeweils erweitert, modifiziert, sowie mit Prioritäten versehen
werden. Ein Anforderungsprofil dient im Softwareengineering der Kommunikation zwi-
schen den unterschiedlichen Parteien im Entwicklungsprozess. Im Englischen wird auch
von „Requirements Engineering“ gesprochen und deutet auf eine ingenieurmäßige Ermitt-
lung und Verarbeitung von Anforderungen hin.
Die Anforderungen können sehr abstrakt (als Lastenheft) oder sehr konkret (als Pflich-
tenheft) formuliert sein, bis hin zu formalen Spezifikation. Mögliche Lösungswege werden
nicht aufgezeigt. So kann das Dokument, in Form eines kurzen Exposés, auch als Basis für
Ausschreibungen dienen. Als detailliertes Pflichtenheft können die Angaben als vertrag-
lich bindende Festlegung der Systemeigenschaften dienen.
Der folgende Entwurf der Anforderungen basiert auf geführten Dialogen mit den Ver-
antwortlichen und Mitarbeitern des Projektes „Jobs in Motion“ (JiM), Analysen der Ziel-
gruppe Jugend (vgl. [8; 9; 10; 11; 12; 13; 14; 15]) und Untersuchungen von Projekten im Be-
reich der Berufsinformation und Jugendkommunikation. Funktionalewie nicht-funktionale
Problembereichsanforderungen des Systems werden hierbei erörtert. Die Struktur der An-
forderungsanalyse basiert auf der DIN 66901 und dem „Lehrbuch für Software-Technik
1/2“ von Helmut Balzert[1].
3.1.1 Zielbestimmung
Die Ziele, die durch den Einsatz des Softwaresystems erreicht werden sollen, sind im Fol-
genden in drei Kategorien eingeteilt. Diese dienen der Übersicht der allgemeinen Zielbe-
stimmung des Projektes.
Muss-Kriterien Das Softwaresystem muss die Auswahl und den Zugang zu den Berufs-
informationsclips gewährleisten. Diese zwei bis drei minütigen Spots sind direkt, vollstän-
9

3 Analyse
dig und audio-visuell zu erschließen. In der endgültigen Ausbaustufe des Projektes „Jobs
in Motion“ ist eine Anzahl von 300 bis 500 Videoclips zu erwarten. Des Weiteren muss
eine differenzierte Auswahl nach unterschiedlichen Interessenschwerpunkte ermöglicht
werden.
Wunsch-Kriterien Einmöglichst direkter Zugriff auf regionale Ausbildungsangebote soll-
te ermöglicht werden. Ebenso ist eine Verknüpfung mit Angeboten der Bundesagentur für
Arbeit, Berufsverbänden und anderen Quellen wünschenswert. Die Evaluation der Nut-
zung des Gesamtkommunikationssystems sollte ermöglicht werden. So sind etwa statis-
tische Daten, aufgeschlüsselt nach gewählten Berufen, nach genutzter vertiefender Infor-
mation oder nach Regionen zu Auswertungszwecken zu erheben. Auch Umfragen zur
Qualität der Clips (Akzeptanz, Eignung, etc) sollten möglich sein.
Abgrenzungs-Kriterien Das Softwaresystem soll keine Lehrstellenbörse darstellen oder
diese ersetzen. Auch ist es nicht Ziel, differenzierte, sachliche Auskünfte über Berufsbilder
zu vermitteln. Dies soll, wie auch die Vermittlung von Lehrstellen, anderen existierenden
Systemen überlassen bleiben.
3.1.2 Produkt-Einsatz
Das zu entwickelnde Produkt soll auf modernen bzw. in naher Zukunft erscheinenden
Systemen zu Einsatz kommen. Die Generierung der Basisinformationen, also weiterer Vi-
deoclips, wird noch einige Zeit in Anspruch nehmen. Der voraussichtliche Einsatz der
Anwendung ist in ca. einem Jahr geplant.
Anwendungsgebiete Die Applikation soll im außerschulischen Umfeld, bzw. nicht di-
daktisch begleitet, eingesetzt werden. In möglichst vielen verschiedenen Umgebungen
(Unterwegs, zu Hause, ...) soll das Softwaresystem von der Zielgruppe autonom und frei-
willig genutzt werden. Ziel ist es, einen kommunikativen Effekt entstehen zu lassen, der
einen Impuls zur Weiterempfehlung der JiM-Clips und gemeinsamer Nutzung gibt. Die
Inhalte sollen mit neuester Technologie verknüpft werden.
Zielgruppen Die Hauptzielgruppe sind Jugendlichen zwischen 14 und 17 Jahren, die
einen Ausbildungsberuf anstreben. Auf diese technikaffine Gruppe ist das Produkt primär
zu entwickeln. An zweiter Stelle sind Jugendliche zwischen 18 und 21 von Interesse. Diese
sind in der Regel Schüler höherer Bildungsgänge, die vielfach ein Studium anstreben und
seltener einen Ausbildungsberuf suchen. Von geringerer Bedeutung sind Erwachsene, die
in Folge von Arbeitslosigkeit oder Umschulungsmaßnahmen auf Ausbildungssuche sind.
10

3 Analyse
Im Gegensatz zu den Anwendern stellen die Kooperationspartner (z.B. die BfA oder
Industrie- und Handelskammern) eine andere Zielgruppe dar, die ebenfalls in das System
einzubinden ist. Sie können zum Beispiel technische und inhaltliche Unterstützung bieten
und Angebote bereitstellen.
Betriebsbedingungen Das Softwareprodukt sollte flexibel genug sein, um in verschie-
denen Produktumgebungen genutzt werden zu können. Der Zugang zu den Videoclips
und weiteren Informationen sollte durchgängig und unbeaufsichtigt möglich sein. Kriti-
sche Systemkomponenten besitzt die Plattform aufgrund des gewählten Geschäftsmodells
nicht, und Ausfälle des Systems sind somit tolerierbar.
3.1.3 Produkt-Bedingungen
Software Die Auswahl der zu berücksichtigenden Softwaresysteme bestimmt sich nach
Kriterien der Verbreitung, Portabilität, Leistungsfähigkeit und Zukunftsperspektive. Zwi-
schen diesen Kriterien ist abzuschätzen. Das Ziel des Softwaresystems ist es, möglichst
viele Jugendliche zu erreichen und zielgruppengerecht ansprechen zu können. Dies be-
dingt eine möglichst barrierefreie Nutzung, d.h. nutzerseitige Lizenzkosten für Software
oder umständliche Installationen sind zu vermeiden.
Hardware Ähnlich zu den Rahmenbedingungen der zu nutzenden Software, müssen auch
hier Kriterien der Verbreitung, Leistungsfähigkeit und Zukunftsperspektive berücksichtigt
werden. Die Kosten der Anschaffung und Wartung der benötigten Hardware (aber auch
der Software) muss im Rahmen des geplanten Geschäftsmodells liegen oder ggf. ausgela-
gert werden. Die Interoperabilität zu den auf dem Markt befindlichen Hardwarekompo-
nenten von Kooperationspartnern und der Zielgruppe muss gewährleistet sein.
Organisatorische Rahmenbedingungen DasGeschäftsmodell zielt auf eine hohe Verbrei-
tung der Anwendung aus. Der Markt soll horizontal, nicht vertikal erschlossen werden.
Eine Refinanzierung des Systems durch die Zielgruppe ist nicht vorgesehen. Eine breitflä-
chige, möglichst hohe Nutzeranzahl legitimiert den Ausbau des Systems. Die laufenden
Betriebskosten sollen lediglich gedeckt werden. So kann der finanzielle Aufwand durch
die Einbindung von Providern für die Datenverbreitung oder von Sponsoren gesenkt wer-
den. Der Einsatz des Systems sollte möglichst geringe Kosten mit sich führen, dennoch
eine hohe Effizienz aufweisen. Das System sollte des Weiteren in hohen Maßen Betriebs-
sicher gestaltet sein. Die Nutzung des Systems basiert auf freiwilliger Basis und Ausfälle
können eine Frustration der Anwender zur Folge haben.
11

3 Analyse
Produkt-Schnittstellen Das Softwaresystem muss verschiedene Schnittstellen zu Koope-
rationspartnern und Zielgruppen zur Verfügung stellen (siehe Grafik 3.1). Die Anlieferung
von Inhalten, die Verknüpfung zu anderen Daten und Diensten, etwa zu Filterfunktionen,
und hauptsächlich die Schnittstelle zu den Anwendern müssen definiert sein. Die Attrak-
tivität der audio-visuellen Inhalte soll durch die technische Umsetzung unterstützt wer-
den. Durch Originalität der Lösung soll ein kommunikativer Effekt entstehen, der einen
Impuls zur Weiterempfehlung oder gemeinsamer Nutzung gibt. Dieser sollte in verschie-
denen Produktumgebungen entsprechend umgesetzt werden. Die Anbindung an Koope-
rationspartner muss einen möglichst problemfreien und system- und plattformunabhän-
gigen Dienst darstellen. Eine Kommunikation über spezifische Schnittstellen des Koope-
rationspartners sollten ebenfalls integrierbar sein. Eine Redaktionsschnittstelle, etwa zur
Sicherstellung der Integrität der Inhalte, sollte vorhanden sein. Je nach Auslagerung un-
terschiedlicher Funktionen an Kooperationspartner müssen über diese Schnittstelle auch
administrative Aufgaben zu erfüllen sein.
3.1.4 Produkt-Funktion
Die Funktionen, die das Produkt bieten soll, werden im Folgenden aufgelistet, deren Not-
wendigkeit begründet und die Anwendungsfälle aus Nutzersicht kurz beschrieben. Die
Abb. 3.1 stellt eine Übersicht als UML-Anwendungsfalldiagramm (Unified Modeling Lan-
guage). Mögliche Anwendungsfälle von verschiedenen Zielgruppen können sehr unter-
schiedlich sein.
Die Zahl der unterschiedlichen Anwendungsfälle kann im weiteren Verlauf der Ent-
wicklung ergänzt werden. Die verschiedenen Funktionen und Abläufe im System, die je-
der Anwendungsfall erfordern, sollten in diesem Zusammenhang ebenfalls mit einer Prio-
rität versehen werden.
3.1.4.1 Anwendungsfall: Unterhaltung
Die Hauptzielgruppe soll durch die Applikation zielgruppengerecht angesprochen wer-
den. Der unterhaltende Charakter der Videoclips soll auch durch die Benutzerschnittstelle
widergespiegelt werden.
(1.1) Die Videoclips sollten daher sofort und vollständig erschlossen werden können.
(1.2) Die Wahl weiterer Videoclips sollte so direkt wie möglich gestaltet sein.
(1.3) Um dem Anwender die Nutzung möglichst einfach zu machen, muss die Oberfläche
und Benutzerführung intuitiv gestaltet und eine Hilfe jederzeit erreichbar sein.
(1.4) Die Kommunikation mit dem Anwender sollte an sein persönliches Profil angepasst
werden können.
12

3 Analyse
(2.3) Priorisierung durch Marktbedarf. Die Verteilung bestimmt sich durch das Verhältnis
von Bewerbern zu offenen Stellen.
(2.4) Suche. Die Auswahl der Videos wird auf Basis eines flexiblen Verfahrens stufenweise
reduziert. Die Suchfunktion muss ebenfalls semantisch und syntaktisch verwandte
Begriffe berücksichtigen können.
Durch die Nutzung von Informationen über Anwender können weitere Filtermechanis-
men implementiert werden:
(3.1) Region. Berufe, die sich in der eigenen oder einer wählbaren Region befinden, kön-
nen besonders behandelt werden.
(3.2) Schulbildung. Berufe, welche eine höhere Vorbildung voraussetzen, könnenmarkiert
oder ausgefiltert werden.
(3.3) Interessen. Die Interessen des Anwenders sollten als Auswahlkriterium fungieren
können. In Verbindung mit Daten zur Schulbildung können diese Informationen mit
Hilfe passender Auswertungsstrukturen eine individuelle Auswahl passender Beru-
fe erreicht werden.
Indexierung. Anwender, die direkt nach bestimmten Berufen suchen, sollten die Mög-
lichkeit besitzen, auf den kompletten Datenbestand zugreifen zu können. Dieser Katalog
kann nach den o.g. Kriterien in Kategorien zusammengefasst und zusätzlich wie folgt ge-
ordnet sein:
(4.1) Alphabet. Die alphabetische Sortierung des Datenbestandes hilft dem schnellen Auf-
finden eines konkreten Berufes.
(4.2) Berufszweig. Die Sortierung von themenverwandten oder fachlich ähnlichen Berufen
ermöglicht ein „Durchstöbern“ von ganzen Berufszweigen.
Informationen. Zu jedem Videoclip sollten entsprechende Informationen hinterlegt sein,
die den Anwender im Entscheidungsprozess (z.B. die Bewerbung für Praktika) weiter un-
terstützen.
(5.1) Berufsbezeichnung. Der vollständige Name des Berufszweiges und die Fachrichtung
helfen dem Anwender weiterführende Informationen zu erhalten.
(5.2) Kurzbeschreibung. Die zielgruppengerechte Beschreibung des Berufes sollte die er-
haltenen Informationen aus dem Videoclip ergänzen.
14

3 Analyse
(5.3) Voraussetzungen. Die benötigten Voraussetzung, wie etwa eine bestimmte Schulbil-
dung, sollte festgehalten werden, um ggf. weitere Maßnahmen, wie die Bewerbung
bei Einrichtungen der Fort- und Weiterbildung, in Betracht ziehen zu können.
(5.4) Anzahl der Lehrstellen. Das Verhältnis von Bewerbern zu offenen Lehrstellen in dem
gewählten Beruf hilft, die Chancen einer Bewerbung einzuschätzen. Auch die Infor-
mation, welche Betriebe in welcher Region ein Ausbildungsplatz anbieten, ist von
hohem Interesse.
(5.5) Erfahrungsberichte. Berichte von Jugendlichen, die bereits eine Ausbildung in dem
gewählten Beruf gemacht haben oder sich in dieser noch befinden. Dies kann Jugend-
lichen zielgruppengerecht wertvolle Informationen liefern.
Kommunikation. Sind weitere Informationen über den Anwender bekannt, so können
diese Daten auf unterschiedliche Weise genutzt werden. Insbesondere für statistische Aus-
wertungen (interessant in Bezug auf die Finanzierung / Evaluation des Projektes) und die
Kontaktaufnahme sind folgende Punkte wichtig.
(6.1) Postadresse. Durch die Vor- und Zunamen kann eine persönliche Ansprache reali-
siert werden und durch die Adresse ist es möglich, den Anwender mit Institutionen
und Kooperationspartnern bekannt zu machen. Auch die Zusendung von Informa-
tionsmaterial über den Postweg ist möglich.
(6.2) E-Mailadresse. Eine schnelle und kostengünstige Kommunikation innerhalb des Sys-
tems und zu Kooperationspartnern ist möglich. So kann der Anwender per E-Mail
über Neuigkeiten, z.B. neue Berufsfelder, informiert werden.
(6.3) Mobilfunknummer. Auch die Kommunikation über Kurznachrichten auf das Mobil-
funktelefon ist eine zielgruppengerechte Option.
(6.4) Geschlecht. Das Geschlecht kann zusätzlich der persönlichen Ansprache und ggf. ei-
ner zielgruppengerechteren Kommunikation, etwa durch entsprechende Modifikati-
on der Benutzeroberfläche, dienen. Wie Gui Bensiepe vermerkte: "Das Design ist die
Domäne, in der die Interaktion zwischen Benutzer und Produkt strukturiert wird,
um effektive Handlungen zu ermöglichen"[16].
(6.5) Systemnutzung. Bereits betrachtete Videos, eine bewertende Umfrage zu diesen, die
Häufigkeit der Nutzung des Systems und andere Werte können statistischen Aus-
wertungen dienen.
15

3 Analyse
3.1.4.3 Anwendungsfall: Verwaltung
Die Verwaltung des Systems beinhaltet die technische Wartung, aber auch die Redaktion
von Inhalten. Beide müssen vor fremdem Zugriffen geschützt sein, bedingen jedoch unter-
schiedliche Anforderungen.
Administration. Der Betrieb eines durchgängig laufenden Systems bedarf einer techni-
schen Wartung und beinhaltet verschiedene Funktionen.
(7.1) Aktualisierung. Das System muss bei Anpassungen der Software auf den neuesten
Stand gebracht werden können.
(7.2) Sicherung. Die Daten müssen gesichert und wieder hergestellt werden können. Dies
gilt sowohl für Benutzerdaten, als auch für eigene Inhalte.
Redaktion. Nicht ausgelagerte Inhalte müssen regelmäßig auf ihre Richtigkeit und Ak-
tualität hin geprüft und ggf. modifiziert werden. Das content management system (CMS)
muss folgende Funktionen bereitstellen:
(8.1) Videos. Die Erneuerung oder Entfernung und die Einordnung in Kategorien von Vi-
deoclips.
(8.2) Inhalte. Die Änderung von Daten, Zahlen und Textinformationen und der automati-
sche Abgleich.
(8.3) Statistik. Die Verwaltung und Aufarbeitung statistischer Daten.
3.1.4.4 Anwendungsfall: Technische Unterstützung
Verschiedene technische Funktionen sollten an Kooperationspartner ausgelagert werden
können. Je nach Struktur dieser Funktionen sind entsprechende Schnittstellen zu definie-
ren.
(9.1) Distribution. Die Verteilung der Applikation und Anwendungsdaten sollen ausgela-
gert werden können.
(9.2) Funktionen. Die Auslagerung technischer Produktfunktionen, wie beispielsweise die
Analyse der Interessen des Anwenders oder die flexible Suche, sollten auch als Funk-
tionen von Kooperationspartnern eingebettet werden können.
16

3 Analyse
3.1.4.5 Anwendungsfall: Bereitstellung von Inhalten
Die Bereitstellung von Inhalten und Informationen, die selbst nicht redaktionell verwaltet
werden sollen oder können, müssen von Kooperationspartnern in das System integriert
und synchronisiert werden.
(10.1) Lehrstellen. Offenen Lehrstellen, Bewerberzahlen oder regionale Verteilung.
(10.2) Zusatzinformationen. Erfahrungsberichte Jugendlicher, veränderte Voraussetzun-
gen oder erweiterte Beschreibungen zu einzelnen Berufen.
3.1.4.6 Anwendungsfall: Bereitstellung von Angeboten
Wurde das Interesse an einem Berufsbild bei der Zielgruppe geweckt, müssen weitere
Schritte unternommen werden. Diese kann und soll die JiM-Plattform selbst nicht leisten
und werden entsprechend ausgelagert.
(11.1) Berufsberatung. Objektive, vollständige und ggf. persönliche Beratung durch frem-
de Institutionen. Ein entsprechender Verweis an diese Einrichtungen, wie etwa das
Berufsinformationszentrum der Bundesagentur für Arbeit.
(11.2) Fortbildung. Sollten die Bildungsvoraussetzungen des Anwenders für ein bestimm-
tes Berufsbild nicht ausreichen, so ist eine Weiterleitung an Institutionen zur Fort-
bildung zu gewährleisten. Auch unterstützende Angebote zu Vorbereitungen und
Abläufen bzgl. Bewerbungen sollten gegeben werden können.
(11.3) Arbeitgeber. Der direkte Kontakt zu Arbeitgebern, soweit von diesen gewünscht,
oder zu Berufsvermittlungsunternehmen.
3.1.5 Produkt-Leistung
Das Softwaresystem, als durchgängig betriebene Plattform, hat verschiedene Leistungsan-
forderungen zu entsprechen und leiten sich ebenfalls aus den Produktfunktionen ab.
(12.1) Erreichbarkeit. Das System sollte zu Stoßzeiten jederzeit erreichbar sein. Ein Ausfall
zu Wartungszwecken zu anderen Zeit ist möglich.
(12.2) Geschwindigkeit. Wartezeiten oder verzögerte Reaktionen sind so gering wie mög-
lich zu halten. Die Zielgruppe Jugend sind eine schnelle Kommunikation gewöhnt.
(12.3) Datenspeicherung. Persönlicher Daten und Nutzungsverhalten sind in persistenter
und temporärer Form zu speichern.
(12.4) Datenabgleich. Der Datenaustausch zuKooperationspartnern ist über definierte Schnitt-
stellen automatisch zu synchronisieren.
17

3 Analyse
3.1.6 Qualitäts-Zielbestimmung und Ergänzungen
Nicht-funktionale Qualitätsanforderungen, wie beispielsweise einzuhaltende Gesetze und
Normen, sind zu berücksichtigen und auszuformulieren.
3.2 Technische Analyse
Die technische Analyse bestimmt, welche Technologien den gegebenen Anforderungen
entsprechen. Die unterschiedlichen Lösungswege für ausgewählte Endgeräte (1.5), die in
den Grundlagen bereits angesprochenwurden, werden kurz beschrieben und in Bezug aus
ihre jeweilige Eignung hin untersucht. Die anschließende Systementwicklung basiert auf
dieser Analyse.
Viele der bereits technisch realisiertenDienste, wie zumBeispiel das digitale Radio (DAB),
mussten aufgrund zu geringer Akzeptanz als wenig erfolgsversprechend angesehen wer-
den. Insbesondere das sensible Thema der Berufsinformation und -orientierung für Ju-
gendliche bedarf einer genaueren Zielgruppenanalyse.
„The nice thing about standards is that you have so many to choose from; fur-
thermore, if you don’t like any of them, you can just wait for next year’s mo-
del.“ [Andrew S. Tanenbaum]
3.2.1 Videostreaming
Die vollständige (1.1) und insbesondere möglichst verzögerungsfreie (12.2) Erschließung
der Videoclips über das Internet erfordert die Aufbereitung der Informationen für das je-
weilige Endgerät und die Betrachtung des Datenstroms bereits während der Übertragung
(Streaming). Jeder Anwender kann hierbei einen eigenen Stream betrachten oder gemein-
sam mit mehreren Anwendern den selben Datenstrom.
3.2.1.1 Auflösung und Bildschirmgröße
Für die Betrachtung der Videos auf unterschiedlichen Endgeräten ist die Auflösung der
Videos ein wichtiges Kriterium für Qualität und Datenmenge. Die Bildschirmgröße und
-auflösung der Endgeräte kann stark variieren und die Videodaten sollten entsprechend
aufbereitet sein. Die Abbildung 3.2 verdeutlicht die Unterschiede der Auflösungen.
PC Die Ausgabemöglichkeiten des heimischen Computers sind am vielfältigsten. Als
Ausgabemedium können fast beliebige Bildschirme, und teilweise Bildschirmbrillen, an-
geschlossen werden. Die verfügbaren Auflösungen liegen meist zwischen 640x480 Pixel
(VGA) und 1600x1200 Pixel (UXGA).
18

3 Analyse
S
V
G
A

(
1
6
0
0
x
1
2
0
0
)
S
V
G
A

(
1
2
8
0

x

1
0
2
4
)
H
D
T
V
(
1
2
8
0

x
7
2
0
)
S
V
G
A
(
1
0
2
4

x

7
6
8
)
P
A
L
(
7
2
0

x

5
7
6
)
P
D
A
(
2
4
0

x

3
2
0
)
S
m
a
r
t
p
h
o
n
e
(
1
7
6

x

2
2
0
)
Abbildung 3.2: Vergleich verschiedener Auflösungen
STB Die STB sind in der Regel an handelsüblichen Fernsehgeräten angeschlossen, die in
ihrer Größe ebenfalls sehr unterschiedlich ausfallen können. Jedoch existieren verschiede-
ne Standards bzgl. der Auflösung der audio-visuellen Daten. PAL-Standardauflösungen
für ein Seitenverhältnis von 4:3 entspricht 720x576 Pixel, und die Entwicklung geht kon-
tinuierlich voran. Der HDTV-Standard, dem eine große Zukunft vorausgesagt wird, defi-
niert eine Auflösung von 1280x720 und 1920x1080 Pixel.
Mobilfunkgerät Die Auflösung, Farbtiefe und Größe sind z.Z. nicht standardisiert und
können in ihrer Leistungsfähigkeit stark variieren. Moderne Mobilfunktelefone besitzen
Bildschirmgrößen zwischen 1,5 Zoll und 3.5 Zoll und Auflösungen zwischen 160x160 Pi-
xel und 480x640 Pixel. Die Anzahl der maximal darzustellenden Farben liegt bei diesen
Geräten bei mindestens 65.536.
Das 3GPP (3rd Generation Partnership Project) ist eine weltweite Kooperation für die
Standardisierung im Mobilfunkbereich. Ziel des Projektes ist die Definition technischer
Spezifikationen für die herstellerunabhängige Nutzung von Mediadaten in Mobilfunknet-
zen. Die Abbildung 3.3 beschreibt die vom 3GPP definierte Architektur für multimediale
Inhalte. In diesem Zusammenhang sind u.a. entsprechende Standardauflösungen für Vide-
odateien empfohlen, wie beispielsweise 176x144 Pixel (QCIF) und 128x96 Pixel (subQCIF).
19

3 Analyse
Abbildung 3.3: 3GPP: Management multimedialer Inhalte [17]
3.2.1.2 Kompressionsverfahren
Aufgrund begrenzter Ressourcen und erhöhter Effektivität werden Audio- und Videoda-
ten zur Übertragung reduziert. Insbesondere für den Bereich des Videostreamings kom-
men je nach Anwendungsfall besondere Verfahren, sog. Codecs oder Kompressionsver-
fahren, zum Einsatz (vgl. [18]).
PC Die Auswahl der möglichen Kompressionsverfahren ist in diesem Fall die größte.
So unterstützen aktuelle Betriebssystem und Anwendungen eine Vielzahl verschiedener
Verfahren und neue Codecs können relativ problemlos nachinstalliert werden. So bieten
sich insbesondere die Verfahren Windows Media Video (WMV), MPEG-4 (MPG), RealVi-
deo (RM), Quicktime (QT), H.263 an. Diese zeichnen sich durch eine sehr gute Bildquali-
tät im Verhältnis zur geringen Dateigröße aus. Die ersten beiden werden durch Microsoft
Windows Betriebssysteme, die den Großteil des Endanwendermarktes abdecken, direkt
unterstützt.
STB Der DVB-Standard für digitales Fernsehen setzt für die terrestrische (DVB-T), kabel-
(DVB-C) und satellitengebunde (DVB-S) Übertragung den sog. MPEG-2-Standard fest, der
auf ähnliche Weise auch auf DVDs zum Einsatz kommt. Dieser wird trotz geringerer Effi-
20

3 Analyse
zienz daher von STBs standardmäßig unterstützt. Die Installation weiterer Codecs ist ggf.
möglich.
Mobilfunkgerät Das 3GP-Projekt (siehe Abb. 3.3) definiert das Kompressionsverfahren
H.263 und optional MPEG-4 als zu unterstützende Algorithmen für Mobilfunktelefone
der 3. Generation. Die Unterstützung anderer Codecs ist je nach Art des Endgerätes jedoch
möglich.
3.2.1.3 Übertragungsprotokolle
Das Streaming von Medieninhalten über das Internet erfolgt über sogenannte Streaming-
protokolle. Diese definieren die Kommunikation und Übertragung von Inhalten zwischen
zwei Parteien. In der vorliegendenArbeit ist einemöglichst verzögerungsfreie Betrachtung
von Videoinformationen von besonderer Relevanz. Daher ist die Beurteilung vorhandener
Streamingprotokolle wichtig.
HTTP Das Streaming über das „Hypertext Transfer Protocol“ (RFC 2616) hat den Vorteil,
dass das HTTP in fast allen internetfähigen Endgeräten bereits implementiert ist. Dieses
Protokoll wird zur Übertragung von WWW-Inhalten genutzt, setzt jedoch auf dem TCP
auf und unterliegt somit seinen typischen Nachteilen, wie einer großen Verzögerungszeit
und anfänglich langsamer Übertragungsgeschwindigkeit (sog. „slow-start“). Auch sind
keine Kontrollmöglichkeiten wie z.B. Vor- und Zurückspulen möglich, und seine Eigen-
schaft, garantiert fehlerfreie Daten zu übermitteln, wirkt sich nachteilig auf die Effizienz
der Übertragung von audio-visuellen Inhalten aus. Eine geringe Datenfehlerrate ist bei
Videostreaming tolerierbar.
RTSP Das „Real Time Streaming Protocol“ (RFC 2326) ist selbst kein Übertragungspro-
tokoll, sondern vielmehr ein offenes Steuerungsprotokoll für Streaminginhalte. Dies regelt
verschiedene Methoden zur Anzeige dieser Inhalte, wie etwa das Vor- und Zurückspulen.
Als Übertragungsprotokoll wird in der Regel das RTP „Real Time Protocol“ (RFC 1889)
genutzt. Dieses basiert auf dem UDP und unterliegt nicht den o.g. Schwächen des TCP.
Aufgrund der offenen Standardisierung der Protokolle werden diese häufig unterstützt
und empfohlen. So auch vom 3GPP.
MMS Das Protokoll „Microsoft Media Server“ ist wie RTSP ein Steuerungsprotokoll für
Media-Streaminginhalte und ist aufgrund der Marktdominanz der Firma Microsoft von
Bedeutung. Das Protokoll ist im Gegensatz zu den oben genannten nicht offengelegt, also
proprietär. Dies hat den Vorteil, dass nur auf schwierige Weise die Streaminginhalte durch
21

3 Analyse
fremde Programme abgegriffen werden und so datenschutzrechtlichen Aspekten besser
Rechnung getragen werden können.
3.2.2 Übertragungstechniken
Die o.g. Kompressionsverfahren arbeiten verlustbehaftet, d.h. während der Kodierung ge-
hen Informationen verloren. Die Qualität eines Videos ist abhängig von der Auflösung
und verwendeten Bitrate. Je geringer die Bitrate, also die Anzahl von Bits, die pro Zeit-
einheit benötigt werden um das Video anzuzeigen, desto mehr Informationen gehen bei
der Kompression und damit an Qualität verloren. Dies gilt ebenso für die Kompression
der akustischen Signale. Die Bitrate muss entsprechend an die Geschwindigkeit des ge-
nutzten Übertragungsmediums angepasst sein. Ist die Bitrate zu hoch, so kann das Video
nicht in Echtzeit während der Übertragung betrachtet werden. Es ist ein entsprechender
Eingabepuffer für die Informationen notwendig, der die Darstellung der Daten Verzögert.
Eine mit den o.g. Komprimierungsverfahren verkleinerte Videodatei mit Stereosignal
und einer Auflösung von 720x576 Pixel bzw. 320x240 Pixel benötigt für eine relativ hoch-
wertige Anzeige etwa 2000 kbit/s bzw. 300 kbit/s. Dieser Wert schwankt je nach Art des
Videos, genutztem Kompressionsverfahren und Qualitätsanspruch. Die Quelldateien der
vorliegenden Videos haben eine Auflösung von 720x576 Pixel und eine Bitrate von 30.000
kbit/s (DV-AVI / PAL).
Wichtig in diesem Zusammenhang ist daher die Übertragungsgeschwindigkeiten vom
Sender zum Endgerät, diese wird als Downlink (DL) bezeichnet.
3.2.2.1 PC und STB
Die Anbindung an das Internet herkömmlicher PCs und STBs sind sehr vielfältig und er-
folgt meist über das Telefonnetz (PSTN - Public Switched Telephone System). Der Down-
link (DL - Übertragungsrate vom Sender zum PC) liegt häufig bei 64 kbit/s (ISDN) oder ca.
1024 kbit/s (DSL). Insbesondere die stetig wachsende Zahl von DSL-Anschlüssen1 und die
Weiterentwicklung der kabellosen Netzwerkverbindungen (WiFi (IEEE 802.11) und Wi-
MAX (802.16)) deuten auf eine breitbandige Zukunft in diesem Segment hin. Aber auch
die Kombination von digitaler Fernsehausstrahlung und herkömmlichen Kommunikati-
onswege sind in diesem Zusammenhang interessant (siehe Abschnitt 3.2.2.3).
3.2.2.2 Mobilfunkgerät
Die Abbildung 3.4 (vgl. Abb. 3.5) gibt eine Übersicht über die Entwicklung verschiedener
mobiler Übertragungstechnologien. Die für die vorliegende Arbeit wichtigen Technologi-
1Pressemitteilung der Deutschen Telekom Januar 2004: Über 4 Mio. T-DSL Kunden, 40% Zuwachs zum Vor-
jahr.
22

3 Analyse
en werden im folgenden kurz beschrieben.
Abbildung 3.4: Entwicklung der Übertragungstechniken[19]
GSM Das Global System forMobile Communications (GSM) ist das erfolgreichste System
der heutigen Mobilfunkgeneration mit mehr ein einer Milliarde Nutzer. Es stellt den z.Z.
leitungsorientierten, digitalen, zellularenMobilfunkstandard dar, ist technische Grundlage
der deutschenD- und E-Netze undwird in über 200 Ländern genutzt. Der DL vonmaximal
14,4 kbit/s ist jedoch bei weitem zu gering für die Echtzeitübertragung von Videoinforma-
tionen. Auch die Erweiterung (HSCDSD) zu dieser Technologie kann theoretisch maximal
115,2 kbit/s übertragen. In der Praxis sind maximal 57,6 kbit/s möglich.
GPRS Das Global Packet Radio System ist eine Erweiterung des GSM-Standards für eine
schnellere Datenübertragung. Dieses System der Generation 2.5G ist imGegensatz zuGSM
bzw. HSCDSD paketorientiert und ermöglicht hiermit, Daten zu übertragen, ohne hierfür
eine Leitung komplett zu belegen. Bezahlt werden somit nur die tatsächlich übertragene
Datenmenge. Die meisten Mobilfunkgeräte sind heutzutage GRPS fähig. Der theoretisch
maximale DL liegt bei 171,2 kbit/s. Vorhandene Endgeräte unterstützen z.Z. jedoch ledig-
lich 53,6 kbit/s. Eine Erweiterung (EDGE) ermöglicht theoretisch einenmaximalen DL von
473,6 kbit/s. Aktuelle Endgeräte mit einem DL von 236,8 kbit/s sind bereits verfügbar.
UMTS Das Universal Mobile Telecommunications Systems gehört zu der dritten Mobil-
funkgeneration und erlaubt eine deutlich höhere Übertragungsgeschwindigkeit. Technisch
ist es nicht mehr mit dem GSM Standard kompatibel und benötigt den Bau einer neue
Infrastruktur. Der Wandel zu dieser Technik ist z.Z. auf dem Markt zu beobachten. Ein
theoretisch maximaler DL von 2.000 kbit/s ist bei eingeschränkter Mobilität (max. 10 m/s)
möglich. Aktuelle Geräte unterstützen einen DL von 364 kbit/s. Die UMTS-Erweiterung
23

3 Analyse
HSDPA gilt als Zwischenstufe zur nächsten Mobilfunkgeneration und kann theoretisch
einen maximalen DL von ca. 50 mbit/s zur Verfügung stellen. Erste Pilotprojekte werden
in Europa bereits realisiert.
WLAN Als WLAN (IEEE 802.11 oder 802.16) werden kabelfreie lokale Netzwerke be-
zeichnet, die häufig im privaten Bereich Anwendung finden. Derzeitig wird intensiv am
Ausbau vorhandener öffentlicher WLAN-Infrastrukturen gearbeitet und immer mehr öf-
fentlich Zugangspunkte („Hot-Spots“) werden erschlossen. Diese Infrastruktur gilt für
den Bereich der Datenübertragung als mögliche Konkurrenz oder Ergänzung des UMTS-
Mobilfunknetze. Der theoretisch maximale DL liegt bei etwa 54 mbit/s (WiFi) bzw. etwa
70 mibt/s (WiMAX)
3.2.2.3 Hybride Systeme
Aus der Annahme, dass die Kommunikation in interaktiven Multimedia-Diensten stark
asymmetrisch ausgeprägt ist, entstanden bereits einige Projekte zur Realisierung hybrider
System (vgl. DMB[20] und CISMUNDUS[21]). Bei einer asymmetrischen Kommunikation,
wie dem Videostreaming, folgt aus einer sehr kurze Anfrage des Nutzers die Aussendung
einer großen Datenmenge.
Abbildung 3.5: Übertragungstechniken im Vergleich[22]
24

3 Analyse
Abbildung 3.6: Übersicht der Sun Microsystems Java-Plattform
PC Im Bereich der Personal Computer kommt die Java 2 Standard Edition zum Einsatz,
die zusätzlich als sogenanntes Applet, eingebettet in den Internetbrowser des Benutzers,
gestartet werden kann.
STB Im Bereich der STB ist die DVB-MHP, Multimedia Home Platform, eine sehr in-
teressante Entwicklung. Die Plattform basiert auf Java (siehe Abb 3.7) und wurde bereits
im September 2000 vom ETSI verabschiedet. Die DVB-Gruppe hat die MHP entwickelt,
um auch in diesem Bereich einen einheitlichen Standard zu etablieren und eine horizon-
tale Marktentwicklung zu unterstützen. In einem Gespräch bestätigte Prof. Reimers7 vom
IRT Braunschweig die Arbeit an MHP-Versionen für Mobilfunkgeräte (MMP), Fahrzeuge
(MCP) und Blu-Ray-Disc. Ab der Version 1.1 ist diese durch die Erweiterung mittels des
Internet-Access- und Interactive-Broadcast-Profils auch in der Lage, mit Servern im Inter-
net zu kommunizieren.
Die MHP Referenz-Implementation8 (MHP-RI) des IRT Braunschweigs eignet sich zur
Entwicklung vonMHP-Applikationen unter Linux oderWindows. DieNutzung vonMHP-
7Dieser war und ist entscheidend an der Entwicklung der DVB-Technologien beteiligt
8hrefhttp://www.irt.de/IRT/produktehttp://www.irt.de/IRT/produkte
27

3 Analyse
Anwendungen ist auch über das Projekt MHP4Free9 möglich.
Abbildung 3.7: Aufbau der MHP-Architektur[24]
Mobilfunktelefon Die Java 2 Micro Edition ist eine Umsetzung der Java Technologie für
leistungsschwache (geringer Arbeitsspeicher, langsame CPU, ...) Endgeräte (siehe Abb.
3.8). Sie ist auf den meisten heutigen mobilen Endgeräten vorinstalliert. Inkompatibili-
täten unter verschiedenen Mobilfunkherstellern sollen mit der sogenannten „Java Powe-
red“10 Zertifizierung der Vergangenheit angehören. Durch Kombination der MIDP 2.0 und
MMAPI 1.1 ist es möglich, multimediale Anwendungen zu entwickeln. Durch den Zugriff
auf unterliegende Systemschnittstellen ist ein Streaming von entsprechenden Videoinfor-
mationen möglich. Auch existiert eine Unterstützung für das SVG-Dateiformat (Erweite-
rung JSR-226).
Das Sun J2ME Wireless Toolkit11 eignet sich als Entwicklungsumgebung zur Erstellung
von J2ME-Anwendungen.
9hrefhttp://www.mhp4free.dehttp://www.mhp4free.de
10hrefhttp://javaverified.comhttp://javaverified.com
11hrefhttp://java.sun.com/products/j2mewtoolkithttp://java.sun.com/products/j2mewtoolkit
28

3 Analyse
3.2.3.5 Kommunikationsplattform
Die Anforderungen an die Kommunikationsplattform sind andere als für Endgeräte. Wie
in den organisatorischen Rahmenbedingungen beschrieben, sollte der Einsatz des Systems
möglichst geringe Kosten mit sich führen, eine gewisse Ausfallsicherheit garantieren und
hohe Effizienz aufweisen.
Hardware Die einzusetzende Hardware bestimmt sich aus der Anzahl gleichzeitig zu-
greifenden Benutzer und des gewählten Streamingverfahrens. Die Plattform muss genü-
gend Rechenleistung aufbringen, um die entsprechenden Zugriffe und Videostreams zu
verwalten. Neben verschiedenen Hardwarearchitekturen haben sich x86-basierende Tech-
nologien (bekannt aus dem PC-Segment) als sehr günstige Variante herausgestellt.
Auch die Speicherung von Benutzerdaten, aber insbesondere der der Videodaten, setzt
eine entsprechend hohe Speicherkapazität voraus. So benötigt die Speicherung von 100
Videoclips in der Originalqualität (30 mbit/s, PAL) und einer durchschnittlichen Länge
von 2,5 Minuten etwa 56 Gigabyte (30/8 ∗ 60 ∗ 2.5 ∗ 100 = 56.250Megabyte).
Die Aufteilung verschiedener Aufgaben und Funktionen können auf unterschiedliche,
über ein Netzwerk verbundene Hardwarekomponenten aufgeteilt werden (9.1, 9.2). So
kann die Datenbank für Benutzerinformationen, die Speicherung der Videodateien und
die Kernapplikation auf unterschiedlichen Rechnern ausgelagert werden.
Software Marktbeherrschend im low-budget Marktsegment ist das sogenannte LAMP14-
System. Dies ist ein ein skalierbares und sehr preisgünstiges System, das verschiedene
quelltextoffene, marktbeherrschende Softwarekomponenten miteinander verbindet.
Die kostengünstige Basis stellt das Betriebssystem Linux (Alternativen sind Windows
und andere UNIX-Derivate) dar. Dieses ist für verschiedene Plattformen verfügbar und
wird insbesondere im Marktsegment der x86-Server eingesetz.
Der Apache HTTP-Webserver (Alternativen sind der Microsoft IIS oder Apache Tomcat)
dient der Bereitstellung vonWebinhalten und stellt eine Schnittstelle (CGI) zu unterschied-
lichen Programmiersprachen dar. Diese stellen den Kern der Applikation dar.
Sehr verbreitet in diesem Zusammenhang sind aufgrund ihrer Plattformunabhängigkeit
die Sprachen PHP, Perl oder Java bzw. JSP. Die Schnittstelle kann jedoch auch von weitaus
leistungsstärkeren Sprachen wie C++ genutzt werden.
Der Datenbankserver wird in dem o.g. System durch die Software MySQL realisiert (Al-
ternativen sind das ebenfalls kostenlose Postgres SQL oder kommerzielle DBMS von Mi-
crosoft oder Oracle). Das relationale Datenbankmodell ist mit Abstand das am weitesten
verbreitete. Auf diesem Modell basieren die meisten DBMS und zeichnen sich durch ihre
14Linux, Apache, MySQL, PHP
31

3 Analyse
Die redaktionelle (8.x) und administrative (7.x) Schnittstelle an das System kann eben-
falls über ein XML-Datenaustausch realisiert werden. Praktikabler ist jedoch vermutlich
der Einsatz einer Benutzeroberfläche über XHTML.
33

4 Design
Clie
nt
Ser
ver
Plat
tfor
m /
An
wen
dun
g
Flas
h
Bro
wse
r
Jav
a
wei
tere
...
Hau
ptzi
elgr
upp
e
Koo
per
atio
nsp
artn
er
Übe
rtra
gun
gste
chn
olog
ie
UMT
S
DVB
DSL
wei
tere
...
End
ger
ät /
Be
nut
zero
ber
fläc
he Ha
ndy
iTV
PC
wei
tere
...
Plat
tfor
m /
An
wen
dun
g MyS
QL
PHP
wei
tere
...
Sch
nitt
stel
len
Pro
prie
tär
XML
wei
tere
...
Übe
rtra
gun
gste
chn
olog
ie
Eth
ern
et
ATM
wei
tere
...
Fun
ktio
nen
Stre
ami
ng
RDM
S
wei
tere
...
Inte
rne
t
Abbildung 4.2: Abstraktionsschichten der JiM-Server-Client-Applikation
36

4 Design
der XML-Informationen und Erstellung der Benutzeroberfläche kann durch die Nutzung
der Laufzeitumgebung Java relativ portabel realisiert werden.
4.1.2 Übertragungstechnik
Die beidseitige Kommunikation zwischen den Servern und den Endgeräten wird über ei-
ne Anbindung an das Internet realisiert. Sie kann durch EDGE, UMTS, IEEE 802.11, IEEE
802.16 oder DSL erfolgen, die die benötigte Bandbreite für die Übertragung zur Verfügung
stellen. Die DVB-Technologie kann ergänzend für den Downlink genutzt werden, dies er-
laubt die Nutzung anderer schmalbandiger Übertragungstechnologien für den Uplink.
Die Anbindung der Server an das Internet benötigt eine deutlich höhere Bandbreite.
Vorausgesetzt, jeder Benutzer kann individuell und zu jeder Zeit einen beliebigen Videost-
ream starten (1.2), so ist je nach Menge gleichzeitig zugreifender Nutzer eine direkte Ver-
knüpfungen über IEEE 802.3 oder ATM an das Internet notwendig. Eine Alternative ist die
Möglichkeit, nur eine begrenzte Auswahl von Videostreams von den Benutzern abgreifen
zu lassen. Dies wäre wirtschaftlich eventuell rentabler, würde jedoch der Anforderung 1.2
widersprechen.
4.1.3 Server
Die benötigten Aufgaben werden auf unterschiedliche Komponenten aufgeteilt. Dies er-
möglicht eine skalierbare und leistungsfähige Bereitstellung (1.1, 12.1, 12.2) der Dienst-
leistungen. Je nach finanziellen Mitteln können sie jedoch auch problemlos auf der sel-
ben Hardware genutzt werden. Die Kommunikation der Komponenten erfolgt über das
Internetprotokoll (IP) und den jeweiligen benötigten Protokolle auf Transport- und An-
wendungsebene. So können Kooperationspartner jeweils die Funktion einzelner Server
übernehmen.
Datenbankserver Die zu speichernden Daten werden in einem relationalen Datenbank-
managementsystem (RDBMS) gespeichert. Dieses speichert sämtliche Informationen über
die Benutzer, Videos, Statistiken und aller anderen Inhalte. Aus datenschutzrechtlichen
Gründen sollte dieser Server dem eigenen Machtbereich unterstehen. Die Einsatz der kos-
tenlosen Software „MySQL“ ist denkbar.
Streamingserver Die Speicherung der Videodaten und deren Aufbereitung ist Aufgabe
dieses Servers. Aufgrund der kostenintensiven Distribution der Videos kann dieser gege-
benenfalls an Kooperationspartner ausgelagert werden (9.1). Der Server muss das Strea-
ming der Daten über HTTP und RTSP unterstützen. Für mobile Endgeräte ist eine Auflö-
sung der Videos von 320x240 Pixel und etwa 300 kbit/s, für andere Endgeräte eine Auf-
lösung von 640x480 Pixel und eine Bitrate von etwa 1000 kbit/s zu wählen. Die Kompri-
37

4 Design
mierung erfolgt jeweils über die 3GPP-Empfehlung. Der Einsatz der kostenlosen Software
„Darwin Streaming Server“ ist ein geeignetes Mittel zur Umsetzung.
Webserver Dieser Server bietet eine geschützte HTML-Schnittstelle für die Redaktion
und Administration. Er bietet über eine CGI-Schnittstelle die Möglichkeit, existierende
und eigene PHP-Applikationen zur Verwaltung einzusetzen. PHP hat sich als umfassen-
de und leistungsfähige Skriptsprache im Internet etabliert, und es existieren bereits viele
Applikationen zu Redaktions- und Verwaltungszwecken. Der „Apache Webserver“ und
Anwendungen wie „PHPMyAdmin“ sind kostenlose Lösungen.
Applikationsserver Auf diesen Server wird die entsprechende Applikation zur Kommu-
nikation mit den Endgeräten und Kooperationspartnern ausgelagert. Der Datenaustausch
erfolgt über definierte XML-Schnittstellen. Das Java-Servlet-System „Cocoon“ auf einem
„Apache Tomcat“ Server bietet sich hier als leistungsfähige und erweiterbare Lösung an.
Die Verbindung zum Datenbankserver erfolgt über eine direkte Schnittstelle, der JDBC.
Die Schnittstellen werden mit Hilfe von DTDs beschrieben.
4.1.4 Schnittstellen
Der Informationsaustausch zu Kooperationspartnern oder Anwendungssystemen erfolgt
im standardisierten Datenaustauschformat XML. Die Struktur der Daten ist jeweilig auf
den Kooperationspartner zu definieren. Der Einsatz von proprietären Formaten ist jedoch
auch möglich (12.4).
4.2 Modellierung
Die in der Anforderungsanalyse formulierten Produktfunktionen werden in der Modellie-
rungsphase vollständig in Bezug auf die zu speichernden Daten, benötigter Schnittstellen
und Programmklassen analysiert. Die Informationen werden mit geeigneten Werkzeugen
formal festgehalten und dienen als Basis für die Implementation.
4.2.1 Ausgewählte Produktleistungen
Im Rahmen dieser Arbeit werden lediglich exemplarisch einige Daten modelliert die zur
Herstellung eines Prototypen benötigt werden. Diese erheben keinen Anspruch auf Voll-
ständigkeit und müssen im weiteren Entwicklungsprozesses entsprechend der gegebenen
Anforderungen erweitert werdn.
38

4 Design
4.2.2 Datenhaltung
Die Speicherung von Informationen ist eine der Hauptaufgaben des Systems; eingesetzt
wird ein RDBMS. Die konzeptionelle Modellierung der Datenstrukturen erfolgt mit Hilfe
entsprechender Entity-Relationsship-Diagrammen (ER-Diagramme).
Nutzerdaten In Abbildung 4.3 ist ein Beispiel für die Speicherung von benötigten Nut-
zerdaten zu sehen.
user
idfirstnamename
mail
street
citycitycode
sex
password
birthyear
Abbildung 4.3: Modellierung der zu speichernden Benutzerdaten
Videodaten Die Abbildung 4.4 stellt ein ER-Diagramm zur Speicherung der Videodaten
dar.
4.2.3 Schnittstellen
Für die Funktionsfähigkeit der JiM-Plattform müssen mehrere XML-Schnittstellen zu Ko-
operationspartnern oder Anwendungssystemen definiert werden. Diesewerden durch den
Einsatz von DTDs beschrieben.
Anfrage an den Applikationsserver Die Struktur für eine Anfrage von einer Anwendung
des Benutzers an den Applikationsserver:
<?xml version="1.0" encoding="ISO-8859-1"?>
39

4 Design
video
id
name
description duration
field
streamname
Abbildung 4.4: Modellierung der zu speichernden Videodaten
<!--
/**
* Project : JIM :: DTDs
* Module : DTD for a request
*
* @author : Alexander Willner <mail@alexanderwillner.de>
* @version : Rapid Prototype
*/
-->
<!ELEMENT jim (action)>
<!ELEMENT action (type, name, password, option)>
<!ELEMENT type (#CDATA)>
<!ELEMENT name (#CDATA)>
<!ELEMENT password (#CDATA)>
<!ELEMENT option (#CDATA)>
Rückgabe von Informationen Wurden Informationen Beispielsweise über einen Videost-
ream angefordert, so sind diese Daten entsprechend zu strukturieren.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
/**
* Project : JIM :: DTDs
40

4 Design
* Module : DTDs for videofile request
*
* @author : Alexander Willner <mail@alexanderwillner.de>
* @version : Rapid Prototype
*/
-->
<!ELEMENT jim (name | field | descr | duration | streamname)>
<!ELEMENT name (#PCDATA)>
<!ATTLIST name
id ID #REQUIRED
>
<!ELEMENT field (#PCDATA)>
<!ELEMENT descr (#PCDATA)>
<!ELEMENT duration (#PCDATA)>
<!ELEMENT streamname (#PCDATA)>
4.2.4 Programmklassen
Für die Modellierung des Softwaresystems erfolgt sprachunabhängig mit Hilfe von UML-
Klassendiagrammen. Diese können automatisch in Quellcode einer Zielsprache umgewan-
delt werden und ergeben somit das Gerüst für die Implementierung.
Video-Klasse Die Abbildung 4.5 stellt einen Rohentwurf wie die Video-Klasse dar. Diese
hält die Informationen über einzelne Videoclips und kann weiterer Attribute und Metho-
den zur Verwaltung besitzen.
41

5 Implementierung
Die Quelltexte sind auf der beiliegenden CD-ROM zu finden.
5.1 Ziel der Implementierung
Das Ziel der Implementierung im Rahmen der vorliegenden Arbeit liegt im Ansatz des
„Rapid Prototyping“. In diesem Modell wird im allgemeinen das erworbene Wissen un-
mittelbar in einem Computerprogramm implementiert (vgl. [27]). Das „Rapid Prototy-
ping“ dient im Softwareentwicklungsprozess auch, den künftigen Nutzern eine Vorstel-
lung der Benutzeroberfläche und Bedienung zu geben. Die Implementierung soll die Er-
gebnisse der Analysen eranschaulichen. Nicht die Wiederverwendbarkeit einzelner Pro-
grammteile, sondern vielmehr der erste Eindruck steht hierbei im Vordergrund.
5.2 Technologie
Die Implementation basiert auf der Gesamtstruktur des JiM-Systementwurfes 4.1. Auf-
grund des gesetzten Zieles wurden in der Implementation jedoch teilweise zum Design
abweichende Technologien gentzt. Dies liegt darin begründet, dass die Implementation
auf vorhandenen Infrastrukturen aufgesetzt wurde und sich für den schnellen Entwurf
teilweise andere Plattformen besser eignen.
Endgerät Als Endgerät wurde ein PC mit installiertem Abspielprogramm für Macrome-
dia Flash gewählt. Die Anwendung simuliert die Oberfläche und Funktion eines interak-
tiven Fernsehgerätes mit einer Auflösung von 576x768 Pixel. Die Navigation erfolgt durch
Maus und Tastatur. Der Datenaustausch zwischen Anwednung und Applikationsserver
erfolgt HTTP-Requests mittels des URL Mime-Formates.
Übertragungstechnik. Ausgelegt ist das implementierte System auf einen Anschluss mit
einer Übertragungsgeschwindigkeit von mindestens 300 kbit/s.
Applikationsserver. Das System wurde auf Basis der Skriptsprache PHP realisiert. Die
Skripte werden über die CGI-Schnittstelle des Apache Webservers angesprochen.
43

5 Implementierung
(a) Das Fernsehbild gibt einen Hinweise auf ein
Zusatzangebot
(b) Sofort nach dem Start der Anwendung wird
das erste Video abgespielt
Abbildung 5.1: Der Start des Prototypen
(a) DasMenü stellt die unterschiedlichenMöglich-
keiten dar
(b) Die einzelnen Piktogramme geben Hinweise
auf ihre Funktion
Abbildung 5.2: Das Auswahlmenü des Prototypen
45

5 Implementierung
(a) Durch den Login ist es möglich persönliche Da-
ten zu speichern
(b) Die Daten wurden erfolgreich geladen
Abbildung 5.3: Der Login des Prototypen
(a) Informationen werden über das jeweilige Vi-
deo bereitgestellt
Abbildung 5.4: Die Informationsanzeige des Prototypen
46

5 Implementierung
Die Suche Die Suche nach bestimmten Begriffe (Abb. 5.5) ermöglicht das Auffinden von
Videoclips in der Datenbank.
(a) Die Suche ermöglicht eine schnelle Eingren-
zung der Clips
(b) Der Benutzer erhält zwei Ergebnisse zu seiner
Suchanfrage
Abbildung 5.5: Die Suche des Prototypen
47

7 Zusammenfassung und Ausblick
In der vorliegenden Arbeit wurde der Prototyp einer interaktiven Kommunikationsplatt-
form im Bereich der Berufsinformation für Jugendliche entwickelt. Dieser Prototyp imple-
mentiert ausgewählte Anwendungsfälle und kann für eine weitere Entwicklung als Basis
dienen. So bestehen z. Z. Verhandlungen zwischen dem Zentrum für interdisziplinäre Me-
dienwissenschaft und Kooperationspartnern aus der Wirtschaft, dieses System einzuset-
zen. Das Ergebnis dieser Verhandlungen wird bestimmte Rahmenbedingungen festsetzen,
die direkten Einfluss auf die zukünftige Systementwicklung haben werden und eine kon-
kretere Umsetzung zulassen. EineMöglichkeit der Umsetzung ist der Einsatz in modernen
UMTS-Mobilfunknetzen.
Eine besondere Herausforderung war die Integration und Berücksichtigung der Anfor-
derungen verschiedener Bereiche. Diese müssen mit zunehmender Konkretisierung des
Projektes bewertet und gewichtet werden. Daher wurden im Rahmen dieser Arbeit be-
reits viele Informationen im Bereich der Berufsinformation für Jugendliche gesammelt. So
wurden Jugendliche persönlich an einer Schule befragt, zahlreiche Studien zur Medien-
nutzung und Berufsinformation analysiert, juristische Aspekte untersucht und an einem
Pilotprojekt für die wirtschaftliche Nutzung von DVB-H mitgearbeitet.
49

Abkürzungsverzeichnis
3GPP . . . . . . . . . . . . . . . 3rd Generation Partnership Project
API . . . . . . . . . . . . . . . . . Application Programming Interface
CERN . . . . . . . . . . . . . . Centre Européan de Recherches Nucléaires
CGI . . . . . . . . . . . . . . . . . Common Gateway Interface
CISMUNDUS . . . . . . . Convergence of IP based Services for Mobile Users and Networks
in DVB-T and UMTS Systems.
DBMS . . . . . . . . . . . . . . Relational Data Base Management System
DMB . . . . . . . . . . . . . . . Digital Multimedia Broadcasting
DSL . . . . . . . . . . . . . . . . Digital Subscriber Line
DTD . . . . . . . . . . . . . . . . Document Type Definition
DVB-C . . . . . . . . . . . . . Digital Video Broadcasting - Cable
DVB-H . . . . . . . . . . . . . Digital Video Broadcasting - Handhelds
DVB-HTML . . . . . . . . Digital Video Broadcasting - HTML
DVB-J . . . . . . . . . . . . . . Digital Video Broadcasting - Java
DVB-MHP . . . . . . . . . . Digital Video Broadcasting - MHP
DVB-S . . . . . . . . . . . . . . Digital Video Broadcasting - Satellite
EDGE . . . . . . . . . . . . . . Enhanced Data for GSM Evolution
EPG . . . . . . . . . . . . . . . . Electronic Programme Guide
ETSI . . . . . . . . . . . . . . . . European Telecommunications Standards Institute
GPS . . . . . . . . . . . . . . . . Global Positioning System
GRPS . . . . . . . . . . . . . . . General Packet Radio Service
GSM . . . . . . . . . . . . . . . . Global System for Mobile Communications
GUI . . . . . . . . . . . . . . . . Graphical User Interface
HDTV . . . . . . . . . . . . . . High Density TeleVision
HSCDSD . . . . . . . . . . . High Speed Circuit Switched Data
HSDPA . . . . . . . . . . . . . High Speed Downlink Packet Access
HTML . . . . . . . . . . . . . . Hypertext Markup Language
HTTP . . . . . . . . . . . . . . . Hypertext Transfer Protocol
Internet . . . . . . . . . . . . . Interconnected Networks
IP . . . . . . . . . . . . . . . . . . Internet Protocol
IRT . . . . . . . . . . . . . . . . . Institut für Rundfunktechnik
50

7 Zusammenfassung und Ausblick
ISDN . . . . . . . . . . . . . . . Integrated Services Digital Network
ITU . . . . . . . . . . . . . . . . . International Telecommunication Union
J2ME . . . . . . . . . . . . . . . Java 2 Micro Edition
JiM . . . . . . . . . . . . . . . . . Jobs in Motion
MCP . . . . . . . . . . . . . . . . Multimedia Car Platform
MHP . . . . . . . . . . . . . . . Multimedia Home Platform
MHP-RI . . . . . . . . . . . . MHP-Reference Implementation
MIDP . . . . . . . . . . . . . . . Mobile Information Device Profile
MMAPI . . . . . . . . . . . . Mobile Media API
MMP . . . . . . . . . . . . . . . Multimedia Mobile Platform
MMS . . . . . . . . . . . . . . . Microsoft Media Server
MODEM . . . . . . . . . . . Modulator / Demodulator
PAL . . . . . . . . . . . . . . . . Phase Alternation Line
PC . . . . . . . . . . . . . . . . . . Personal Computer
PDA . . . . . . . . . . . . . . . . Personal Digital Assistant
PSTN . . . . . . . . . . . . . . . Public Switched Telephone Network
QCIF . . . . . . . . . . . . . . . Quarter Standard Image Format
RFC . . . . . . . . . . . . . . . . Request for Comments
SMIL . . . . . . . . . . . . . . . Synchronized Multimedia Integration Language
SQL . . . . . . . . . . . . . . . . Structured Query Language
STB . . . . . . . . . . . . . . . . . Set-Top-Box
SVG . . . . . . . . . . . . . . . . Scalable Vector Graphics
TCP . . . . . . . . . . . . . . . . Transmission Control Protocol
UDP . . . . . . . . . . . . . . . . User Datagram Protocol
UML . . . . . . . . . . . . . . . Unified Modeling Language
UMTS . . . . . . . . . . . . . . Universal Mobile Telecommunications Systems
WAP . . . . . . . . . . . . . . . Wireless Application Protocol
WiFi . . . . . . . . . . . . . . . . Wireless Fidelity
WiMAX . . . . . . . . . . . . Worldwide Interoperability for Microwave Access
WLAN . . . . . . . . . . . . . Wireless Local Area Network
WLL . . . . . . . . . . . . . . . . Wireless Local Loop
WML . . . . . . . . . . . . . . . Wireless Markup Language
WWW . . . . . . . . . . . . . . World Wide Web
XML . . . . . . . . . . . . . . . . Extensible Markup Language
51

Abbildungsverzeichnis
3.1 Übersicht verschiedener Anwendungsfälle als UML-Diagramm . . . . . . . 13
3.2 Vergleich verschiedener Auflösungen . . . . . . . . . . . . . . . . . . . . . . 19
3.3 3GPP: Management multimedialer Inhalte [17] . . . . . . . . . . . . . . . . . 20
3.4 Entwicklung der Übertragungstechniken[19] . . . . . . . . . . . . . . . . . . 23
3.5 Übertragungstechniken im Vergleich[22] . . . . . . . . . . . . . . . . . . . . . 24
3.6 Übersicht der Sun Microsystems Java-Plattform . . . . . . . . . . . . . . . . 27
3.7 Aufbau der MHP-Architektur[24] . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Aufbau der Java 2 Micro Edition[25] . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Übersicht der Systemarchitektur für das JiM-Projekt . . . . . . . . . . . . . . 35
4.2 Abstraktionsschichten der JiM-Server-Client-Applikation . . . . . . . . . . . 36
4.3 Modellierung der zu speichernden Benutzerdaten . . . . . . . . . . . . . . . 39
4.4 Modellierung der zu speichernden Videodaten . . . . . . . . . . . . . . . . . 40
4.5 UML-Diagramm für die Video-Klasse . . . . . . . . . . . . . . . . . . . . . . 42
5.1 Der Start des Prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Das Auswahlmenü des Prototypen . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Der Login des Prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Die Informationsanzeige des Prototypen . . . . . . . . . . . . . . . . . . . . . 46
5.5 Die Suche des Prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
52

Literaturverzeichnis
[14] Zinnecker J, u.a., Null Zoff und voll busy. Die erste Jugendgeneration des neuen Jahrhun-
derts. Leske + Budrich, Obladen, 2002.
[15] OECD, Pisa 2000. Deutsches PISA-Konsortium, 2000.
[16] F. Thissen, Kompendium Screendesign. Effektiv informieren und kommunizieren mit Multi-
media. X-media-press, 2003.
[17] N. technical papers, White Paper. Mobile Video Services - The next stop in mobility and
visual gratification. Nokia Corporation, 2003.
[18] S. Rieger, Streaming-Media und Multicasting in drahtlosen Netzwerken - Untersuchung
von Realisierungs- und Anwendungsmöglichkeiten. Gesellschaft für wissenschaftliche
Datenverarbeitung mbH Göttingen, 2003.
[19] Artur Lugmayr, Samuli Niiranen, Seppo Kalli, Digital Interactive TV and Metadata,
ser. Signals and Communication Technology, 2004.
[20] H. H. V. R. B. G. Wolfgang Klingenberg, Digital Media Broadcasting (DMB) in der An-
wendung Mobiles Intranet. Elektronik Report, 1999.
[21] M. B. et. al., Cismundus: Convergence of digital broadcast and mobile telecommunications.
Conference Publication, 2003.
[22] C. P. und Stefan Emilius, UMTS gegen WLAN - drahtlos oder Ratlos?, Juni 2004, t-
Systems Gastvortrag an der LMU-München.
[23] D.-I. G. May, Hybride Netzwerke mit „IP Datacast over DVB-H“. Paper, 2004.
[24] R. Sedlmeyer, Multimedia Home Platform - Standard 1.0.1. Sonderdruck aus Fernseh-
und Kino-Technik, 2001.
[25] K.-D. Schmatz, Java 2 Micro Edition. Dpunkt Verlag, 2004.
[26] A. Nussbaumer, A. Mistlbacher, XML Ent-Packt. mitp-Verlag, Bonn, 2002.
[27] G. G. et. al., Topics in Expert Systems Design. Elsevier Science Publisher, 1989.
[28] M. H. und Gerhard Leitner, “Usability von web-anwendungen.” in Web Engineering:
Systematische Entwicklung von Web-Anwendungen, 2003, pp. 265–296.
[29] M. Pol, T. Koomen, A. Spillner, Management und Optimierung des Testprozesses.
dpunkt-Verlag, 2002.
54

Danksagung
Ich möchte mich herzlich bei Prof. Schmidt und Martin Traub für ihr Vertrauen und ihre
Unterstützung bedanken.
Der Dank geht auch an Bernhard Többen der mich mit den richtigen Fragen stets vor-
wärts gebracht hat und Edith Werner für ihre Unterstützung. Und ganz besonders an mei-
ne Familie und Freunde die mir zu während der Bearbeitungszeit zur Seite gestanden ha-
ben.
55