Doku

Projektdokumentation ür die Studienveranstalt Studienveranstaltung ung “Sotware-Engineering “Sotware-Engineering Projekt“ Projekt“ I SS 2012 Modulleitung

Betreuer

Pro. Dr.-Ing. Heiko Tapken

Pro. Dr. rer. nat.Karsten Morisse Dipl.-In.. (FH), M.Sc. Benedikt Engelbert Dipl.-In

Teilnehmer

Maximilian Beckers 447109

Oliver Braun 391251

Julia Chatt 412539

Julia Dell 413942

Florian Gardewin 412503

Maximilian Staab 402602

Eduard Walter 402638

Dominik Werner 395380

Konstantin Wiesmann 397925

ZATTOO LIVE TV ZATTOO T V FÜR DAS OPEN SOURCE MEDIA CENTER XBMC

Inhaltsverzeichnis 1.

Das Sotware-Engineering Projekt 1.1. Augabenstel Augabenstellung lung 1.2. Autraggeber 1.3. Projektbeteil Projektbeteiligte igte 1.3.1. Mitgliederliste 1.3.2. Betreuer & Ansprechpartner 1.4. Motivation ür das Projekt 1.4.1. Entwicklungsteam 1.4.2. Zattoo

4 4 4 5 5 5 6 6 7

2.

Planung und Analyse 2.1. Pluginentwicklung: Anorderungen 2.1.1. XBMC 2.1.2. Zattoo 2.2. Vorgehe Vorgehensmodell: nsmodell: Scrum 2.2.1. Warum Scrum? 2.2.2. Tailoring 2.2.3. Rollenverteilung im Projektteam 2.2.4. Ablau / Arbeitsmeeting 2.3. Entwicklungsumgebung & Konventionen 2.3.1. Entwicklungsumgebung 2.3.2. Konventionen 2.4. Planung des XBMC-Plugins 2.4.1. Python 2.4.2. XBMC 2.4.3. Zattoo API - Testclient 2.4.4. ZAPI Funktionen 2.4.4.1. Session Handling Calls 2.4.4.2 . User and Product Management calls

8 8 9 12 12 12 13 14 16 16 16 17 19 19 20 23 24 24 25

3.

Usability

28

3.1.

Usability Test

28

3.2

Messbarkeit von Usability

28

3.3

Eye-Tracking

29


4.

GUI Konzeption

31

4.1.

Allgemeines

31

4.2.

Gestaltung / Umsetzung

31

4.2.1. Mockups

31

5.

Realisierung des XBMC-Plugins 5.1. Entwicklung eines Prototypen 5.2. Multilanguage 5.3. Login Funktionaität 5.4. Kanal Zapping 5.4.1. Umsetzung 5.4.2. Zurück-Spring-P Zurück-Spring-Problem roblem 5.4.3. Pro und Kontra, ob die Funktion beibehalten werden soll 5.5. XBMC-HLS Fork 5.5.1. Kompilierung 5.6. Spezizierung der Anorderunge Anorderungen n durch User Stories 5.6.1. Zeitstrahl und Sprints 5.6.2. User Stories und Sprint-Zuordnung 5.7. Sprintdetails

34 34 34 35 36 36 37 37 38 39 39 40 41 45

6.

Ausblick

46

7.

Fazit

47


1. Das Sotware-Engineering Projekt Das Modul Sotware-Engineering Sot ware-Engineering Projekt (olgend: (olgend: SWE-Projekt) ndet im ünten Semester des Studiums der Medieninormatik an der Hochschule Osnabrück statt. Das Modul soll die teilnehmenden Studierenden beähigen, ein reales Anwendungspr Anwendungsprojekt ojekt arbeitsteilig zu planen und innerhalb eines Teams zu realisieren. Die Veranstaltung unterteilt sich hierbei in einen Theorie- und einen Praxisteil. Häug werden externe Unternehmen als Partner ür das SWE-Projekt hinzugezogen. Für diese Unternehmen soll im Praxisteil eine spezische Anwendung entwickelt werden. Diese Dokumentation beasst sich mit dem Praxisteil des SWE-Projekts im Sommersemester 2012 mit dem Thema “Zattoo Live TV ür das Open Source Media Center XBMC”. XBMC”. Im olgenden Kapitel wird zuerst einmal das Projektumeld mit Mitgliedern, Betreuern, Ansprechpartnern und der jeweiligen Motivation, gerade dieses d ieses Projekt gewählt / angeboten zu haben beschrieben.

1.1. Augabenstellung Entwickelt werden soll eine Erweiterung ür die Open Source Media Center Sotware XBMC. Das Plugin soll es ermöglichen, live TV-Inhalte vom Internet TV Dienst Zattoo abzuruen und anzeigen zu lassen. Neben der eigentlichen Realisierung der Anwendung liegt in diesem Projekt ein besonderer Schwerpunkt in der Usability der zu entwickelnden Anwendung. Die Applikation sollte auch au einem großen Bildschirm übersichtlich und intuitiv autreten und auch mit eingeschränkten Interaktionswerkzeugen wie beispielsweise einer FünFün-TTasten-Fe asten-Fernbedienung rnbedienung gut bedienbar sein. Der Projektpartner Zattoo stellt den Zugri au ihre Streams über ein Application Programming Interace (olgend: API) zur Verügung. Verügung. Die ersten Schritte bei der Verwendung des API werden in einem gemeinsamen Workshop erarbeitet. Die Applikation soll nach ausührlichen Tests Tests in ein auslieerbares Format und an Zattoo übergeben werden.

1.2. Autraggeber Die Zattoo Europa AG ist eigenen Angaben zuolge mit über 10 Millionen Nutzern Europas ührender WebTV-Anbieter.

4


Zattoo bietet seine Streamingdienste in sechs Ländern an. Außer linearen Live TV stehen Nutzern in der Schweiz alle Sendungen der letzten drei Monate als Auzeichnung zur Verügung. Neben der Internetplattorm I nternetplattorm zattoo.com zattoo.com besteht Zattoos Geräte-Portolio aus Applikationen ür iOS, Android, Windows Windows Phone 7 und diversen Set-Top-Boxen Set-Top-Boxen und Smart T Vs.

1.3. Projektbeteiligte In diesem Abschnitt werden die Mitglieder, Betreuer und Schnittstellen untereinander untereinander im Rahmen des SWE-Projekts vorgestellt. vorgestellt.

1.3.1. Mitgliederliste Die unten abgebildete Mitgliederliste gibt einen Überblick über die am Projekt beteiligten Studenten und ihre Kontaktdaten: K ontaktdaten: N a me

Alter

Studiengang & E-Mail Semester

Maximilian Be Bernhard Be Beckers

24

MI6

[email protected]

Oliver Braun

27

MI6

[email protected]

Julia Chatt

26

MI7

[email protected]

Julia Dell

30

MI7

[email protected]

Florian Gardewin

27

MI7

[email protected]

Maximilian Staab

25

MI8

[email protected]

Eduard Walter

25

MI8

[email protected]

Dominik Werner

27

MI8

[email protected]

Konstantin Wiesmann

26

TI8

[email protected]

1.3.2. Betreuer & Ansprechpartner Neben dem studentischen Entwicklungsteam stellt die Hochschule jedem Projekt ein Team Team aus Betreuern zur Verügung, welche die Projektphase als Ansprechpartner ür das Entwicklungsteam begleiten und einen ordnungsgemäßen Ablau sicherstellen sollen.

5


Betreuer

Fachbereich

Pro.. Dr. Pro Dr. rer rer.. nat. nat. Karsten Karsten Morisse Morisse

Fakultät Ingen Fakultät Ingenieurwi ieurwissens ssenschat chaten en und und Inormati Inormatikk / Medieninormatik Medienlabor | eLCC | Projekt eCULT

Dipl.-In. (FH), M.Sc. Benedikt Dipl.-In. Engelbert

Für das Projekt “Zattoo “Zattoo Live TV ür das Open Source Media Center XBMC” besteht besteht die Gruppe der Betreuer aus: Neben den Betreuern gibt es bei Zattoo Zattoo selbst noch einen Ansprechpartner Ansprechpartner,, der ür den Zeitraum des Projekts als Schnittstelle zwischen Entwicklungsteam und Zattoo Europa AG dient: • Ralf Krutho-Brüwer, Krutho-Brüwer, Zattoo Europa AG

1.4. Motivation ür das Projekt In diesem Abschnitt wird kurz au die di e Motivation jedes Projektmitglieds nach der Leitrage “Warum haben Sie gerade dieses Projekt und kein anderes gewählt?” eingegangen. eingegangen. Danach soll auch die Motivation M otivation des Autraggebers Zattoo näher erläutert werden, ihre Inhalte über XBMC verügbar zu machen.

1.4.1. Entwicklungsteam N a me

Motivation

Maximilian Bernhard Beckers

• kennenlernen und einarbeiten in in Python • Erfahrungen mit Streaming und verarbeiten verarbeiten von Streams Streams • erste Erfahrungen von dem Entwickeln eines Produktes Produktes für ein “echtes” Unternehmen machen • Entwickeln eines Produktes Produktes in einer Gruppe • erste Erfahrungen in der Projektarbeit Projektarbeit / Leitung • Python • Streaming Techniken • “Echtes” Produkt entwickeln • Arbeiten im Team, Organisation • reales Projekt im Team für ein erfolgreiches und interessantes Unternehmen erarbeiten • Design & Usability Usability

Oliver Braun

Julia Chatt

6


Julia Dell

Florian Gardewin

Maximilian Staab

Eduard Walter

Dominik Werner

Konstantin Wiesmann

• neugierig durch Präsentation Präsentation von Zattoo im 2. Semester Semester • Design & Usability Usability • kennenlernen von von Python • arbeiten im Team • Erfahrungen im Projektmanagement Projektmanagement sammeln sammeln • kennenlernen von von Python • arbeiten im Team • erstes “echtes” Produkt entwickeln entwic keln • Interesse an Audio- und Videotechnik Videotechnik • Wissenserweiterung über Schnittstellen-T Schnittstellen-Technologien • Erweiterung der der Programmierfähigkeiten Programmierfähigkeiten • die perfekte Verbindung Verbindung aus Medien und Informatik • aktiver User des XBMC • Auseinandersetzung mit Python • Arbeit im größeren größeren Team Team kennen lernen • Mitarbeit an einem Produkt welches von tausenden Usern genutzt werden könnte • erste Erfahrungen im Projektmanagement sammeln • Generelles Interesse an Streamingdiensten Streamingdiensten • Auseinandersetzung mit Python • Ausliefer Auslieferung ung eines “realen Produktes”, Produktes”, kein Forschun Forschungsprojek gsprojektt / keine Machbarkeitsstudie • Usability • Mitarbeit an einem einem internationalen Softwareprojekt • erstes Projekt mit mehr als 3 Personen • Python

1.4.2. Zattoo Wie schon erwähnt besteht das Zattoo-Portolio neben der Onlineplattorm aus einer Vielzahl an Applikationen ür mobile Geräte, Set-Top-Boxen Set-Top-Boxen und Smart Smar t TVs. Generell olgt Zattoo hierbei einer Multi-Device-Strategie; Zattoo-Inhalte sollen dem Endkunden au möglichst vielen Plattormen so komortabel wie möglich zur Verügung gestellt werden. Die Media Center-An Center-Anwendung wendung XBMC olgt grundsätzlich einer sehr ähnlichen Strategie. Die aktuelle XBMC-Version steht beispielsweise plattormübergreiend ür Ubuntu/Linux, Windows und Mac OS X zur Verügung, zudem gibt es XBMC-Versionen ür das AppleTV2 und 7


neuerdings auch Portierungen ür den Raspberry Raspberr y Pi und die mobile Android-Plattorm. Durch die Vielzahl an Devices au denen XBMC zur Verügung steht, ist XBMC ür Zattoo eine sehr attraktive Anwendung, um das eigene Portolio auszuweiten. Aus dem Bereich Set-TopSet-TopBoxen ist gerade das AppleTV mit entsprechenden Anorderungen Anorderungen an das Interaktionsdesign I nteraktionsdesign als Zielplattorm sehr interessant, weshalb Zattoo ein entsprechendes Testdevice Testdevice ür das SWE-Projekt zur Verügung stellt.

2. Planung und Analyse In diesem Kapitel wird der Ansatz des Entwicklungsteams ür die Bearbeitung des SWEProjekts vorgestellt. Darunter allen das gewählte Vorgehensmodell Vorgehensmodell samt etwaigen Anpassungen an das Projekt, aber auch die d ie Beschreibung der Schnittstellen zu XBMC und Zattoo, genauso wie die eigentliche Konzeption und Planung des SWE-Projekts.

2.1. Pluginentwickl Pluginentwicklung: ung: Anorderungen Anorderungen Ein Plugin, quasi eine Schnittstelle zwischen zwei bestehenden Sotware-Systemen, bringt während der Entwicklung spezische Anorderungen mit sich, die in einem Sotwareprojekt, bei dem eine Stand-Alone-Applikation entwickelt werden soll, nicht unbedingt vorkommen.

Generell ist es so, dass bei der Pluginentwicklung die Flexibilität gegenüber Änderungen an den Applikationen, die über das Plugin verbunden werden sollen, die größte Herausorderung darstellt. Sowohl XBMC als auch Zattoo entwickeln ihre Sotware bzw. die entsprechenden Interaces nach außen kontinuierlich weiter, natürlich auch während der Entwicklungsphase dieses Projekts. Für die Planungsphase des Projekts hat dies zur Folge, dass die Inormationsbeschaung auwändiger gestaltet werden muss, da nicht nur ein einziges Mal Inormationen beschat werden, au deren Basis dann eine eine Sotware entwickelt wird, sondern in regelmäßigen InterIntervallen überprüt werden muss, ob sich nicht während der Entwicklungszeit grundlegende Abläue geändert haben.

8


Auch ür die Kommunikation untereinander stellt sich dadurch die Anorderung, dass geundene Änderungen schnellstmöglich innerhalb des Entwicklungsteams bekannt bek annt gemacht werden müssen und bestenalls direkt dokumentiert werden.

2.1.1. XBMC XBMC, rüher als Abkürzung ür “X-Box Media Center”, Center”, mittlerweile aber als Eigenname ohne tieeren Sinn verwendet, ist eine unter den Bestimmungen B estimmungen der Gnu General Public License (GPL v2) erhältliche, klassische Media Center Sotware ür einen PC bzw. HTPC - mittlerweile mittler weile auch ür Android und IOS. “Klassisch” bedeutet in diesem Zusammenhang, dass XBMC mit dem Ziel entwickelt wird, wi rd, den Nutzern das Abspielen von Videos, Musik, Bildern und anderen Mediendateien lokal, über ein Netzwerk oder über das Internet I nternet zu ermöglichen, üblicherweise an einem regulären regulären Fernseherr und gesteuert über eine Fernbedienun Fernsehe Fernbedienung. g. Die Funktionalität, ein Fernsehsignal über eine TV-Karte anzuzeigen bzw. ein lauendes TV-Programm anzuzeigen und auzunehmen, bietet XBMC derzeit (Stand 04.2012) nicht. Das XBMC-Team XBMC-Team hat kurz kur z nach Start Star t des SWE-Projekts eine neue Version ihrer Sotware veröentlicht, veröentl icht, XBMC Version 11.0 “Eden”. “Eden”. Diese wird als Basis ür die Plugin-Entwicklung verwendet. Die ür das Projekt relevanten Module innerhalb von von XBMC sind das Modul M odul GUI, das CORE-Modul und das Plugin-API. Im GUI-Modul wird das generelle Aussehen von XBMCPlugins anhand eines au WindowXML basierenden Frameworks über XML-Dateien gesteuert.

9


Aus dem weitgehend in C/C++ implementierten Core-Modul von XBMC ist ür das SWE-Pro jekt der Multimedia Video Player Player,, genannt “DVDPlayer” “DVDPlayer”,, relevant. DVDPlayer DVDPlayer wurde von von den XBMC-Entwicklern au Basis des Open Source Multimedia-Projekts FFMPEG entwickelt und stellt einen Cross-Plattorm-Player Cross-Plattorm-Player bereit, der in der Lage ist, alle momentan gebräuchlichen Audio- und Videoormate abzuspielen. Die Plugin-Schnittstelle von XBMC nutzt seit Release der Version 11 keinen selbst entwickelten Pythoninterpreter mehr. mehr. Es wird ein externer Python-Interpret Python-Interpreter er verwendet, der die Pythonversionen von von 2.4 auwärts (ohne Support von Python >= Version Version 3) unterstützt. Plugins selbst werden als Python-Script implementiert. Für die Plugin-Entwicklung selbst gibt es noch Anorderungen, die beachtet werden müssen, damit das entwickelte Plugin nach Auslieerung auch im oziellen Plugin-Repository von XBMC angenommen wird. Diese wären:

•

Alle Plugins müssen nach den im XBMC-Wiki beschriebenen Grundprinzipien entwickelt werden

•

Es muss jedem Plugin Plugin eine Lizenz-Datei beiliegen. XBMC empehlt empehlt hier die Creative GPL v. 2+-Lizenz ür Plugins

•

Alle Dateien müssen frei und legal sein

•

Die Plugins dürfen kein Copyright verletzen

•

Alle Quelldateien müssen mitgeliefert werden, keine pre-kompilierten Dateien

•

Das XBMC-T XBMC-Team behält behält sich das Recht vor vor,, das Plugin bei Bedarf zu aktualisieren aktualisieren oder zu enternen

•

Jedes Plugin hat seinen seinen eigenen Ordner und wird wird über eine XML-Dat XML-Datei ei mit Namen addon.xml beschrieben.

•

Jedes Plugin Plugin hat hat 2 Bilder als Referenz, einmal ein Icon, welches als Datei Datei icon.png icon.png mit den Dimensionen 256x256 Pixel zur Verügung Verügung gestellt werden muss und optional eine Datei anart.jpg, welche Fanart (Wallpape ( Wallpaperr etc.) zum Plugin enthält.

Für das SWE-Projekt ergeben sich außerdem einige wichtige Schnittstellen zur Inormationsbeschaung, die im Folgenden augeührt und kurz beschrieben werden:

10


•

XBMC Wiki: http://wiki.xbmc.org/

Das Wiki von XBMC wird von der XBMC Community und dem Entwicklungsteam gepfegt und dient dem SWE-Projektte SWE-Projektteam am als erste Anlaustelle ür Inormationen rund um das XBMC-Projekt. Dort sind unter anderem auch die Guidelines ür die Plugin-Entwicklung und einige entwicklungsspezische Themen wie zum Beispiel die Schnittstellen ür Plugins zum XBMC-Core dokumentiert. •

XBMC Forum: http://forum.xbmc.org/

Im Forum von XBMC können spezische Fragen zu XBMC-Funktionen gestellt werden. Für das SWE-Projekt wird ein Account Account ür das Forum Forum angelegt, um mit der XBMCCommunity in Kontakt treten zu können. Die Accountdate Accountdaten: n: • • •

Benut Ben utzzer erna name me::sw sweh ehso soss Passwor t: swe12!

XBMC IRC:

Eine weitere Kontaktmöglichkeit besteht über den Internet Relay Chat (IRC), in dem es einen eigenen Chatraum ür XBMC gibt. Auch dort kann man sich mit anderen PluginEntwicklern austauschen und Fragen stellen.

•

•

Adresse: http://webchat.freenode.net/

• •

Server: irc.freenode.net Raum: #xbmc oder #xbmc-scripting

XBMC Github-Repository:

Die XBMC-Quelldateien sind in einem mit dem Versionierungssystem Git erstellten Repository öentlich zugänglich. Das Repository erreicht man unter • ht http tps: s:// //gi gith thub ub.c .com/ om/xb xbmc/ mc/xb xbmc mc Dort kann bei Bedarf B edarf eine lokale Kopie aller Quelldateien heruntergeladen und bearbeitet werden.

11


2.1.2. Zattoo Auch Zattoo stellt den Zugri au ihre i hre Inhalte über ein API zur Verügung. Die einzelnen Funktionen des API sind ausührlich in einem in i n englischer Sprache verassten Wiki beschrieben. Das Wiki ist unter • http:/ http://devel /developer oper.zattoo .zattoo.com| .com|Usern Username:h ame:hso| so|Passw Password:H ord:Hs0Za s0ZaT!99 T!99

zu erreichen. Außer dem Zugri au das Wiki lässt Zattoo der Projektgruppe noch einen in Python geschriebenen Testclient Testclient zukommen, welcher die relevanten API-Methoden implementiert. Das API greit au eine Testumgebung, Testumgebung, die “Sandbox” “Sandbox” von Zattoo zurück, es wird also nicht mit dem eigentlichen Produktivsystem gearbeitet. Trotzdem Trotzdem stehen alle relevante relevanten n Funktionalitäten zur Verügung. Kontakt zu Zattoo besteht über den Ansprechpartner Ral Krutho-Brüwer. Dazu wurde vom Projektteam ein Skype-Account ür eventuelle Skype-Konerenz Skype -Konerenzen en angelegt: • Skype-Username: hsos-swprojekt | Passwort: xboxzatt00

2.2. Das Vorgehensmodel Vorgehensmodell: l: Scrum Das SWE-Projekt wird mit Hile des agilen Vorgehensmodells Vorgehensmodells Scrum durchgeührt, welches grundsätzlich au dem iterativ-inkremente iterativ-inkrementellen llen Vorgehensmodell Vorgehensmodell basiert. Im olgenden Abschnitt wird davon ausgegangen, dass der Leser mit den Grundzügen von Scrum vertraut ist.

2.2.1. Warum Scrum? Im theoretischen Teil der Veranstaltung Veranstaltung hat das Projektteam einige Vorgehensmodelle ür die Sotwareentwicklung kennengelernt. Gerade die dort angesprochenen agilen Methodiken und Ansätze erscheinen den Projektteil Projektteilnehmern nehmern durchaus sinnvoll und logisch. Da mit Ral Krutho-Brüwer ein direkter Ansprechpartner zur Verügung steht, der auch bereit ist, Zeit in das Projekt zu investieren, ist außerdem eine wichtige Anorderung ür agile Vorgehensmodelle Vorgehensmodelle - gute, kontinuierliche Kommunikation mit dem Kunden - erüllt.

12


Weiterhin ist die Ausgangssituation und somit die Zeitplanung ür das Projekt relativ unklar, da niemand der Projektteilnehmer bisher mit XBMC, der Zattoo-Programmierschnittstelle Zattoo-Programmierschnittstelle oder der Programmiersprache Python in Berührung gekommen ist. Daher kann eine genaue, Zeitplanung anangs nicht durchgeührt werden und keine Erolgsgarantie gegeben werden. Scrum beruht au der Ansicht, dass dies meist eh nicht der Fall ist, und versucht dieses Problem durch drei Grundprinzipien zu reduzieren, Transparenz, Transparenz, Überprüung und Anpassung: Der Projektortschritt und entsprechende Hindernisse sind immer ür alle Teilnehmer Teilnehmer sichtbar, in regelmäßigen Abständen werden Funktionalitäten Funktionalitäten gelieert und beurteilt und die Anorderungen werden werden nach jeder Lieerung neu beurteilt und bei Bedar Bedar  angepasst.

2.2.2. Tailoring Eine der Möglichkeiten, M öglichkeiten, die außerdem zur Wahl von Scrum als Vorgehensmodell Vorgehensmodell geührt haben, ist das Tailoring. Dies bedeutet vereinacht, dass ein Sotwareprojekt au die reellen Anorderungen zugeschnitten werden kann. Arteakte und Abläue, die nicht benötigt werden, werden aus dem Modell “herausgeschnitten” “herausgeschnitten” oder an die realen Gegebenheiten angepasst, um ein Projekt nicht durch unnötige, u nnötige, aber durch ein Vorgehensmodell vorgeschriebevorgeschriebene Dokumente o.ä. auzublähen. Da das Projektteam nur aus neun Mitgliedern besteht, sind olgende Anpassungen ür das Projekt nötig: •

Die Sprint-Zeit wird auf eine Woche festgelegt, mit anschließendem anschließendem Abschlussmeeting mit dem Zattoo-Ansprechpartner.

•

Die Rollen Rollen des Product Product Owners und des Scrum-Masters werden von einer Person (dem studentischen “Projektleiter”) “Projektleiter”) ausgeüllt.

•

Das Entwicklungsteam wird weiter in Arbeitsgruppen zu entsprechenden Unterbereichen der zu entwickelnden Anwendung unterteilt. Dabei ist diese Einteilung fexibel, d.h. je nach Augabenste Augabenstellung llung kann die di e Anzahl der Teammitglieder Teammitglieder variieren.

•

Eine Retrospektive wird nur bei Bedarf durchgeführt. durchgeführt. Generelle. nicht-technische Probleme werden werden soweit möglich direkt geklärt. geklär t.

•

Wenn Sprint-Ziele vor dem eigentlichen Ende einer Sprints erreicht erreicht werden, wird soweit möglich das Abschlussmeeting vorverlegt. Ansonsten wird mit den am sinnvollsten erscheinenden Arbeitspaketen weitergearbeitet.

13


•

Ein fester fester Arbeitstermin wird einmal einmal in der Woche angesetzt, bei Bedarf mehrmals die Woche. An diesem Termin wird das “Daily Scrum” ormell durchgeührt.

•

Durch die Nutzung Nutzung einer gemeinsamen Projektpla Projektplattform ttform (s. Abschnitt “Entwicklungsumgebung”) werden Arbeitsergebnisse kontinuierlich ür alle Teammitglieder Teammitglieder sicht- und überprübar estgehalten estgehalten..

•

Die teaminterne Kommunikation außerhalb außerhalb des Arbeitstermins soll in erster Linie über die Projektplattorm erolgen. Die Nutzung anderer Kommunikationsmittel (E-Mail, Messenger etc.) bleibt trotzdem erlaubt.

•

Jeder thematische Teilbereich des Projekts hat einen oder mehrere “Exper “Experten” ten” als ersten Ansprechpartner.

•

Wo sinnvoll, werden in der Veranstaltung kennengelernt kennengelerntee Entwick Entwicklungsprakt lungspraktiken iken wie Pair Programming angewendet.

•

Das Projektteam Projektteam versucht, den Zeitplan soweit zu straen, straen, dass während während der Klausurenphase im Semester keine weitere Arbeit am Projekt stattnden muss, damit das Projektteam sich in dieser Zeitspanne voll au anallende Klausuren konzentrieren konzentrieren kann.

•

Scrums Timeboxing-Prinzip für Sprints Sprints darf im Notfall durchbrochen werden, wenn z.B. der Ansprechpartner beim Kunden nicht zur Verügung steht. Dies kann k ann aber nur dann geschehen, wenn sich von beiden Seiten vorher au einen entsprechend kürzeren oder längeren Sprint geeinigt wird.

2.2.3. Rollenverteilung im Projekt Projekt Wie im Abschnitt Tailoring Tailoring erwähnt, wird das Projektteam in weitere Unterteams mit spezischen Augabenbereichen unterteilt. Die Augabenbereiche sind: • GU GUII-En Entw twic ickl klun ung g • Pl Plug ugin in-R -Real ealis isie ieru rung ng- -XB XBMC MC • Pl Plug ugin in-R -Real ealis isie ieru rung ng- -Za Zatt ttoo oo •

Generalisten

Das GUI-Team GUI-Team setzt dabei den Schwerpunkt au die Konzeption und Realisierung eines möglichst ansprechenden und intuitiven GUI- und Interaktionsdesigns. Das Team Team XBMCRealisierung setzt sich im Detail mit den von XBMC zur Verügung gestellten FunktionalitäFunktionalitäten auseinander. Das Team Team Zattoo-Realisierung entsprechend mit den von Zattoo zur Verügung gestellten Funktionalität Funktionalitäten. en. 14


Außerdem gibt es noch das Team Team Generalisten. Diese Gruppe wird besetzt von TeammitglieTeammitgliedern wie z.B. dem Product Owner/Scrum Master, der Augaben wie die Dokumentation der Meetings und generelles Projektmanagement Projektmanagement erüllen muss, trotzdem aber als Ansprechpartner bei Problemen zur Verügung Verügung steht und bei Bedar Bedar  und Zeit seine Arbeitskrat einem Team zur Verügung stellt. Auch sind in diesem Team die Projektmitglieder vertreten, die sich zum Zeitpunkt der Erstellung noch nicht genau einer Gruppe zuordnen wollten. ScrumMaster/ProductOwner:Diese beiden Rollen werden wie unter “Tailoring” “Tailoring” beschrie-

ben, von einer Person ausgeüllt. In I n diesem Projekt ist das der Projektleit Projektleiter er Dominik Werner. Werner. Team TeamGUI-Entwicklung:Unter Leitung von Oliver Braun als Experten besteht dieses Team aus Julia Chatt und Julia Dell, beides ausgebildete Mediengestalterinnen. TeamPlugin-Realisierung-XBMC:Neben Neben Maximilian Bernhard Beckers als Experten beas-

sen sich Eduard Walter und Florian Gardewin mit diesem Bereich. TeamPlugin-Realisierung-Zattoo:Da Da die Zattoo API gut dokumentiert ist, besteht dieses

Team nur aus Konstantin K onstantin Wiesmann, Wiesmann, welcher eng mit Maximilian Bernhard Beckers zusammenarbeitet. TeamGeneralisten:Neben Dominik Werner Werner ist hier noch Maximilian Staab als “Springer”

vertreten. Customer: Der Kunde ist in diesem Projekt Ral Krutho Brüwer in Vertretung ür Zattoo.

User:Die Benutzer-Rolle wird in diesem Projekt teilweise vom Projektteam Projektteam selbst, teilweise

von Zattoo-Mitarbeitern und ür z.B. Usability-Tests Usability-Tests auch von externen Personen übernommen. Geplant ist, die einzelnen Inkremente am Ende jeder Sprint-Woche an Zattoo zu übergeben, worauhin Ral Krutho-Brüwer dann Zattoo-intern Feedback einholt und dieses d em Projektteam zukommen lässt. Außerdem wird jedes neu implementierte Feature dem gesamten Projektteam vorgestellt und von diesem bewertet. Bei spezischen Tests Tests werden bei Bedar ausgewählte Studenten der Hochschule Osnabrück hinzugezogen. Management:Das Management besteht aus dem Projektbetreuer Pro. Dr. rer. nat. Karsten

Morisse und als erstem Ansprechpartner ür das Projektteam aus Dipl.-In. (FH) / M.Sc. Benedikt Engelbert.

15


2.2.4 . Ablau / Arbeitsmeeting Das Arbeitsmeeting ndet jeden Dienstag ganztägig ab 10 Uhr im Raum SD0005 der Hochschule Osnabrück statt. Zu Anang des Meetings steht die Inormationsphase oder auch das “Daily Scrum”. Scrum”. Jedes Teammitglied Teammitglied inormiert kurz über den derzeitigen Stand seiner Augabe, Hindernisse werden analysiert und bei Bedar B edar Generalisten oder Experten zu einem Team Team hinzugeügt, um diese zu bewältigen. Au Basis der hier gewonnenen Erkenntnisse Erkenntnisse wird dann die di e Vorbereitung Vorbereitung au das Meeting mit dem Kunden durchgeührt. Anschließend ndet eine Arbeitsphase statt, in der in den entsprechenden Teams Teams am Projekt gearbeitet wird. Je nach Terminvorgabe Terminvorgabe seitens des Kunden ndet entweder vor oder nach der Arbeitsphase das Meeting mit dem Kunden statt, in dem die Ergebnisse des letzten Sprints vorgestellt und analysiert werden und die User Stories ür den nächsten Sprint gesammelt werden. Danach ndet die Planung des nächsten Sprints statt. Zwischenmenschliche, nicht in erster Linie die zu entwickelnde Sotware Zwischenmenschliche, Sot ware betreende Hindernisse können während des Arbeitsmeetings oder auch per Mail im Einzelgespräch mit dem Scrum Master vorgetragen werden, welcher welcher sich dann um eine Lösung bemüht.

2.3. En Entw twic ickl klun ungs gsum umge gebu bung ng & Kon onve vent ntio ione nen n Im diesem Abschnitt werden einige vom Projektteam ür die gute Zusammenarbeit augestellte Konventionen angeührt angeührt und die Entwicklungsumgebung ür das Projekt vorgestellt. vorgestellt.

2.3.1.

Entwicklungsumgebung

Um zu den gleichen Ergebnissen zu kommen, soll im Projekt möglichst auch die di e gleiche Sotware zur Entwicklung eingesetzt werden. Dazu wird ein System ür die gemeinsame Datenhaltung benötigt. Anbei eine Liste mit der verwendeten Sotware: •

IDE: Eclipse Indigo, Version 3.7 •

installiertes PyDev-Eclipse-Plugin Version 2.4.0.201.202.0116

•

eGit zur Anbindung an das Versionierung Versionierungssystem ssystem

16


•

Versionierungssystem: Versionierungssy stem: Git

•

Python-Interpreter-Version: Python-Interpreter -Version: 2.7.2

•

Projektmanagement Projektmanage ment (Wiki, Ticketsystem): Redmine

•

Testumgebung: XBMC Version 11.0 “Eden” “Eden”,, Stable Sources

•

Datenhaltung: Redmine/Dropbox

•

Diagramme: LucidChart

2.3.2 .

Konventionen Konv entionen

Die in diesem Abschnitt olgenden Konventionen Konventionen wurden vom Scrum Master erstellt und gemeinsam mit dem Projektteam abgesegnet. Die Konventionen stehen unter olgendem Disclaimer des Scrum Masters:ww Disclaimer:

“MancheshiermageuchwiegesunderMenschenverstandvorkommen. KurzeAntwort:Istesauch. LangeAntwort:Istesauch.Erfahrungswertemeinerseitshabenabergezeigt,dassmangewisse Dingeliebereinmalfesthält,damitnichtdochirgendwerkommtundseineigenesSüppchen kochtunddamitallesinsChaosstürzt.Ichhoetrotzdem,dasProjektaufeinersehr „unbürokratischen“Ebenehaltenzukönnen. „unbürokratischen“Ebenehaltenzuk önnen.” ” • Ar Arbe beit itsm smee eeti ting ng

•

Generell besteht bei Arbeitsmeetings Anwesenhe Anwesenheitspicht. itspicht. Sollte ein Teammitglied keine Zeit haben, meldet es sich in angemessener Zeit vorher beim Scrum Master ab.

•

Jedes Meeting wird im Redmine-Wiki auf einer entsprechenden Seite protokolliert. Der Schritührer wechselt bei jedem Meeting.

•

Vor jedem Meeting wird vom Scrum Master eine Mail mit mit Raum, genauem Zeitpunkt und evtl. Inormationen über die Tagesordnung Tagesordnung an das Projektteam verschickt

•

Bei Diskussionen wird jede Meinung akzeptiert und der gerade Sprechende darf seinen Satz beenden.

17


• Vers ersion ionier ierung ung& &Tic Ticket ketsy syste stem m

•

Es wird Git als Versionierungssy Versionierungssystem stem genutzt.

•

Wenn ein Commit gepusht wird, werden Kommentare über gemachte Änderungen hinzugeügt.

•

Generell sollte jede Änderung an projektreleva projektrelevanten nten Dingen in einem eigenen Ticket estgehalten werden.

-

Allerdings insoern eingeschränkt, dass nicht jeder Rechtschreibe Rechtschreibehler hler in einem Kommentar ein eigenes Ticket erhält. Wird aber bestehende Funktionalität Funktional ität geändert, wird ein Ticket geschrieben/erweitert, damit jeder au der Aktivitätsseite des Redmine-Systems soort sehen kann, was sich geändert hat.

-

Keine Romane: Kurz und au den Punkt.

-

Grundsatz ür das Ticketing: Wenn es länger dauert, ein Ticket zu schreiben als es zu bearbeiten, schreib kein Ticket sondern mach.

• Proj ojek ektp tpla lanu nung ng

•

•

Erster Anlaufpunkt für die Projektplan Projektplanung ung ist das Redmine-Wiki. Alles was geplant wird, soll dort dor t estgehalten werden, damit das Projekt auch später “au “au einen Blick” erassbar ist.

•

Für (UML-)Diagr (UML-)Diagramme amme wird die Webapplikation LucidChart verwendet. Diese bietet die Möglichkeit, kollaborativ an Diagrammen zu arbeiten.

•

Anfallende Dokumente und Daten, die nicht versioniert werden, werden im Redmine-System oder alternativ im gemeinsamen Dropbox-Ordner hochgeladen.

Generelles

•

Der Arbeitsraum wird so verlassen wie er vorgefunden wird. An die aushängende Raumordnung wird sich gehalten.

18


2.4. Planung des XBMC-Plugins XBMC-Plugins In diesem Abschnitt wird au die spezische Planung ür das XBMC-Plugin eingegangen.

2.4.1. Python Für die Entwicklung des Plugins wird die Skriptsprache Python verwendet, da dies die Standard Programmiersprache der XBMC-Pluginschnittstelle ist. Da das Team vor Projektstart keinerlei Erahrung mit Python hatte, musses sich zunächst in die Syntax und Logik dieser Programmiersprache Programmiersp rache einarbeiten und die di e Grundlagen kennenlernen bevor mit der Entwicklung des Prototypen begonnen wird. Python ist eine Sprache, die im Hinblick au leicht verständliche Struktur und Syntax konzipiert wurde.In Python werden beispielsweise Scopes nicht wie aus anderen Programmiersprachen bekannt mit geschweiten Klammern deniert. Die Zuordnung zu einem Scope erolgt in Python über eine entsprechende Einrückung. An das Ende einer Anweisung wie zum Beispiel einer IF-Abrage wird ein Doppelpunkt gesetzt. Eine einache IF-gesteuerte Ausgabe könnte dementsprechend etwa wie olgt aussehen: ifi==1: print “Hallo World!” else print “ Welcome!”

Das XBMC-Plugin muss einige Daten aus der ZAPI auslesen und in XML-Dat XML-Dateien eien speichern, ebenso muss das Auslesen von JSON-ormatierten Daten über die di e ZAPI realisiert werden. Anstatt die Daten JSON-ormatiert auszulesen, könnte auch XML als Übertragungsormat herhalten, jedoch zeigen Perormance-Tests, Perormance-Tests, dass die d ie Geschwindigkeit der Datenübertragung sich durch Wahl von JSON deutlich steigert und somit die Navigierbarkeit bzw. Benutzerreundlichkeit innerhalb des Plugins wesentlich wesentlich verbessert werden kann.

19


Ist der grundsätzliche Aubau Pythons erst einmal verstanden und die wichtigsten Bibliotheken bekannt, ist der olgende Code-Ausschnitt aus dem Plugin zum Auslesen der Fa Favoriten voriten aus der entsprechenden XML-Datei XML-Datei keine Schwierigkeit mehr: 1. import xml.dom.minidom as xml 2. av_dir = xbmc.translateP xbmc.translatePath( ath( ‚special://prole/av ‚special://prole/avourites.xml‘ ourites.xml‘ ) 3. dom = xml.parse(av_dir) 4. nodeList = dom.getElementsByT dom.getElementsByTagName(„avourite“) agName(„avourite“) In der ersten Zeile dieses Code-Abschnitts wird die Bibliothek “xml.dom.minidom”, “xml.dom.minidom”, welche zum Auslesen der XML-Datei XML-Datei benötigt wird, importiert und über das Schlüsselwort as direkt als Variable xml initialisiert. In Zeile 2 wird der d er Pad zu der XML-Dat XML-Datei, ei, die die Fa Favoriten voriten des Benutzers enthält, relativ zu der Stelle im System an der das XBox Media Center installiert wurde, ausgelesen und in der Variable fav_dir gespeichert. Die dritte Zeile dient dazu, die in der Datei stehenden Datensätze über den vorher importierten XML-Parser XML-Parser in eine DOM-Hierarchie zu konvertieren und in der Variable dom abzuspeichern. Die letzte Zeile des Ausschnitts zeigt dann wie es möglich ist au die Daten zuzugreien. In diesem Fall werden alle -T -Tags ags aus der XML-Datei extrahiert und in der Variable nodeList gespeichert.

2.4.2. XBMC Alle Plugins, die innerhalb des XBox Media Centers installiert werden, sind in einem Verzeichnis namens xbmc/addons au der Festplatte organisiert. Je nach Betriebssystem kann der Ort dieses Verzeichnisses wechseln. Beim Betriebssystem OS X (Snow Leopard, 10.6.8) ndet sich der Ordner beispielsweise unter $HOME/Library/Application Support/XBMC/addons In dieses Verzeichnis kann bei Bedar auch per Hand ein selbst erstelltes Plugin-Verzeichnis Plugin-Verzeichnis eingeügt werden.

20


Au obigem Bild sieht man die Struktur des Plugins. Jedes Plugin in XBMC muss über ein Skript namens addon.py verügen, welches als “Main”-Klasse des Plugins dient. Weiterhin muss innerhalb der addon.xml das Plugin spezisch beschrieben werden. Weiter Weiter gibt es noch einen Ordner resources, in dem sich beispielsweise eingebundene, externe Bibliotheken oder auch die settings.xml mit den Einstellungen des Plugins innerhalb von XBMC bendet. XBMC stellt dem Programmie Programmierer rer drei wichtige Schnittstellen zur Verügung. Dies sind xbmcgui, xbmcplugin und xbmcaddon. Im weiteren wird genauer au diese Schnittstellen eingegangen und erklärt ür welche Funktionalität Funktionalität diese in dem Plugin verwendet werden. Die Schnittstelle xbmcgui ist, wie es der Name schon andeutet, ür die Umsetzung eines Graphical User Interaces innerhalb des Plugins zu verwenden. Über diese Schnittstelle lassen sich beispielsweise Fehle Fehlermeldungen rmeldungen in Form eines Dialogensters darstellen, wie es unter anderem bei der Fehlerüberprüung des Loginmoduls angewendet wird. 21


Um den Umgang mit dieser Schnittstelle zu verdeutlichen, soll der olgende Code-Ausschnitt einen kleinen Einblick geben. dialog = xbmcgui.Dialog() dialog.ok(pluginLanguage(40091), pluginLanguage(40099)+“:\n“+pluginLanguage(login._errormessage))

In der ersten Zeile wird ein Objekt vom Typ xbmcgui.Dialog angelegt. Die zweite Zeile zeigt dann wie ein Dialog mit einem “OK”-Button angelegt wird. Dieser bekommt lediglich zwei Strings übergeben, die in dem hier angeührten Beispiel noch entsprechend der im Media Center eingestellten eingestellten Sprache und anhand des beim Login entstandenen Fehlertyps dynamisch angepasst werden. Ebenalls eine sehr wichtige Schnittstelle bei der Entwickelung des d es XBMC-Plugins ist xbmcplugin. Mit Hile dieser Bibliothek werden die Listen erstellt durch welche das Plugin dargestellt wird und in welchen auch die Streams visualisiert werden. Die Listen lassen sich entsprechend des ausgewählten XBMC-Skins in unterschiedlichen Ansichten darstellen. Die Erstellung der Listen selbst wird über die Schnittstelle xbmcplugin gesteuert, die einzelnen Listenelemente selbst dagegen über die Schnittstelle xbmcgui. Zur Verdeutlichung Verdeutlichung olgt der Aubau der Listenelemente innerhalb des Plugins: # Liste ür alle Channels listItem = xbmcgui.ListItem(pluginLanguage(50003)) listItem.setProperty(‚Folder‘, ‚true‘) xbmcplugin.addDirectoryItem(thisPlugin, sys.argv[0] + ‚?clist=all‘, listItem, datalen) . . . xbmcplugin.endODirectory(thisPlugin)

22


Die FunktionaddDirectoryItem() in obigem Beispiel dient dazu, ein neues Element in der Liste anzulegen. Mit dem Übergabeparamet Übergabeparameter er thisPlugin wird die ID der aktuellen Plugininstanz übergeben. Der nächste Parameter bezeichnet die URL die augeruen wird, wenn ein Benutzer das Listenelement auswählt. In diesem Beispiel wird ein Parameter per GET übergeben um die entsprechende Funktion Funktion beim Auru auswählen zu können, da XBMC bei jedem Vorgang die addon.py (die eingestellte “Main-Klasse”) neu mit den entsprechenden Parametern aurut. Der olgende Parameter bezeichnet die Funktion des Listenelements als listItem, welches in den vorherigen Zeilen angelegt und als Ordner deniert worden ist. Der letzte Parameter ist optional und gibt die Anzahl der Listenelemente an um beim Laden einer Liste einen Fortschrittsbalken anzeigen zu können. Ist die Erstellung einer Liste beendet, wird die Methode endOfDirectory()mit der ID des Plugins augeruen. augeruen. Damit wird signalisiert, dass die di e Liste an genau diesem Punkt abgeschlossen und ertig erstellt wurde. Die letzte von XBMC gestellte Schnittstelle ist xbmcaddon. Diese Schnittstelle wurde in dem Plugin lediglich an einer Stelle genutzt, um au die Settings des Plugins, welche in einer XMLDatei namens settings.xml im Plugin-Ordner abgespeichert werden müssen, zugreien zu können: settings = xbmcaddon.Addon(id=‘plugin.video.zattoo‘)

Hier wird das Plugin über seine ID, welche in diesem Fall den Namen des Ordners im PluginVerzeichnis von XBMC bezeichnet, ausgewählt, um dann au die Inhalte der XML-Datei zugreien zu können.

2.4.3.

Zattoo API - Testclient Testclient

Von Zattoo wurde zu Anang des Projekts ein Python Skript Sk ript gestellt, welches die wesentlichen Schnittstellen der ZAPI testweise beschrieben hat. ZAPI-Methoden wie Login, Logout, Senderliste abruen, oder auch das Anordern einer aktuellen Stream URL ür einen TestsenTestsender konnten damit in Python augeruen werden. werden. Dadurch war eine unktionierende Python Bibliothek verügbar welche im Plugin weiter verwendet werden konnte.

23


2.4.4.

ZAPI Funktionen

Wie in Kapitel 2 bereits erwähnt, stellt Zattoo ein Interace ür direkten Zugang zu seinem Angebot Namens ZAPI. Neben dem Verweis au die ausührliche Dokumentation unter http://developer.zattoo.comseien hier die im Plugin verwendeten ZAPI-Funktionen beschrieben. Die Kommunikation mit der ZAPI im Allgemeinen ist der sogenannte „API call“ und geschieht via HTTPS HTT PS GET oder POST POST,, Parameter können als UrlEncodedForm UrlEncodedForm Entität mitgesendet werden. Die ZAPI erwidert einen Call mit einer Response im XML- oder JSON-Format JSON-Format (in diesem Plugin wird das JSON-Format augrund besserer Perormanceer Perormanceergebnissen gebnissen verwendet).

2.4.4.1. Session Handling Calls (Hello, Get Session, Update Session, General Terms, Terms, Privacy Policy Policy,, Goodbye) POST to https://HOST/zapi/session/hello Der „Hello“-Request startet eine Session und muss zu Beginn jedes Verbindungsaubaus zwischen App und ZAPI gesendet werden. Der Auru erolgt mit POST to https://HOST/zapi/ session/hello. Als Parameter müssen die „unique App ID“ (app_tid), die Geräte-UUID (uuid), und die Sprache (lang) übergeben werden. Desweiteren kann optional das Format (ormat: XML oder JSON), der Geräte-T Geräte-Typ yp (device_type; nur ür mobile Geräte), die aktuelle Version (app_version) sowie die Aufösung der „thumbnails“ „thumbnails“ (live_thumbs, program_thumbs) übergeben werden. Als Response wird ein Session Ino Objekt Objekt empangen. GET to https://HOST/zapi/session Mit einem „Get Session“ –Request können Inormationen einer bestehenden Session erneuet abgeruen werden. Der Auru ist Parameterlos und hat als Response ebenalls ein Session Ino Objekt. https://HOST/zapi/session/update Zum Ändern bestimmter Attribute (insb. der Sprache) einer Session wird der „Update Session“-Request benutzt. Der Auru erolgt mit POSTto und dem entsprechenden Parameter. Parameter. Auch hier wird wieder wi eder ein Session Ino Objekt zurückgegeben.

24


GET to https://HOST/zapi/general_te https://HOST/zapi/general_terms rms GET to https://HOST/zapi/privacy_policy Um die allgemeinen Geschätsbedingungen(General Geschätsbedingungen(General Terms) Terms) oder die Datenschutzrichtlinien (Privacy Policy) abzuruen, können der „Get General Terms“Terms“- oder der „Get Privacy Policy“Request gesendet werden. Das kann unter Umständen dann notwendig sein, wenn diese nicht wie üblich über die Website angezeigt angezeigt werden können. Sie werden innerhalb der jeweiligen Response als einache Textobjekte Textobjekte übermittelt. Die Aurue lauten GET to https://HOST/ zapi/general_terms und GET to https://HOST/zapi/privacy_policy POST to https://HOST/zapi/session/goodbye Der Goodbye-Request ist das Gegenstück zum „Hello“ und sollte nach Möglichkeit zum Trennen Tren nen der Verbindung zum Server genutzt werden.

2.4.4.2. User and Product Management calls (Create Account, Login, Get Account, Update Account, Forgot Password, Password, Get Catalog, Get Account Token, Logout) POST to https://HOST/zapi/account/new Die User and Product Management M anagement calls sind größtenteils selbsterklärend. Mit dem „Create „Create Account“-Beehl kann ein neuer Zattoo Account erstellt werden. Eine gültige Email-Adresse und ein Passwort müssen dem Auru als Parameter mit übergeben werden. POST to https://HOST/zapi/account/login Mittels Login wird der entsprechende User angemeldet (richtiger Login und Passwort vorausgesetzt). GET https://HOST/zapi/account Mit Get Account können Inormationen über den eingeloggten User erhalten werden. Die Response ist ist in Form eines Account Ino Objekts POST to https://HOST/zapi/account/update

25


Update Account ermöglicht das Ändern der Userdaten Login und Passwort (müssen als Parameter übergeben werden) https://HOST/zapi/orgot-password Der “Forgot “Forgot Password”-Request ermöglicht das Senden eines neuen Passwortes an die entsprechende Email-Adresse. Email-Adresse. Hier ist der Auru sowohl mit GET als auch mit POST möglich. GET https://HOST/zapi/catalog Für den User verügbare Premium-Angebote von Zattoo werden mit dem Beehl „Get Catalog“ abgeruen. GET https://HOST/zapi/catalog GET https://HOST/zapi/account/toke https://HOST/zapi/account/token n Um direkt über die ZAPI Premium-Angebote Premium-Angebote zu kauen, wird ein Token Token benötigt, der mit “Get Account Token” angeordert werden kann. POST to https://HOST/zapi/account/logout “Logout” meldet meldet den Zattoo Account ab und trennt ihn von der Session. Channels,EPGDataandPlaylistcalls

(Get Channels, Guide, Search, S earch, ProgramDetails) GET https://HOST/zapi/channels Der “Get Channels”-Request wird genutzt, um eine Liste der verügbaren Sender zu erhalten (Channel List). Diese ist abhängig vom Login-Status des Users, seinem Account (zb. Premium) und seiner GeoIP. GET https://HOST/zapi/program/guide Der “Guide”-Request “Guide”-Request wird gesendet um Inormationen über das Fernseh Fernsehprogramm programm im EPG-Format zu erhalten. Die Response ist vom Typ Guide Ino und kann durch entsprechende Parameter eingegrenzt werden (Zeit oder Sender). GET https://HOST/zapi/program/se https://HOST/zapi/program/search arch Der “Search”-Request “Search”-Request ist eine Erweiterung Er weiterung des “Guide”-Request “Guide”-Request und durchsucht den EPG nach weiteren (spezielleren) (spezielleren) Kriterien. Zusätzlich kann nach dem Namen der Sendung S endung (title), dem Namen der Episode (episode_title) sowie weiteren Kriterien gesucht werden. Die Search Response enthält eine Liste von Sendern GET https://HOST/zapi/program/details 26


Mit dem “Program Details”-Request können weitere Details zum Programm des als Parameter übermittelten Senders abgeruen werden. LiveChannelsandRecordedProgramscalls

(Watch, Stop) POST to https://HOST/zapi/watch Der “Watch”-Request “Watch”-Request lieert die URL zum eigentlichen Inhalt (Livestream oder augenommene Sendungen). Neben dem benötigten Parameter stream_type (eindeutige ID des Streams) sind weitere optionale Parameter möglich: -

Recording_id: Zum Anschauen augenommener Streams aus einer Playlist

-

cid, start, end: end: Sender, Sender, Start- und Endzeit von augenommenen Streams

-

cid: Sender-Id zum Anschauen von Livestreams

Zusätzlich können eine minimale und/oder maximale Datenrate übermittelt werden, die jedoch nicht zwingend von Zattoo berücksichtigt berücksichtigt werden. POST to https://HOST/zapi/stop Sendet ein Stoppsignal an den Server, dass der Inhalt nicht weiter gestreamt werden soll.

27


3.1. Usabilit Usabilityy Test Es gibt verschiedene Möglichkeiten, die Gebrauchstauglichkeit von Anwendungen zu testen. Diese spielen bei der Entwicklung und u nd Verbesserung Verbesserung von Anwendungen eine große Rolle. Bei Erstellung des Tests haben wir au olgende Kriterien geachtet: die Augaben sollten realistisch und dem Wissen der Teilnehmer angepasst sein, die Augaben sollten nicht trivial, aber doch einach genutzt sein, um in einer vorgegeben Zeit gelöst werden zu können. Die Formulierungen sollten klar und deutlich sein. Außerdem haben wir au olgende ün Fragen bei der Erstellung der Sotware geachtet: 1. Werden die Benutzer wissen, welchen Eekt ihre Aktionen haben? 2. Werden die Benutzer das notwendige Element sehen? 3. Werden Werden die Benutzer glauben, dass es sich um das richtige Element handelt? 4. Werden Werden die Benutzer die Auswirkungen der Aktion einschätzen können? 5. Werden die Benutzer den nächsten Schritt erkennen?

3.2. Messbarke Messbarkeit it von Usability Es gibt mittlerweile viele verschiedene Ansätze zur Messung der Bedienbarkeit. Kriterien ür die Messungen sind zum Beispiel Ezienz, Eektivität und Zuriedenheit. Daraus kann man schlussolgern, dass Anwendungen, welche schneller durchlauen werden, besitzen auch den höheren Usability-Grad. Weitere Ansätze sind z.B. die Fehle Fehlerhäugkeit, rhäugkeit, welche ein Nutzer während des Durchlaus macht oder die Erinnerungsähigkeit an die d ie Struktur. Wir Wir haben uns an die Zuriedenheit und Eektivität der Probanden orientiert und diese später analysiert und bewertet. Aus dem Usability Test heraus konnten wir detaillierte Inormationen über die User Experience herausnden und solche Fak Faktoren toren wie Nutzerzuriedenheit und Verständis der Anwendungen beurteilen. Man sollte die Benutzer geschickt steuern und in die gewünschte Richtung lenken. Die Navigation soll schnell erkennbar und nachvollziehbar sein,um zu vermeiden, dass der Nutzer verwirrt wird. Man sollte eine Balance zwischen z wischen Ästhetik und Funktionalität nden. Elemente, die die meiste Aumerksamkeit brauchen, müssen gestalterisch so angeordnet sein, dass diese von einen Besucher schnell geunden werden.

28


3.3. Eye-Tracking Als Eye-Tracking Eye-Tracking oder Blickbewegungsmessung bezeichnet man eine Methode, mit mi t welcher der Blickverlau einer Person beim Betrachten eines Gegenstandes oder einer interaktiven Anwendung gemessen wird, um neue Erkenntnisse über die Wahrnehmung des Produktes/ Programms zu erhalten. Außerdem lieert Eye-Tracking Eye-Tracking Anhaltspunkte über das Orientierungsverhalten der Nutzer. Nachdem ein Proband dem Test Test unterzogen wird und die jeweiligen Augabe erledigt hat, sammelt man diese Daten zur Auswertung. Die darau olgende Analyse des mittels eines Eye-Trackers Eye-Trackers augezeichneten Pades, in dem die Fixationsdauer kodiert ist, gibt Auschluss über Wirksamkeit der dargebotenen Inormation und Auschluss über das Verhalten des Rezipienten. Bei der Kombination von Eye-Tracking Eye-Tracking und UsabilityUsability-TTest haben wir die Probanden zur Lösung einiger Augaben mit unserem System veranlasst und motiviert die d ie Sotware dabei zu kommentieren. Mit Hile von Fragebögen, die unsere Probanden nach dem Test ausüllen sollten, konnten wir wichtige Erkenntnisse, Meinungen sowie Verbesserungsvorschlägen Verbesserungsvorschlägen der Nutzer gewinnen. Eine zentrale Anorderung war eine Favoriten Liste, die darauhin auch implementiert wurde. Eye - Tracking Tests Tests gaben Auschluss über die allgemeine Benutzbarkeit von XBMC und unseres Plugins. Im Verlau der Tests stellte sich heraus, dass ast alle Probanden Schwierigkeiten hatten das Zattoo Live TV zu nden, weil keinen der Probanden das XBMC zuvor Erahrung mit XBMC XBM C hatte. Fast alle Probanden Probanden versuchten ihr Glück unter dem Button „Programme“ und nicht unter dem Button „Videos“. Dies kann man an den olgenden Screenshots erkennen. Screenshots,diebei demEye-Tracking entstandensind

29


Ab dem zweiten Start und mit ersten XBMC Erahrungen konnte unser Plugin jedoch schnell geunden werden. Dies bestätigt auch nochmal unsere Entscheidung uns ür ein Script zu entscheiden. Ein Plugin hätte umständlich über die Optionen installiert werden müssen, unsere Lösung ist an der Stelle an der man sie erwarten würde zu nden.

30


4. GUI Konzeption Die Entwicklung einer optisch ansprechenden und intuitiv zu bedienenden Oberfäche wurde mit Projektstart ein großer Stellenwert Stellenwert eingeräumt. Leider ist dies d ies jedoch mit einigen Fallstricken Fall stricken verbunden, au die d ie im Folgende Folgenden n näher eingegangen wird.

4.1. Allgemeines XBMC unterscheidet zwischen sogenannten “Scripts” und “Plugins”. Für die GUI Entwicklung ist das relevant, da nur Plugins volle Gestaltungsmöglichkeiten bieten. Allerdings Allerdings sind Scripts sehr viel einacher zu installieren und vor Allem auch in der erwarteten Kategorie zu nden, unter Video → Plugins. Im Hinblick au die Anorderung von Zattoo au möglichst vielen Geräten zur Verügung zu stehen entschieden wir uns ür ein Script.

4.2. Gestaltung / Umsetzung Durch die Entscheidung ür ein Script im XBMC Sinne waren uns bei der GUI Gestaltung enge Grenzen gesetzt. Das Look & Feel ändert sich je nach verwendeten Skin. Dennoch haben wir Mockups erstellt die zeigen wie man eine schlanke, moderne und intuitiv zu bedienende Oberfäche gestalten könnte. Dabei bedienten wir uns Stilmitteln wie “Cover“Coverfow” und kontextabhängigen Mouseover Aktionen.

4.2.1. Mockups

31


32


XBMC verwaltet seine Menüs intern mit Listen. Allerdings werden diese nicht zwangsläug auch als Listen dargestellt. Im verwendeten ver wendeten “Confuenc “Confuence” e” Skin können die di e Listeneinträge auch als Galerie oder in i n Kacheln angezeigt werden. Innerhalb des von XBMC gesetzten Rahmen ist die GUI nach dem “In drei Klicks zum Ziel” Prinzip gestaltet. Unabhängig davon ob der Nutzer eingeloggt ist oder nicht bedar es nicht mehr als 3 Klicks um zur Senderauswahl zu gelangen. Neben rein gestalterischen Aspekten spielt natürlich auch die Benutzbarkeit eine Rolle. Comort Funktionen wurden von Usern gewünscht und von uns auch umgesetzt. So So gelang eine im XBMC Rahmen schlanke Oberfäche, deren Nutzbarkeit wir mit Usability Tests bestätigt haben.

33


5. Realisierung des XBMC-Plugins Im olgenden Kapitel wird nun au die konkrete Implementierung des Projekts eingegangen. eingegangen.

5.1. Entwicklung eines Prototypen Um bereits in der Anangsphase des Projekts au mögliche Hindernisse und Probleme aumerksam zu werden wurde mit der d er Bereitstellung der Zattoo API umgehend ein erster Prototyp einer XBMC-Plugins entwickelt. Hauptaugenmerk der Prototypenentwicklung lag hierbei darau, die generelle Streamingunktionalität von HLS-Streams innerhalb von XBMC zu testen und von diesen Ergebnissen ausgehend die weitere Projektplanung einzuleiten. HLS - eine Abkürzung ür HTTP HT TP Live Streaming - ist ein von dem Unternehmen Apple Inc. im Rahmen von Quicktime X entwickeltes, auf HTTP HT TP basierendes Protokoll zum linearen Streaming von Medien über das Internet. Grundsätzlich wird dabei ein Stream in eine Sequenz von kleinen Dateidownloads augeteilt, wobei jede dieser Dateien einen Teil Teil des Medienstreams enthält. Au Empängerseite wird am Anang einer Streamingsitzung eine m3u8-Playlist mit den Metadaten des Streams heruntergeladen,, darunter auch diverse Substreams in z.B. anderer Qualität. Auf Basis dieser heruntergeladen di eser Daten wird der Stream dann au Clientseite abgespielt, was zum Beispiel den Vorteil mit sich bringt, dass auch während des Streamings die Qualität schnell geändert werden kann, ohne den Stream neu starten zu müssen. Es wurde schnell estgestellt, dass HLS Streams nur bedingt kompatibel waren mit dem XBMC. Die automatische Bitrate Anpassung unktionierte nicht, dadurch resultierte nur ein Bild mit der d er minimalen Bitrate. Zudem neigte der Stream ot dazu einach abzubrechen.

5.2 . Multilangu Multilanguage age XBMC bietet eine einache Möglichkeit an Plugins mehrsprachig zu entwickeln. Dazu wird im Unterordner resources/language// resources/language// eine string.xml hinterlegt, welche die di e Strings in der jeweiligen Zielsprache enthält, gekoppelt gekoppelt an est denierte IDs. In der resources/language/German/strings.xml liegen dann z.B. die deutschen Übersetzungen.

34


Auszug resources/language/German/strings.xml Benutzername Passwort Ni …

Auszug resources/language/English/strings.xml

Username Passwor id=“30002“>Password d Do not login … Über die Methode pluginLanguage() pluginLanguage() wird vollautomatisch der String aus der passenden Übersetzungsdatei zurückgegeben, abhängig davon welche Sprache der Benutzer in den Systemeinstellungen von XBMC eingestellt hat.

5.3. Login Funktionaität Ein wichtiger Bestandteil unserer Vereinbarung Vereinbarung mit Zattoo war es, dass sich die Benutzer einloggen müssen bevor sie Zugri au die Live TV Streams bekommen. Realisiert wird dieses Feature primär über die ZAPI Funktionen POST to https://HOST/zapi/account/log https://HOST/zapi/account/login in sowie POST to https://HOST/zapi/account/login. Um nicht bei jedem Plugin Start die Login Inormationen neu eingeben zu müssen werden diese zwischen den Sessions in einer XML Datenbank gespeichert. XBMC bietet diese Funktiona Funktionalität lität über die xbmcplugin.setSetting(p luginID,VariablenName) luginID,V ariablenName) Schnittstelle an. Dadurch wird eine resources/settings.xm resources/settings.xmll im Verzeichnis des Plugins angelegt. Über xbmcplugin.getSetting(pluginI xbmcplugin.getSetting(pluginID,V D,VariablenName) ariablenName) lassen sich dann gespeicherte Variablen wieder auslesen.

35


Das Plugin erkennt beim Starten ob Login Daten schon hinterlegt sind. Ist dies nicht der Fall sieht der User nur ein Listenelement Li stenelement mit dem Namen “Login” “Login” über welches dann das Einstellungsenster,, mit der Möglichkeit der Eingabe der Daten, augeruen wird. Sind ein Benutzerlungsenster name und Passwort gespeichert wird versucht mit diesen sich beim Zattoo Server anzumelden. Ist ein Login erolgreich er olgreich zeigt das Plugin das eigentliche Hauptmenü an, anderweitig eine entsprechende Fehlermeldung Fehlermeldung warum der Login gescheitert ist. Im weiteren bendet sich der Login in den Settings des Addons um sich evtl. mit einem anderen Name einzuloggen. Die Settingoption von XBMC ist standardmäßig über die rechte Maustaste zu erreichen und wird über die settings.xml Konguriert.

3.4. Kanal Zapping Unter „Zapping“ stellt sich der Benutzer B enutzer das vor- und zurück-Schalten zwischen den TV T V Kanälen vor. In XBMC würde das bedeuten, dass der Benutzer die vor- und zurückzurück-TTaste des Players verwenden will, die eigentlich ür das springen in einer Playlist gedacht sind, um einen Sender weiter oder zurück zu schalten.

5.4.1. Umsetzung Daher liegt es nahe, die Sende-Streams in eine Playlist zu legen. Da die zuständige “Xbox” API leider nur die Möglichkeit vor gibt, eine angelegte Playlist komplett ab zu spielen und nicht, einen einzelnen Titel daraus gezielt auszuwählen, ergibt sich das erste Problem: Der angewählte Sender muss an die erste Stelle in der Playlist gesetzt werden und die anderen Sender müssen relativ zu diesem Sender an der richtigen Stelle in der Playlist zu nden sein, sodass der Benutzer bei vor- und zurück-Springen die richtigen Sender zu sehen bekommt. Bei klicken au den gewünschten Sender wird daher eine Playlist augebaut, die genau diese Kritärien auweist. 36


5.4.2. Zurück-Spring-Problem Das wesentlich größere Problem verhält sich wie olgt: Da XBMC ür persistente Daten, wie etwa Film- oder Musikbibliotheken, ausgelegt ist, ist auch der Player von XBMC nicht ür die Wiedergabe von Streams gedacht. D.h. D.h. beim Drücken au die Vorwärts-Taste Vorwärts-Taste springt der Player zwar auch bei Internet-Streams ohne Probleme einen Titel weiter, weiter, beim Drücken au ZurückZurück-TTaste wird allerdings erst eine Unterscheidung gemacht. Ein exemplarischer Pseudo-Code macht diesen Vorgang Vorgang klar: AnfangSpringezurück wenn(aktuelleAbspiellzeit>1Sekunde) {

Spri Sp ring nge ezu zurü rück ckz zum umA Anf nfan ang gde des sak aktu tuel elle len nTi Tite tels ls }

sonst {

Springe zum letzten Titel }

EndeSpringezurück

Da Zattoo-Fernseh-Streams keine Download-Streams, sondern echte Internet-Streams sind, ist es nicht möglich, darin zu einem anderen Zeitindex zu springen. Dies verursacht zwar keinen Fehler, Fehler, allerdings kann der Player auch niemals erolgreich er olgreich zum Beginn des aktuellen Titels zurückspringen, sodass nach Ende, der ersten Sekunde S ekunde in einem Sender, nichts mehr bei Drücken au zurück passiert.

5.4.3. Pro und Kontra, ob die Funktion beibehalten werden soll Da das Problem nicht bei der eigentlichen Implementierung der Funktion „Zapping“ „Zapping“,, sondern beim Player liegt, kann es so erst mal nicht einach behoben werden. Allerdings ist es auch möglich, dass der Player von XBMC in einer späteren Version Version noch lernt Internet-Streams richtig zu interpretieren. Daher ist es theoretisch möglich, dass sich das Problem ohne weiteres Beitun von unserer Seite löst. Au der anderen Seite i st es allerdings auch möglich, dass der Benutzer verwirrt ist, wenn er zwar vor, aber nicht zurück zappen kann.

37


Daher olgen nun einige Pro- und Kontrapunkte, ob es dennoch Sinnvoll ist, die ehlerhate Funktion im Plugin zu behalten. Pro

Kontra

Eine spätere XBMC Version kann möglicher Weise Live-Streams interpretiere interpretieren n Weiter Schalten unktioniert

Möglicher Weise Weise wird der Fehler aber auch nie behoben Benutzer wird verwirrt

Zurück Schalten unktioniert in der ersten Sekunde (Fehler ällt beim schnellen „Zappen“ nichtt au) nich au )

Bugs können eine Sotware unvollständig erscheinen lassen

Es gibt also Punkte ür und gegen die Entscheidung, das Zapping ehlerhat im Plugin zu lassen. Es wäre eventuell sinnvoll, den Code zum Zappen auskommentiert im Code stehen zu lassen, um ihn später zu implementieren, sobald der XBMC Player auch ür InternetStreams optimiert wird.

5.5. XBMC-HLS Fork Recherchen zu der nicht vollständigen Kompatibilität der Zattoo Streams d urch das XBMC ergaben, dass das XBMC das HTTP HT TP Live Streaming nicht vollständig unterstützte. Weitere Weitere Recherchen brachten zutage, dass es aber schon seit längerer Zeit einen Patch gab, der dieses Problem löst. Jedoch wurde dieser Patch noch nicht vom XBMC Entwickler Entwick ler Team Team implementiert. Augrund dessen wurde die Entscheidung geällt diesen Patch selbst zu implementieren um zu testen ob eine vollständige HLS Kompatibilität im realisierbaren Rahmen lag. Das Patchen und anschliessende Kompilieren klappte unter Windows Windows und Mac OSX sehr schnell, und es zeigte sich, dass der Patch dem XBMC dazu verhal HLS Streams richtig abzuspielen. Somit wurde gezeigt, dass es möglich ist HLS Streams ehlerrei zu unterstützen und das ein zuküntiges ozielles XBMC Release R elease mit HLS Kompatibilität im Rahmen des Möglichen liegt.

38


5.5.1. Kompilierung Da es gerade in der späteren Projektphase neue Builds von XBMC gab mussten die Updates jeweils ür die entsprechenden entsprechenden Systeme neu kompiliert kompiliert werden. Kompiliert wurde dann die XBMC 12 Alpha um sicher zu gehen dass das Plugin ür einen zuküntigen Release von XBMC lauähig ist. Zumal die 12 Version von XBMC die Entschlüsselung der Streams unterstützt die Seitens Zattoo im Laue des Projekts zugeügt wurde. Probelme traten otmals bei der Kompilierung bestimmter Forks bspw. der Version ür IOS au. Die Entsprechenden Dependencies wurden otmals alsch gesetzt und machten ein mehrmaliges Kompilieren und widerholen der Schritte notwendig not wendig bis eine ehlerreie Version erstellt werden konnte.

5.6. Spezifzierung der Anorderung Anorderungen en durch User Stories Wie schon erwähnt, werden bei Scrum häug User Stories als Mittel M ittel zum Festhalten der Anorderungen verwendet, so auch in diesem Projekt. Um eine kleine k leine Übersicht über das Projekt zu bieten, olgt in diesem Abschnitt erst einmal ein Zeitstrahl mit dem Projektzeitraum und der Einteilung in Sprints. Darau olgt eine Liste aller User Stories mit entsprechender Zuordnung zu einem Sprint. Danach werden die einzelnen Sprints mit entsprechenden Abläuen im Detail erklärt.

39


5.6.1. Zeitstrahl und Sprints

40


5.6.2. User Stories & Sprintzuordnung 1) Als Kunde möchte ich, dass eine Analyse über die Streamingähigkeit von Zattoo-Inhalten über das Xbox Media Medi a Center durchgeührt wird, um anhand der Ergebnisse die weitere Pro jektgestaltung ausarbeiten zu können. können. 2) Als Kunde möchte ich, dass die Oberfäche der Anwendung möglichst intuitiv ist, da mein Kundenstamm sehr groß ist und sich aus einer sehr heterogenen Gruppe zusammensetzt, die nicht technikerahren sein muss. 3) Als Nutzer möchte ich die Streams von Zattoo innerhalb meiner XBMC Anwendung anschauen können, da ich XBMC als Media Center nutze. 4) Als Nutzer möchte ich die Streams in geeigneter Qualität ansehen, damit ich mir keine verpixelten Streams ansehen muss.

5) Als Nutzer möchte ich in einer Listenansicht sehen, was gerade au welchem Sender läut, um au einen Blick das derzeitige Fernsehprogramm sehen zu können. 6) Als Nutzer möchte ich in der Listenansicht Listenansicht ein kleines Bild mit einem Ausschnitt der Sendung sehen, die gerade läut, damit ich mir im Zweiels Zweielsall all sicher sein kann, dass es auch die gewünschte Sendung ist. 7) Als Nutzer möchte ich nach dem Start des Plugins die Möglichkeit haben, mich mit meinen Logindaten bei Zattoo Zattoo anzumelden, da ich sonst keine Streams Streams über XBMC empangen kann. 8) Als Nutzer möchte ich nach dem Login eine Liste mit Kategorien ür Sender angezeigt bekommen, um nicht lange nach dem Sender den ich sehen will suchen zu müssen. 9) Als Nutzer möchte ich, wenn wenn ich während ich einen Stream Stream gucke au die vorheriges/ nächstes-Elemente klicke, zwischen den Sendern zappen, zappen, damit ich möglichst intuitiv die Kanäle wechseln kann. 10) Als Nutzer möchte ich meine Sender-F S ender-Favoriten avoriten in einem entsprechenden Ordner speichern und auswählen können, damit die Schritte bis zum eigentlichen “Fernsehe “Fernsehen” n” möglichst minimiert werden. 11) Als Kunde möchte ich, dass der entwickelte XBMC-Fork au möglichst vielen Devices zur Verügung steht, um mein Portolio größtmöglich auszuweiten. 12) Als Kunde möchte ich, dass XBMC in der Lage ist, verschlüsselte Streams abzuspielen, abzuspielen, da ich meine Inhalte I nhalte verschlüsselt anbieten möchte. 13) Als Kunde möchte ich eine Projektdokumentation, um evtl. später darau zurückgreien zu können, wenn etwas unklar ist. 41


1. US1: Als Als Kunde möchte ich, dass eine Analyse Analyse über über die Streamingähigkeit von ZattooInhalten über das Xbox Media Center durchgeührt wird, um anhand der Ergebnisse die weitere Projektgestaltung ausarbeiten zu können. 1.1. Sprints nr: 1 - 3 1.2. Analyse Aubau XBMC, erste erste Tests Tests (2) 1.3. Python erlernen erlernen (1) 1.4 Prototyp erstellen (3) 1.5. => Folge-Userstory: 3 2. US2: Als Kunde möchte möchte ich, dass die Oberfäche der Anwendung möglichst intuitiv ist, da mein Kundenstamm sehr groß ist und sich aus einer sehr heterogenen Gruppe zusammensetzt, die nicht technikerahren sein muss. 2.1. Sprints nr: 1 - 14 2.2. AP: Konzeption & Analyse (1-5) 2.2.1. Fazit: Wenig Spielrau Spielraum m 2.3. Mockuperstellung (6-7) 2.4. Vorbereitung Usability-Tests (8-9) 2.5. Testdurchührung (10-12) (10-12) 2.6. Auswertung(13-14) 3. US3: Als Nutzer möchte ich die Streams Streams von Zattoo innerhalb meiner XBMC Anwendung anschauen können, da ich XBMC als Media Center nutze. 3.1. Sprint nr: 4 3.2. Testclient in XBMC-Plugin umsetzen umsetzen 3.3 Fazit: Bug besteht, besteht, dass die Aufösung nicht angepasst wird. wird. 3.4 => Folgestories: 4, 5 4. US4: Als Nutzer möchte ich die Streams in geeigneter Qualität ansehen, damit ich mir kei ne verpixelten Streams ansehen muss.

4.1 Sprints: 5 - 15 4.2 Analyse Streaming-Bug (5-6) 4.3 Recherche Lösungswege (7-8) 4.4 Test: Test: Pull-Request, Fazit: erolgreich (9) 4.5 Kompilieren: OSX / Windows Windows / Linux (10-13) 42


4.6 Tests (14-15) 4.7 Fazit: Größter Showstopper. 5. US5: Als Nutzer möchte möchte ich in einer Listenansicht sehen, was gerade au welchem Sender läut, um au einen Blick das derzeitige Fernsehp Fernsehprogramm rogramm sehen zu können. 5.1 Sprint: 5-7 5.2 AP: Einbau Einbau rudimentäres EPG 5.3 Fazit: Aktualisierungsproblem, Aktualisierungsproblem, muss nicht weiter bearbeitet werden, werden, weil XBMC es von der internen Struktur her nun mal nicht anbietet (Datenbank kann nicht einach löschen etc.). Kunde will au Weiterentwicklung Weiterentwicklung bei XBMC warten. 6. US6: Als Als Nutzer möchte ich in der Listenansicht Listenansicht ein kleines Bild mit einem Ausschnitt der Sendung sehen, die gerade läut, damit ich mir im Zweiel Zweielsall sall sicher sein kann, dass es auch die gewünschte Sendung ist. 6.1 Sprint: 7 6.2 Holen der Bilder von ZAPI, ZAPI, mit gemacht gemacht im Rahmen von US5. 6.3 Faz Fazit: it: Aktualisierungsproblem, Aktualisierungsproblem, Bilder werden geladen aber aber gecached. gecached. Überschreiben mit aktuelleren Bildern nicht möglich. Ausweichen au statische Sender Logos. 7. US7: Als Nutzer möchte möchte ich nach dem Start des Plugins Plugins die Möglichkeit haben, haben, mich mit meinen Logindaten bei bei Zattoo anzumelden, da ich sonst keine Streams Streams über XBMC empangen kann. 7.1 Sprints: 10 - 12 7.2 Loginunktionalität einbauen 7.3 Generator: UUID 7.4 Ausührliche Tests 7.5 Optimierungen 7.6 Fazit: Login Funktionalität implementiert. 8. US8: Als Nutzer möchte möchte ich nach dem Login eine eine Liste mit Kategorien ür Sender angezeigt bekommen, um nicht lange nach dem Sender den ich sehen will suchen zu müssen. 8.1 Sprints: 13 - 14 8.2 Analyse Möglichkeiten im Rahmen von XBMC das Zattoo-Kategoriesystem abzubilden 43


8.3 Einbau Funktionalität 8.4 Fazit: Kategorien als Unterordner Unterordner realisiert. realisiert. Kategorienamen direkt über die ZAPI aurubar und mit entsprechenden Sendern beüllbar. beüllbar. 9. US9: Als Als Nutzer möchte ich, wenn wenn ich während ich einen Stream gucke au die vorheriges/nächstes-Elementee klicke, zwischen den Sendern ges/nächstes-Element Sendern zappen, damit ich möglichst intuitiv die Kanäle wechseln kann. 9.0 Sprint: 16 9.1 Einbau Funktionalität 9.2 Test 9.3 Fazit: Vorwärst schalten unktioniert, unktioniert, zurück schalten jedoch nicht, da XBMC au den Anang des Streams schalten möchte. 10. US10: Als Nutzer möchte ich meine Sender-Favoriten Sender-Favoriten in einem entsprechenden entsprechenden Ordner speichern und auswählen können, damit die Schritte bis zum eigentlichen “Fernsehen “Fernsehen”” möglichst minimiert werden. 10.0 Sprints: 15-16 10.1 Einbau Funktional Funktionalität ität 10.2 Fazit: Favoriten Ordner implementiert mithile der Original XBMC Fa Favoriten voriten Funktion 11. US11: Als Kunde möchte ich, dass der entwickelte entwickelte XBMC-Fork au möglichst vielen Devices zur Verügung steht, um mein Portolio größtmöglich auszuweiten. 11.0 Sprints: 14-17 11.1 Kompilieren au diverse Betriebssystem 11.2 Fazit: Fork erolgreich kompiliert ür Windows, Linux, OSX, Apple AppleTV. TV. XBMC au IOS allerdings nur mit Jailbreak. 12. US12: Als Kunde möchte ich, dass XBMC in der Lage ist, verschlüsselte verschlüsselte Streams Streams abzuspielen, da ich meine Inhalte verschlüsselt anbieten möchte. 12.0 Sprints: 10 - 11 12.1 Festgest Festgestellt, ellt, dass die stabilen XBMC 11.0 Sources neue Zattoo Verschlüsselung Verschlüsselung nicht unterstützen. 12.2 Tests mit Alpha-Version Alpha-Version v. XBMC-Github-Repository 12.3 Fazit: 12er Alpha Version Version kompatibel zur Verschlüsselung, Verschlüsselung, jedoch manchmal instabil. 44


13. Als Kunde möchte ich eine Projektdokumentation, Projektdokumentation, um evtl. später darau zurückgreien zu können, wenn etwas unklar ist. 13.0 Sprints: Projektbegle Projektbegleitend, itend, Verweis aus Wiki. 13.1 Erstellung Dokumentation, Klassendiagramme, Zeitplan, UI Mockups

5.7. Sprintdetails ???????????????

45


6. Ausblick Das Zattoo Plugin erweisst sich gerade au Devices wie dem ATV als eine sinnvolle und ansprechende Ergänzung zu den vorhandenen Features Features von XBMC. Auch wenn die Streamingdienste in Deutschland seitens der Privatsender anders positioniert sind als in der Schweiz bietet das Zattoo-Plugin gerade bei großen Sportevents der öentlich Rechtlichen FernsehFernsehsender eine fexible Möglichkeit des Empangs. Zumal der Empang hochaugelöster Inhalte auch in Deutschland meist mit Kosten verbunden ist. Die Zukunt des Plugins ist leider mitunter au neuere Versionen Versionen XBMC´s angewiesen. Wie erwähnt verügen momentane Builds von XBMC keinen nativen HLS-Support. Das es jedoch bereits eine Implementation gibt ür die Unterstützung lässt darau schließen das diese auch in zuküntigen Release´s dann mit eingebunden wird. Eine solche Implementation seitens der XBMC-Entwickler-Community lässt vielleicht auch Spekulation um weitere Features in Richtung Streaming aukommen, so dass evtl. ür das Zapping-Problem eine Lösung geunden werden kann. Da es sich bei XBMC jedoch um eine Open Source Sotware handelt und es keine este Roadmap der Entwickler gibt sind Auschlüsse au neue Versionen weder Abschätzbar noch sind evtl. zuküntige Features abzusehen. Einzig eine Eigeninitiative selbst in Richtung XBMC zu entwickeln wäre vermutlich eine Alternative einfuss au zuküntige Implementationen zu haben und sie den eigenen wünschen anzupassen.

46


7. Fazit Abschliessend lässt sich sagen, dass das Projekt zu einem erolgreiche er olgreichen n Ergebnis geührt werden konnte. Alle Muss Anorderungen wurden nach Kundenanorderung umgesetzt und implementiert. Zusätzlich gelang es auch einige Kann K ann Anorderungen, wie eine Favoriten Favoriten Liste einzubauen. Die Arbeit in einem größeren Team erwies sich als komplexer als zunächst erwartet. Durch genaue Planung und Umsetzung unserer Vorgaben Vorgaben entwickelte sich jedoch schnell eine Dynamik und ein gutes Arbeitsumeld. Dabei war der regelmäßige Kontakt und Austausch mit Ral Kruttho-Brüwer, Sotware Entwickler bei Zattoo, und Benedikt Engelbert, Projektleiter an der Hochschule, sehr hilreich. Viele der im Verlau dieser Dokumentation beschriebenen Probleme Probleme konnten durch gesammeltes Know How der Projektmitglieder gelöst werden. werden. Das ührte auch dazu, dass wir uns mit Themen beschätigten, die im Voreld nicht unbedingt zu erwarten erwar ten waren – Kompilierung und Patchen eines eigenen XBMC Forks beispielsweise. Die Veranstaltung „Sotware Engineering Project“ gibt einen guten Einblick und Vorgeschmack au das, was uns im Rahmen des Abschlusssemesters und auch danach erwartet. erwar tet. Sie ist eine gute Vorbereitung Vorbereitung und hilt den Praxisschock im Unternehmen zu verringern.

47


8. Klassendiagramm

48

Doku

Recommend Documents