Projekt: 4Video - Middleware für die Anpassung von … · 2016-03-30 · Mit 4Video möchte M4...

© Mhoch4 Die Fernsehagentur, 2010 Copyright: Die in diesem Konzept dokumentierten Vorschläge sind geistiges Eigentum der Mhoch4 GmbH & Co KG und unterliegen den geltenden Urhebergesetzen. Die unautorisierte Nutzung, die ganze oder teilweise Vervielfältigung sowie jede Weitergabe an Dritte ohne Rücksprache ist nicht gestattet.

Seite 1

Projekt: 4Video - Middleware für die Anpassung von Videopublikationen für mobile Endgeräte © Mhoch4 - Die Fernsehagentur, November 2010

Inhalt 1 Projektbeschreibung ......................................................................................................2

1.1 Zielsetzung, Problemstellung und Lösungsweg ......................................................................... 2 1.2 Führende Konkurrenz und Internationaler Stand der Technik................................................... 4 1.3 Einstufung der eigenen Entwicklungsziele.................................................................................. 9 1.4 Technische Risiken des Projektes............................................................................................... 9 Risiko 1 – Skalierungsproblematik und Lastprobleme 10 Risiko 2 – Gefahr übermäßiger Funktionsanforderungen in der Definitionsphase 10 Risiko 3 – Hohe Heterogenität des Document Object Model auf Output (TabletPCs) und

Inputseite (Redaktionssysteme) 10 Risiko 4 – Performance 3rd Party Interfaces; Lastprobleme und lange Antwortzeiten 11 Risiko 5 – Datenmengen, rasches Wachstum von Log-Daten 11 1.5 Definition von technischen Zielkriterien und Meilensteinen zu diesen Kriterien..................... 11

2 Arbeitspakete und Termine ..........................................................................................14 2.1 Übersicht Arbeitspakete ............................................................................................................. 14 2.2 Arbeitspakete im Detail............................................................................................................... 14


Seite 2

1 Projektbeschreibung Mit 4Video möchte M4 für Verlage und insbesondere für TV- bzw. Web-TV Sender eine Plattform als Middleware entwickeln, mit der es möglich ist, bestehende Publikationen und Videoformate auf elekt-ronische Lesegeräte (eViewer) zu bringen und diese so anzupassen, dass sie auf die erweiterten Dar-stellungsmöglichkeiten angepasst werden. Dieses umfasst bei Verlagspublikationen eine Migration von Text und Bild zu Text, Bild, Audio, Video und Animation bzw. eine Ergänzung von Videoinhalten um Text-, Audio-, Bild- und Animationsinhalten. Wir sehen den Bedarf bei unseren Kunden nach einer Lösung, welche plattformunabhängig funktio-niert, denn zukünftig wird der Markt für eViewer Hardware immer heterogener werden. Hierbei werden nicht nur Apple, sondern auch diverse andere große Marktteilnehmer einen relevanten Marktanteil gewinnen. Letztendlich bleibt es dem Endkunden überlassen, welches Endgerät er sich kauft. Die M4 Lösung wird sicherstellen, dass darauf Content diverser Medien in einer den neuen Darstellungsmög-lichkeiten angepassten Form bezogen werden kann. 1.1 Zielsetzung, Problemstellung und Lösungsweg Das Vorhaben wird in acht Arbeitspakete unterteilt, deren Details im Kapitel 2 beschrieben sind. Basis für die Entwicklung ist zunächst eine genaue Betrachtung und Erhebung der Bedürfnislage und An-spräche von Verlagen bzw. Redaktionen, um die daraus gewonnenen Erkenntnisse für die Entwick-lung der Middleware abzuleiten und eine optimale Integration in bestehende Systeme auf Nutzerseite (Verlage, Redaktionen, WebTV-Sender sowie die Multi-Device Auslieferung an die Endgeräte) zu gewährleisten. Ein Kernziel bei der Entwicklung der Middleware ist die Migration von einer linearen Darstellungsform zum semantischem Publizieren durch das Zurverfügungstellen von „Semantic Enrichment Tools“ (Abb.1), die weit über das Setzen von statischen Hyperlinks hinausgehen und z.B. in Form eines „Semantic Wiki” Zusatzinformationen liefern und in Runtime aus dynamischen Dokumenten kreiert werden. Diese Microcontent-Elemente können dann wiederum HTTP URIs haben.

Abbildung 1: Sematisches Content Enrichment


Seite 3

Hierbei werden infrage kommende Semantik-Tools auf XML-Basis, wie beispielsweise Microformats oder GRDDL (Gleaning Resource Descriptions from Dialects of Languages), RDFa (Abwandlung von RDF – Resource Description Framework), EasyRdf, Semantic MediaWiki, Karagabi KMFramework, RedStore sowie vereinfachte Ontologien auf ihre Eignung hin überprüft und in die Entwicklung der Middleware einbezogen, um die zuvor beschriebene dynamische Contentgenerierung für elektroni-sche Lesegeräte zu unterstützen. In Phase 1 der Programmierung soll zunächst die Basis dafür geschaffen werden, dass Magazine (Spiegel, Bunte, Focus, Stern, Prinz, Petra, etc.) an die Middleware angebunden werden können. Diese Anbindung ermöglicht den Zugriff auf die bestehenden Multi-Content-Assets (Text, Bild, Layout-Templates, Audio und Video) verschiedener Verlage, um innerhalb der Middleware die Anreicherung dieser Inhalteschnipsel mit weitergehenden Metadaten vornehmen zu können und eine nahtlose Auf-bereitung der Inhalte für die neuen Endgeräte vornehmen zu können. Phase 2 der Programmierung fokussiert sich auf die entsprechende Anreicherung der Inhalte und die Aufbereitung, also den elektronisch gestützten und weitestgehend automatisierten Redaktionsablauf für die elektronischen Lesegeräte. Die geplante Lösung soll auf den bestehenden Produktionsprozes-sen für die aktuellen Druckerzeugnisse des Verlags aufsetzen und vollständig in diesen integriert wer-den. Es ist ausdrücklich nicht gewollt, eine reine Website anzubieten, welche von der Online-Redaktion separat gepflegt werden muss. Die bestehenden Redaktionssysteme sollen einen Export ihres jeweiligen Magazins zur Verfügung stellen. Typischerweise wird das in einem pdf-Format gelie-fert. Weiterhin werden die Daten zu den einzelnen Artikeln als XML-Format sowie die Bilder des Ma-gazins benötigt. Der Verlag liefert diese Daten auf einen von M4 betriebenen Server an.

Abbildung 2: eViewer Funktionsweise Phase 3 fokussiert sich auf die Auslieferung der Inhalte, um die Darstellung auf verschiedensten e-Viewern – insbesondere Tablets – zu gewährleisten. Nach momentanen Stand der Technik steht hier-bei ein Multi-Device Ansatz (ePUB, iPad/Html5, Android Tablets, Windows 7 Tablets, Flash 10, etc.) im Mittelpunkt, um die wichtigsten Plattformen in diesem technisch heterogenen Marktumfeld zu be-rücksichtigen. Innerhalb der 4Video-Middleware werden die Daten der verschiedenen Verlage in einem (verlagsspe-zifischen) Produktkatalog zusammengeführt und angereichert. Hierbei sollen Verlagen auch Möglichkeiten eingeräumt werden, elektronische Preismodelle auszu-wählen und anzupassen. Denkbar sind beispielsweise die Erstellung verschiedener Produktkombina-tionen (z.B. Bundle aus Spiegel und Bunte) oder verschiedener Zahlungsmodelle (z.B. Einzeltarifpreis oder Abo-Preis). Die Administration der einzelnen Produkte erfolgt auf Ebene der ePublikationen im Rahmen der an die Middleware angeschlossenen Verwaltungstools.


Seite 4

Für kleine Redaktionen oder Verlage wird 4Video an bestehende „leichte“ Administrationstools ange-schlossen werden, ebenfalls wird ein unabhängiger Bezahldienstleister einbezogen werden, über den es möglich ist, Content auf verschiedenen Plattformen anzubieten/zu monetarisieren. Somit ist es den Nutzern der Middleware freigestellt auf eine in sich geschlossene Lösung zuzugreifen, als auch die Anbindung an bestehende Systeme auf Seiten der Nutzer (Verlage, Redaktionen, etc.) vorzunehmen. Die besondere Herausforderung des Projektes liegt in der Umsetzung der Lösung auf den eViewer Endgeräten. Hierbei muss berücksichtigt werden, dass jeder Betriebssystemhersteller ein eigenes Bedienkonzept für seine Geräte vorgesehen hat. Zusätzlich sind die Hardwarekonfigurationen bei den Endgeräteherstellern nicht standardisiert (verschiedene Displaygrößen, Prozessoren, Bildschirmtech-nologien, Navigationstools, hard-buttons, etc.). Somit muß das funktionale Bedienkonzept an die mög-lichen Endgeräte system-immanent angepaßt werden, wobei die Schnittstelle zur Middleware gleich bleibt. Des weiteren müssen auch aufkommende Marktentwicklungen für zukünftige eViewer-Geräte berücksichtigt werden.

1.2 Führende Konkurrenz und Internationaler Stand der Technik Das Projekt 4Video adressiert auf technischer Ebene verschiedene Bausteine, die als eigenständige Produkte / Services bereits am Markt vorhanden bzw. eingeführt sind, jedoch in der Zusammenfüh-rung und mit der spezifischen Zielsetzung des Projektes 4Video noch nicht als Wettbewerbsprodukt am Markt bestehen. Aus diesem Grunde werden nachfolgend die Kernkomponenten Hardware, Soft-ware und Semantische Anreicherung separat betrachtet: Hardware Die digitalen Medien haben den Zeitungs- und Zeitschriftenmarkt entscheidend beeinflusst und verän-dert. Der Großteil der Verlage hat sich zusätzlich zu ihren Printprodukten auch im Internet eine Prä-senz geschaffen, (die jedoch nur in den wenigsten Fällen wirtschaftlich profitabel ist.) Mit der Einführung von elektronischen Lesegeräten ist ein zusätzliches Medium zur Verbreitung von digitalen Inhalten entstanden, das eine enorme Steigerung in Angebot sowie Nutzung von eBooks und anderen Verlagsprodukten erwarten lässt. Amazon USA verkauft zur Zeit nach eigenen Angaben mehr E-Books als gebundene Bücher: Im Juni 2010 kamen auf 100 abgesetzte Hardcover-Ausgaben 180 elektronische Bücher. (Quelle: heiseonline) Neben dieser Entwicklung, die auf eine gesteigerte Nutzung im Bereich eReader (z.B. Amazon Kindle) schließen lässt, befinden sich seit der Einführung des iPad von Apple nun vor allem Tablet-PCs im Aufwind. Zu den Anbietern zählt neben Apple unter anderem auch Dell (Streak), HP (PalmPad) und 1&1 (Smartpad). Sie können als ergänzendes Medium zu Laptop und Netbook gesehen werden und vereinen Endgerä-te, wie E-Book-Reader und tragbare Spielekonsolen. Sie bieten eine neuartige Form des Medienkonsums und damit Raum für neue Nutzungsformen, für Verlage die Chance auf neuartige Erlösmodelle sowie Hoffnung auf die Erschließung neuer Zielgrup-pen (siehe Umfrage Abb.3). Auch die Möglichkeiten zur Einbindung von multimedialen Inhalten und interaktiven Elementen macht dieses Medium für Verlage interessant und steigert die Attraktivität für dessen Konsumenten.


Seite 5

Abbildung 3: Einschätzung Verlage bezüglich Tablet-PCs, Mai 2010 Software Bei der Nutzung von elektronischen Lesegeräten für die Distribution von Inhalten ist jedoch zu beach-ten, dass dessen Anbieter meist unterschiedliche Technologien und Softwarekomponenten nutzen. Als Betriebssystem hat sich bei vielen der Lösungen Android durchgesetzt; doch ebenfalls Windows 7 und das Open Source System Linux kommen bei Tablet-PCs zum Einsatz. Auch die Verwendung von Flash, bzw. HTML5 zur Darstellung von multimedialen Inhalten unterscheidet die Geräte voneinander. Die Problematik, die sich hieraus für Anbieter von Inhalten ergibt, ist die Notwendigkeit, Inhalte in un-terschiedlichen Formaten bereitstellen zu müssen, um diese auf unterschiedlichen Endgeräten anbie-ten zu können. Um diesen Aufwand zu reduzieren und eine gleichzeitige Veröffentlichung von identischen Inhalten auf verschiedenen Plattformen zu ermöglichen, besteht bei Inhalteproduzenten (Redaktionen, Verla-ge, etc.) ein hohes Interesse an technischen Lösungen in diesem Bereich. Übersicht: E-Reader und Tablet-PCs

Name Hersteller/Anbieter Betriebssystem/ Plattform

Veröffentlichung

E-Book-Reader Kindle Amazon iPhone, Windows PC,

Android Oktober .2009 (Europa)

Sony Reader Sony März 2009 (D) iLiad iRex (Philips) Linux Sommer 2006 Tablet PCs iPad Apple iPhone OS April 2010 (D)


Seite 6

JooJoo (Surf-Tablet) Fusion Garage Unix (Flash) Mai 2010 (D) Smartpad 1&1 Android Juni 2010 (D) Dell Streak (Tablet-Phone)

Dell Android Juni 2010 (GB)

HP Slate 500 HP Windows 7 k.A. Archos Archos Linux (Archos5) /

Android (Archos 5 Inter-net Tablet) / Windows 7 (Archos 7)

Dezember 2009 (D)

Interpad e-noa GmbH Android Herbst 2010 WeTab Neofonie Android September 2010 k.A. Motorola Gingerbread (Adroid 3.0) November 2010 Adam Notion Ink Indien Android tbd. Eee Pad Asus Windows 7 tbd. k.A. Google Android tbd. Tabelle 1: Übersicht E-Reader und Tablet-PCs Hardware-Software-Kombinationen Zum aktuellen Zeitpunkt gibt es im deutschen Markt zwei kommerziell verfügbare Tablet-PC, das iPad von Apple sowie den Archos. In den nächsten Monaten werden jedoch weitere Endgeräte, insbeson-dere auf Basis der Android Plattform (z.B. von LG und Samsung) auf den Markt kommen. Zu unterscheiden sind drei verschiedene Lösungsmodelle:

1. Hardware-basierte Lösungen, die Inhalte und ein spezielles Endgerät miteinander koppeln, 2. hybride Lösungen die Inhalte und Hardware miteinander koppeln über Erweiterungen aber

auch den Zugang zu anderen Plattformen und Betriebssystemen bieten sowie 3. Software-basierte Lösungen für ein oder mehrere Betriebssysteme, die nicht an ein spezielles

Endgerät gekoppelt sind. Die vorstehend in Tabelle 1 genannten Lösungen gehören mit Ausnahme von Nefonie / WeTab alle-samt der Kategorie 1 an. Zur Kategorie 2 gehören in Deutschland die Unternehmen Neofonie und txtr, welche beide Produktlösungen angekündigt haben, aber noch am Beginn der Entwicklung stehen. An Lösungen der Kategorie 3 arbeiten in Deutschland die beiden Mobilfunkbetreiber T-Mobile und Voda-fone, die aber jeweils die eigene Marke und Plattform transportieren wollen. Lösungen am Markt Derzeit gibt es auf dem Markt nur singuläre Lösungen für jeweils eine Hardwareplattform, jedoch noch keine Hardware-übergreifende Lösung. Zusätzlich gibt es innerhalb der bestehenden Lösungen noch keine Content-Server-Lösung, die es ermöglicht, dass Verlage die Inhalte ihrer Publikationen (basierend auf dem eigenen Verlags- und Print Workflow) an ein zentrales System anliefern können und von dort an multiple Endgeräte weiter-verteilen können. Bestehende Systeme fokussieren sich primär auf die Abbildung eines Workflows zur Darstellung von Websites. Die Contentaufbereitung für mobile Endgeräte ist kein Lösungsbestandteil, schon gar nicht wenn es darum geht, die lineare Darstellung von Content durch Verknüpfungen und sogenannten Semantischen Content Enrichment Tools (CE Tools) zu erweitern. Diese inhaltliche Aufbereitung ist vor allem in den Bereichen der Wissenschaftspublikationen und Corporate Publishing anwendbar bzw. wird dort bereits genutzt – stellt aber auch für Publikumszeitschriften eine sinnvolle Erweiterung dar.


Seite 7

Im Bereich der generischen semantischen CE Tools sind Open Calais und Temis, im Bereich der ver-tikal spezialisierten Tools BiotaxonFinder und ConceptWebAlliance als Marktstandard zu nennen. Zusätzlich sind Tools und Anbieter wie Censhare AG - SaaS-Anbieter Plattform unabhängiger Publi-kationssysteme, Noxum - Standard- und Individualsoftware für Portale, E-Business, Product Informa-tion Management, Cross Media Publishing und Technische Kommunikation sowie Author-it – US Component Content Management Software Unternehmen zu nennen, die sich im Umfeld der hier angedachten Lösung bewegen. Zu beachten, was ihre Development Roadmap anbetrifft, sind weiterhin Unternehmen wie Acrolinx, Ptc, Adobe Air, DCLabs, Instinctools, Schema GmbH, Jahia. Allerdings reichen die Funktionalitäten dieser Tools nur bedingt an den angedachten Funktionsumfang der hier angestrebten Lösung heran. Eine Spezialisierung auf und Anwendbarkeit im Bereich Mobile ist in keinem Fall vorgesehen. Das Funktionsprinzip der hier angedachten Lösung wird durch die nachfolgende Grafik verdeutlicht:

Abbildung 4 – Verknüpfungsbeziehungen in Textdokumenten In der hier angedachten Lösung kann Text mit Hintergrund-Informationen versehen, z.B. zu E-Learning aufbereitet, vom Leser kommentiert und bewertet und nach unterschiedlichen Schwierig-keitsgraden individuell zusammengestellt werden. Die Verlinkung soll dabei nicht über statische HTML-Seiten erfolgen, sondern nach Art eines dynamischen semantischen Wikis über dynamische Dokumente erfolgen, die im Idealfall „at runtime“ durch semantisch verlinkten Mirocontent auf Basis von http URIs erstellt werden. Die Abbildung 1 in Punkt 1.1 verdeutlicht dieses Funktionsprinzip be-reits schematisch. Der ideale Prozeßablauf besteht hierbei aus drei aufeinander aufbauenden Blöcken:

1. Datenbank der Medien-Assets (Texte, Bilder, Grafiken, Videos)


Seite 8

2. Die multiple Verknüpfung zu verwandten Inhalten 3. Der semantischen Verknüpfung verschiedener Medien-Assets zu einer neuen inhaltlichen Zu-

sammenstellung Durch dieses Prinzip werden Mehrfachverknüpfungen von verschiedenen Inhaltebausteinen und eine semantische Verknüpfung möglich, die in den nachfolgenden beiden Grafiken verdeutlicht werden.

Abbildung 5 – Vertiefende Verwandschaftsbeziehungen zu weiteren Medien-Assets

Abbildung 6 – Zusammenstellung von Medieninhalten anhand von Fundstellen


Seite 9

Die 4Video-Middleware stellt somit die Verknüpfung von maßgeblich 3 Komponenten dar:

1. Die Anbindung an externe Medienbibliotheken (Redaktionssysteme), um eine semantische Anreicherung der Media Assets zu ermöglichen,

2. Ein Authoring System, welches die Zusammenstellung neuer Medieninhalte ermöglicht, 3. Eine Auslieferungsschnittstelle, die erstmalig die Belieferung der unterschiedlichen Tablet-

PCs aus einem System heraus ermöglicht. 1.3 Einstufung der eigenen Entwicklungsziele M4 hat als einer der größeren unabhängigen digitalen Videoproduzenten mit eigener Redaktion in Deutschland, der u.a. für die dpa – Deutsche Pesse Agentur, die Messe Düsseldorf sowie für wesent-liche deutsche Verlage und TV-Sender bereits gearbeitet hat umfangreiche Erfahrungen in Redakti-onsprozessen allgemein, sowie bei der Produktion und Auslieferung digitaler Videoinhalte gemacht. M4 hat im Rahmen der fortlaufenden Geschäfts- als auch der Forschungs- und Entwicklungstätigkei-ten in verschiedenen Förderprojekten bereits umfassende Erfahrungen und Kenntnisse in den Berei-chen Flash, HTML5 und verschiedensten Auslieferungsformen von Videos und begleitenden Metada-ten sammeln können. Letzteres maßgeblich im Rahmen des Projektes P2P-Next (Europäische Kom-mission, FP7). Kenntnisse über die wesentlichen zu entwickelnden Schnittstellen liegen ebenso vor und auch die Grundfunktionalitäten des Contentservers nebst Metadatenanreicherung sind bereits angedacht wor-den. Dies stellt die Voraussetzung dafür dar, dass das Projekt zwar mit technischen und wirtschaftlichen Risiken behaftet ist, aber diese beherrschbar erscheinen und der Antragsteller von einer erfolgreichen Projektdurchführung im Rahmen des definierten Budgets ausgeht. Die nähere Auseinandersetzung mit dem Themenkomplex semantisches Web erfolgte im Rahmen der Untersuchung weitergehender Metadatenanreicherung der M4-Produktionen, um sowohl Auffindbar-keit von M4-Produktionen im Web zu unterstützen als auch die dynamische Zusammenstellung von themenbezogenen Videofeeds zukünftig zu ermöglichen. Die Nutzung von semantischen Metadaten für die Beschreibung von Inhalten und die damit verbundene Erfassung von thematischen Zusam-menhängen von Multimedia-Inhalten zielt somit mittelfristig neben der Entwicklung der 4Video-Middleware auch auf die Erweiterung des klassischen M4-Produktangebots. Im Gegensatz zu umfassend aufgestellten Forschungsprogrammen im Umfeld des semantischen Web wie bspw. THESEUS (BMWi), SEKT (Semantic Knowledge Technologies – Europäische Kommissi-on), IKS (Interactive Knowledge Stack – Europäische Kommission) die sich u.a. mit der Erforschung und Entwicklung in Bezug auf maschinelles Lernen und automatischer Inhalteerfassung beschäftigen, zielt 4Video auf die Anpassung und Erweiterung bestehender semantischer Erfassungsmöglichkeiten ab, mit dem Ziel den spezifischen Einsatzzweck, die redaktionelle, nahtlose Bearbeitung von multime-dia-Magazinen und deren Aufbereitung für mobile eReader zu ermöglichen. 1.4 Technische Risiken des Projektes Viele technische Risiken des Vorhabens bei M4 entstehen durch eine ständige Unsicherheit in der technologischen Entwicklung des Marktes für Online-Video und Tablet-PCs. So könnten eine rasante Entwicklung neuer Anwendungen und der Einsatz neuer Technologien durch Konkurrenzunternehmen die eigene Technik überholen, so dass die Lösung bei der Markteinführung bereits veraltet ist. Um diesem Umstand vorzubeugen, wird eine ständige Marktbeobachtung während des Projektes durch-geführt und die Option offen gehalten, technische Komponenten des Systems an aktuelle Marktbe-dürfnisse anzupassen.


Seite 10

Nicht zu letzt verbleibt ein nicht zu unterschätzendes technologisches Restrisiko, bei einem Neuent-wicklungsprojekt, welches im schlimmsten Fall zu einem Scheitern des Projektes führen kann. Auch die Wahl der Programmiersprache für die Middleware stellt ein Risiko für die erfolgreiche Umsetzung des Projektes dar. Die falsche Wahl bei der Programmiersprache kann zu Barrieren aufgrund einer Unverträglichkeit des Systems mit anderen Anwendungen am Markt führen. Außerdem kann sie zu Problemen bei einer Erweiterung der einzelnen Komponenten führen, falls diese sich erst im Laufe des Projektes ergeben oder durch Markteinflüsse anders gestaltet werden müssen. Das Endprodukt könnte, durch eine schlecht gewählte Programmiersprache sowie eine zu geschlossene Struktur, in-kompatibel mit Elementen/Anwendungen von Drittanbietern sein und würde damit gegenüber anderen Lösungen am Markt nicht bestehen. Um dies zu verhindern, werden vor der Entscheidung für eine Programmiersprache zunächst umfassenden Recherchen und eine Gegenüberstellung verschiedener Lösungsansätze angestrebt, um eine möglichst hohe Kompatibilität mit eViewer-Geräten auf dem Markt und deren technischen Spezifizierungen zu erreichen. Ein weiteres technisches Risiko im Projekt ergibt sich durch die hohen Datenmengen, die bei umfas-senden Multimedia-Anwendungen durch die Einbettung von Online-Videos übertragen werden müs-sen. Ohne ein ausgewogenes Distributionsnetz und hohe Übertragungskapazitäten bricht das System bei einem erhöhten Datenaufkommen durch viele Nutzer/Zugriffe zusammen. Folgende Lösungen und Alternativpläne sind bei Eintritt vorgesehen. Risiko 1 – Skalierungsproblematik und Lastprobleme Auf Grund von einer ungeplanten großen Anzahl von aktiven Nutzern und Zugriffen kann es zu tempo-rären Engpässen kommen. Zusätzlich kann insbesondere am Anfang des Betriebes ein Skalierungs-problem auftreten. Lösung 1 – Profiling (Xdebug), Load Balancing HTTPD, Load Balancing Database Reads, Integration von CDN (z.B. AWS Cloudfront) Lösung 2 – Definition eines intelligenten Cache Systems Schon im Architekturmodell wird auf diese Probleme der Skalierung und Lastverteilung eingegangen. Dies führt zu deutlich besseren Lastverteilungen und Skalierungseffekten der Lösung. Weiterer Lö-sungsbaustein ist das DBClustering, um die Scalability weiter zu erhöhen. Außerdem ist die frühzeiti-ge Integration eines reichweitenstarken CDN (Content-Delivery-Networks) geplant um bessere Skalie-rungseffekte, geringere Ausfallzeiten und eine höhere Qualität für den Nutzer anzubieten. Risiko 2 – Gefahr übermäßiger Funktionsanforderungen in der Definitionsphase In der Funktionsspezifizierung besteht die Gefahr Funktionsanforderungen in einem Maße zu definie-ren, welche realistisch im Entwicklungszeitraum bzw. mit dem geplanten Entwicklungsbudget nicht abbildbar sind. Dies resultiert häufig aus einer näheren Beschäftigung mit einem Problemkreis und der Falschbewertung von seltenen Detaillösungen. Lösung 3 – Rückkopplungsschleifen mit externen Experten Lösung 4 – Erstellung eines zweistufigen Entwicklungsplans mit einer „Light“ Version in Stufe 1 und einer „Voll“-Version in Stufe zwei der Entwicklung Bereits in frühen Phasen der Funktionsspezifizierung werden externe Experten hinzugezogen, um anhand von Drittmeinungen die Funktionsanforderungen auf Sinnhaftigkeit und Umsetzbarkeit zu ü-berprüfen. Des weiteren ermöglicht die Erstellung eines zweistufigen Entwicklungsplans die Aufteilung in Minimalanforderungen und Wunschanforderungen Risiko 3 – Hohe Heterogenität des Document Object Model auf Output (TabletPCs) und Input-

seite (Redaktionssysteme) Durch den interoperativen Multi-Content und Multi-Device Ansatz der gesamten Lösung ist es zwin-gend die Komplexität der entsprechenden Schnittstellen auf der Input- und Outputseite der Middlewa-re zu berückichtigen. Lösung 5 – Einsatz von Standard DOM API’s auf beiden Seiten (jquery, jQTouch)


Seite 11

Ein Schwerpunkt wird auf die Integration von offenen, flexiblen Schnittstellen inklusive einer entspre-chenden Dokumentation gelegt. Durch den Einsatz bspw. standardisierter JavaScript-Frameworks kann diese Komplexität operationalisiert werden. Zudem wird konsequent darauf geachtet, dass Open Source Software genutzt wird, um ein Vendor-Lock-In zu verhindern und um mit sehr vielen Systemen kommunizieren zu können. Außerdem sind die relevanten Standards in dem Bereich Video, ausge-hend von internationalen Gremien, in dem System berücksichtigt. Risiko 4 – Performance 3rd Party Interfaces; Lastprobleme und lange Antwortzeiten Ein weiteres Problem kann die Performance von 3rd Party Schnittstellen sein, da 4Video als Middle-ware auf der Input- und Output-Seite stark von diesen abhängt und daher auch die Performance des eigentlichen Systems davon abhängen wird. Probleme bei diesen 3rd Party Schnittstellen können vielschichtig sein, z.B. langsame Antwortzeiten oder Lastprobleme. Lösung 6 – Diese Probleme werden ebenfalls schon während der Entwicklung adressiert und mit be-rücksichtigt. Lösungsansätze umfassen asynchrone Abläufe sowie der Recall von Interfaces per Scheduler. Risiko 5 – Datenmengen, rasches Wachstum von Log-Daten Eine starke Nutzung der Systeme und anfänglich zur Optimierungszwecken geplanten hohen Log-Levels, kann es zu einer starken Anstieg der Datenmengen durch diese Logfiles kommen und ent-sprechend zu zusätzlichen Lastszenarien auf dem System. Lösung 7 – frühzeitige Abschätzung und Planung, Überwachung, Datenverdichtung und Archivierung Es ist geplant, ein mehrstufiges Datenbanksystem zu etablieren, um die Datenbank in verschiedene Modi fahren zu können. Unterstützt wird dieser Prozess die frühzeitige Abschätzung, Planung, Über-wachung, Datenverdichtung und Archivierung von Daten. 1.5 Definition von technischen Zielkriterien und Meilensteinen zu diesen Kri-terien Zu den allgemeinen Zielkriterien, die während des Projektes berücksichtigt werden, gehören die stän-dige Kontrolle des Einsatzes von finanziellen und personellen Ressourcen. Außerdem wurden 12 wirtschaftliche und 11 technische Zielkriterien definiert, die an den 5 Meilensteinen im 4Video-Projekt kontrolliert werden. An diesen Zeitpunkten wird beurteilt, ob der Projektverlauf am kritischen Pfad ver-läuft und ob Alternativpläne eingesetzt werden müssen.

Meilen-stein-Nummer

Meilenstein-Name Betroffenes Arbeitspa-ket

Datum

1 Funktionale Spezifikation 3 M3

2 Technische Spezifikation und Funktionsbeschreibung

4 M5

3 Entwicklung Phase 1 5 M7



6 Integration, Stress Tests + Demonstrator 8 M12

Tabelle 2: Meilensteine Bereits in den ersten Monaten der Projektlaufzeit werden die nachfolgend definierten wirtschaftlichen und technischen Zielkriterien überprüft und bei Bedarf ergänzt.


Seite 12

Folgende technische Zielkriterien bestehen während der Projektlaufzeit:

Zielkrite-rium

MS-Nummer

Datum Name technisches Zielkriterium

T1 1 M3 Proof of Concept erbracht – Funktionsprototyp er-stellt

T2 1 M3 Lastenheft erstellt

T3 1 M4 Usability Testing und Usability Analyse nebst Validie-rungsparameter definiert

T4 2 M5 Pflichtenheft erstellt

T5 3 M7 Phase 1 – APIs erstellt

T6 4 M10 Phase 2 – Content Server und Enrichmentmodul erstellt

T7 5 M12 Phase 3 – Mulit-Device Auslieferungsschnittstelle erstellt

T8 6 M12 Stresstest erfolgt

T9 6 M12 Demonstrator fertig gestellt

Tabelle 3: Technische Zielkriterien Die Kontrolle der technischen und wirtschaftlichen Zielkriterien bei Meilenstein 1 erfolgt durch das Arbeitspaket 2. Dieses erfolgt nach folgenden Parametern: Aufgabe 2.1: Usability-Testing und Usability-Analyse Aufgabe 2.2: Validierung der technischen Komponenten mit potentiellen Usern Aufgabe 2.3: Kosten- und Nutzenanalyse, Dieses geschieht intern, aber auch durch Hinzuziehung von Peer Reviewern und einer Adopters Group bestehend aus Vertretern von potentiellen Käufern und Nutzern von 4Video. Jeweils zu den Meilensteinen werden im AP 2 umfangreiche Tests und Analysen durchgeführt. Dies umfasst im Bereich Usability-Analyse gängige Analyseverfahren wie Heuristische Evaluation und Cognitive Walkthrough. Im Bereich Usability-Tests werden dann klassische, szenariobasierte Usabili-ty-Tests mit einem Fokus auf Detail-Optimierung von Interaktionsprozessen durchgeführt. Neben szenariobasierten Usability-Tests werden Experteneinschätzungen und On-Site-Befragungen (inkl. Benchmarking) hinzugezogen sowie Konzept-/Design-Tests (on- und offline) zum Einsatz kom-men. Eine weitere geplante Test-Methode sind taskbasierte Online-Befragungen und Tracking des Klickverhaltens. Die Kontrolle der Zielkriterien bei Meilenstein 1 erfolgt nach folgenden Parametern

a) Qualitative Bewertung des Lastenhefts, des Proof of Concepts und der Use Cases durch Peer Reviewer

Die Kontrolle der Zielkriterien bei Meilenstein 2 erfolgt nach folgenden Parametern b) Qualitative Bewertung des Pflichtenhefts durch Peer Reviewer c) Adäquate technische Spezifikation der Phasen 1 - 3 d) Adäquate Definition der Märkte und des Wettbewerbs

Die Kontrolle der Zielkriterien bei Meilenstein 3 erfolgt nach folgenden Parametern


Seite 13

a) Usability-Testing, Usability Analyse in einem einwöchigen Spezialtest b) Validierung der technischen Entwicklung der Phase 1 c) Qualitative Bewertung der Produktdefinition und Feature-Liste durch Peer Reviewer


a) Usability-Testing, Usability Analyse in einem einwöchigen Spezialtest b) Validierung der technischen Entwicklung der Phase 2 c) Qualitative Bewertung des Vertriebskonzepts v1.0 durch Peer Reviewer


a) Qualitative Bewertung des Marketingkonzepts v1.0 und Vertriebsplans durch Peer Reviewer b) Validierung der technischen Entwicklung der Phase 3 c) Usability-Tests und Usability-Analysen


d) Qualitative Stresstest-Bewertung e) Quantitative Stresstest-Bewertung f) Usability-Tests und Usability-Analysen


Seite 14

2 Arbeitspakete und Termine

2.1 Übersicht Arbeitspakete AP-Nr.

Name des Arbeitspaketes AP Ver-antwor-tung

Start

Ende

1 Technische Validierung + Usability 2 M01 M12

2 Proof of Concept 1 M01 M03

3 Funktionale Spezifikation (Lastenheft) 4 M01 M03

4 Technische Spezifikation (Pflichtenheft) 5 M02 M05

5 Entwicklung Phase 1 – APIs Multi-content Redaktions-systeme

5 M05 M07

6 Entwicklung Phase 2 – Me-dienbibliothek und Enrich-ment

5 M08 M11

7 Entwicklung Phase 3 – Mul-ti-Device Auslieferungs-schnittstelle

5 M11 M12

8 Integration, Testing, De-monstrator 2 M08 M12

Tabelle 4: Arbeitsplan im Überblick 2.2 Arbeitspakete im Detail Das 4Video-Projekt besteht aus folgenden Arbeitspaketen: Arbeitspaket 1 – Technische Validierung und Usability Aufgabe 1.1: Durchführung von Usability-Analysen (Expertenorientiert / analytisch) Aufgabe 1.2: Durchführung von projektbegleitenden Usability-Analysen (Benutzerorientiert / empi risch) Aufgabe 1.3: Validierung der technischen Komponenten mit potentiellen Usern Aufgabe 1.4: Auswertung Ergebnisse Aufgaben 1.1-1.3 Erstellung von Pflichtenheft für Redesign AP-Beschreibung: In diesem Arbeitspaket wird die technische Entwicklung validiert. Dieses

geschieht intern, aber auch durch Hinzuziehung von Peer Reviewern und einer Adopters Group bestehend aus Vertretern von potentiellen Käufern und Nutzern von 4Video. Zusätzlich wird die Usability von 4Video analysiert und verbessert. Dieses geschieht durch umfangreiche qualitative und quantitative Usability Tests sowie durch Benchmarktesting.

Input: Input für dieses AP ist zum einen das vorliegende Dokument und zum anderen das Briefing durch die Projektleitung

Output: Das AP sorgt dafür, dass die Usability der Middleware den Anforderungen entspricht und validiert die einzelnen Komponenten der Entwicklungsplattform mit


Seite 15

potentiellen Usern aus dem Verlagsumfeld. Das Ergebnis sind Usability- und Benchmarkingreports.

Arbeitspaket 2 – Proof of Concept Aufgabe 2.1: Proof of Concept allgemein Aufgabe 2.2: Proof of Concept diverse Entwicklungsszenarien B2B AP-Beschreibung: In diesem Arbeitspaket wird für eine ausgewählte Anzahl von Nutzern ein Proof

of Concept entwickelt. Input: High-Level Business Plan des Unternehmens Output: Basierend auf den Resultaten des Proof of Concept sollen die funktionalen und

technischen Spezifikationsdokumente entwickelt werden. Durch die Proof of Concept-Phase werden mögliche Fehlentwicklungen weitgehend vermieden. Report mit Ergebnissen des Proof of Concept.

Arbeitspaket 3 – Funktionale Spezifikation, inkl. Lastenheft Aufgabe 3.1: Funktionale Spezifikation Phase 1 Aufgabe 3.2: Funktionale Spezifikation Phase 2 Aufgabe 3.3: Funktionale Spezifikation Phase 3 Aufgabe 3.4: Funktionale Spezifikation Gesamtsystem, semantisches Content-Enrichment und

Produkt nebst Lastenheft AP-Beschreibung: Die funktionale Spezifikation beschreibt die Funktionsweise des Systems aus

Nutzersicht (Use-Case). Innerhalb der funktionalen Spezifikation ergeben sich auch funktionale Testfälle, die innerhalb der Testphase geprüft werden.

Input: Ergebnisse der Proof of Concept Phase (AP3). Output: Beschreibung der funktionalen Zusammenhänge des Gesamtsystems,

Lastenheft. Arbeitspaket 4 – Technische Spezifikation und Architektur, inkl. Pflichtenheft Aufgabe 4.1: Architektur und technische Spezifikation Phase 1 Aufgabe 4.2: Architektur und technische Spezifikation Phase 2 Aufgabe 4.3: Architektur und technische Spezifikation Phase 3 Aufgabe 4.4: Architektur und technische Spezifikation Gesamtsystem, semantisches Content-

Enrichment und Produkt nebst Pflichtenheft AP-Beschreibung: Basierend auf der funktionalen Beschreibung, wird eine technische Architektur

entworfen, die die Zusammenhänge zwischen den einzelnen Modulen sowie den Systemfunktionen darstellt. Die technische Spezifikation dient als Input für die Entwickler, um mit der Programmierung zu beginnen.

Input: Funktionale Spezifikation (AP4) und Ergebnisse der Proof of Concept Phase (AP3)

Output: Beschreibung der technischen Zusammenhänge und Architektur Pflichtenheft. Arbeitspaket 5 – Entwicklung Phase 1 – Player nebst grafischer Benutzeroberflächen als Tem-plate-Sammlung Aufgabe 5.1: APIs zu multi-content Redaktionssystemen


Seite 16

Arbeitspaket 6 – Entwicklung Phase 2 – Medienbibliothek und semantisches Content-enrichement Aufgabe 6.1: Multicontent-Medienarchiv Aufgabe 6.2: Management/ Content Aufgabe 6.3: Content-Tagging Aufgabe 6.4: semantische Content-Verknüpfung Aufgabe 6.5: eReader-bezogene Darstellungstemplates Arbeitspaket 7 – Entwicklung Phase 3 – multi-device Auslieferungsschnittstelle Aufgabe 7.1: Administration, Aufgabe 7.2: Endgeräte-spezifische Formatumwandlung und Auslieferung Aufgabe 7.3: Contentfeed Arbeitspaket 8 – Integration, Testing und Demonstrator Aufgabe 8.1: Integration der einzelnen Module Aufgabe 8.2: Stresstests der einzelnen Module Aufgabe 8.3: Finaler Bau des Demonstrators

Projekt: 4Video - Middleware für die Anpassung von … · 2016-03-30 · Mit 4Video möchte M4...

Documents

Transcript of Projekt: 4Video - Middleware für die Anpassung von … · 2016-03-30 · Mit 4Video möchte M4...