BWL & FOM Wirtschaftsinformatik Blog

Fallstudie: Offene vs. geschlossene Systeme – Risikoanalyse am Beispiel Android und iPhone OS

1 Titel

Name der Autoren: Tobias Genge, Matthias Kurzer
Titel der Arbeit: „Offene vs. geschlossene Systeme – Risikoanalyse am Beispiel Android und iPhone OS“
Hochschule und Studienort: FOM Hamburg

2 Inhaltsverzeichnis

Inhaltsverzeichnis

[Verbergen]

2.1 Abkürzungsverzeichnis

Abkürzung Bedeutung
IEEE Institute of Electrical and Electronics Engineers
GPL General Public License
BSD-Lizenz Berkeley Software Distribution Lizenz
ASOP Android Open Source Project
CDD Compatibility Definition Document
CTS Compatibility Test Suite
USB Universal Serial Bus
WLAN Wireless Local Area Network
GPS Global Positioning System
SIM Subscriber Identity Module
3G 3rd Generation
UMTS Universal Mobile Telecommunications System
GSM Global System for Mobile Communications
GByte Gigabyte
IT Information technology

3 Abbildungsverzeichnis

Abb.-Nr. Abbildung
1 Risikomatrix

4 Tabellenverzeichnis

Tabelle Nr. Quelle
1 Vor- und Nachteile von quelloffener Software
2 Kategorisierung Android und iPhone OS
3 Ergebnisse der Szenarioanalyse

5 Einleitung

Nach der Einführung des iPad durch Apple im April 2010 erlebte der Bereich der Tablet PC einen starken Aufschwung. Gleichzeitig bieten viele weitere Hersteller Tablet PCs an. Für das iPad wird das Betriebssystem iPhone OS eingesetzt, für Tablet PCs anderer Hersteller zumeist Android. Hierbei stehen sich beide Betriebssysteme konträr gegenüber. iPhone OS ist proprietär, quellgeschlossen und nur für Endgeräte von Apple verfügbar. Android, welches durch das Android Open Source Project unter der Federführung von Google entwickelt wird, ist hingegen quelloffen und für verschiedenste Endgeräte unterschiedlicher Hersteller einsetzbar. Das iPad bzw. das Betriebssystem iPhone OS wird häufig als geschlossenes System bezeichnet.

Tablet PCs auf Basis von Android hingegen als offenes System. Gegenstand dieser Arbeit ist der Vergleich von offenen und geschlossenen Systemen anhand einer Risikoanalyse am Beispiel von Android und iPhone OS. Es soll die Frage beantwortet werden, welches System für Softwareentwicklungsfirmen die geringeren Risiken birgt. Die Risikoanalyse soll hierzu Informationen für die Entscheidungsfindung liefern, welches System als Entwicklungsplattform zu bevorzugen ist. Der Fokus der Risikoanalyse wird hierbei auf wirtschaftliche Risiken gelegt.

In dieser Fallstudie werden zunächst die Grundlagen und Begriffe erläutert.

Die Risikoanalyse wird anhand eines Szenarios durchgeführt.
Des Weiteren wird dargelegt, ob die Einordnung von Android als offenes System und iPhone OS als geschlossenes System zutreffend ist.

In der Risikoanalyse werden die schützenden Werte und die möglichen Gefahren sowie deren Folgen identifiziert. Daran anschließend sollen die Risiken bewertet und ergebnisorientiert dargestellt werden.

Schlussendlich wird der Risiko-Vergleich auf offene und geschlossene Systeme übertragen.

6 Grundlagen

6.1 System

Im folgenden werden die Begriffe „System, „Offenes System“ und „Geschlossenes System“ erläutert. Im Verlauf der Arbeiten für diese Studie ergab sich, dass auch dem Begriff „Halboffenes System“ Bedeutung zukommt. Daher wird dieser ebenfalls erläutert.

6.1.1 Begriff

Es gibt verschiedene Möglichkeiten, den Begriff „System“ zu definieren. Ursprünglich kommt der Begriff aus dem griechischen und beschreibt „…eine Einheit, die aus mehreren miteinander in Beziehung stehenden Elementen zusammengesetzt ist“[1]. Das „Digitale Wörterbuch der deutschen Sprache des 20. Jahrhunderts“ definiert System als eine zum Teil hierarchisch strukturierte „Gesamtheit von Aussagen, die eine Einheit bildet“, andererseits aber auch eine „sinnvolle Ordnung, Gliederung von etwas“ darstellt[2].

„Ein System hat eine begrenzte geografische Ausdehnung aus unabhängigen, jedoch untereinander verbundenen und miteinander wechselwirkenden Komponenten oder Subsystemen. Ein System reagiert (üblicherweise) auf äußere Einflüsse.“[3] Systeme lassen sich in offene und geschlossene Systeme einteilen, wobei insbesondere bei Softwaresystemen eine Verwechslung von offenen Systemen und offener Software zu vermeiden ist[4].

6.1.2 Offenes System

Die IEEE (Institute of Electrical and Electronics Engineers) definierte offene Systeme im Dezember 1990: „OPEN SYSTEM ENVIRONMENT: a comprehensive and consistent set of international information technology standards and functional standards that specify interfaces, services and supporting formats to accomplish interoperability and portability of applications, data and people….“[5] Somit gehören zu einem offenen System nicht nur die Technik, sondern auch die Daten und die Menschen. Etwas enger definiert Tom Wheeler offene Systeme als „jene Hard- und Software-Implementierungen, die der Sammlung von Standards entsprechen, die den freien und leichten Zugang zu Lösungen verschiedener Hersteller erlauben. Die Sammlung von Standards kann formal definiert sein oder einfach aus De-facto-Definitionen bestehen, an die sich die großen Hersteller und Anwender in einem technologischen Bereich halten.“[6] Wichtige Merkmale sind demnach Portierbarkeit, Skalierbarkeit und Interoperabilität. M: Bues fügt noch Standards als „Fundamente für Interoperabilität und Portabilität“ hinzu[7].

Interoperabilität gilt dabei als das wichtigste Merkmal bzw. auch Ziel eines offenen Systems. Verschiedene Systeme mit unterschiedlichen Funktionen von teilweise verschiedenen Herstellern arbeiten gemeinsam um ein Ziel zu erreichen. Für den Anwender sollte sich dieser Verbund als ein homogenes System darstellen[8].

Portabilität, was Übertragbarkeit bedeutet, bezieht sich nach der Definition der IEEE nicht nur auf die Anwendungen, die auf verschiedenen Systemen lauffähig sein soll, sondern auch auf die Daten und Menschen. Der Wechsel zwischen den Systemen sollte keinen zusätzlichen Lernaufwand bedeuten[9].

Skalierbarkeit kann auch als Unterpunkt der Portierbarkeit gesehen werden, nämlich die Portierbarkeit auf größere bzw. kleinere Systeme[10].
Offene Systeme haben sowohl für den Anwender als auch für den Hersteller einige Vorteile. Der Anwender verspricht sich:

  • Reaktionsschnelligkeit, da offene Systeme sich schnell auf äußere Einflüsse einstellen können
  • Kooperationsfähigkeit, offene Systeme können mit anderen offenen Systemen kommunizieren
  • Investitionsschutz durch Erweiterung und Skalierung der offenen Systeme
  • Unabhängigkeit durch Verringerung der Abhängigkeit von einem Hersteller und da sich Komponenten verschiedener Hersteller zu einem System zusammenfügen lassen
  • Integrationsfähigkeit, da sich offene Systeme optimal an Erfordernisse anpassen lassen

Aus den genannten Punkten ergibt sich weiterhin der Vorteil der:

  • Wirtschaftlichkeit[11].

Der Hersteller kann durch offene Systeme eine größere Anwendergemeinschaft erreichen und seine Entwicklungskosten reduzieren[12]. Wichtig sind hierbei Schnittstellen. Sie stellen definierte Übergänge zwischen den Systemen dar und können auch selbst Systeme sein. Zum Beispiel stellt ein Satellitenreciever die Schnittstelle zwischen dem Satelliten und dem Fernseher dar und bildet selbst ein System.

6.1.3 Geschlossenes System

In der Literatur finden sich kaum Definitionen von geschlossenen Systemen. Grundsätzlich gilt aber, dass geschlossene Systeme in bestimmten Kategorien oder in ihrer Gesamtheit nichts oder zumindest weniger als offene Systeme mit der Umwelt austauschen.

In der IT werden meist proprietäre Systeme mit geschlossenen Systemen gleichgesetzt, was aber nicht in jedem Fall zutreffend ist [13]. Andererseits meint die IT mit „geschlossenem System“ oft auch Systeme „aus einem Guss“, bei denen alle Komponenten perfekt zueinander passen und aufeinander abgestimmt sind. Diese Systeme können dann aus Komponenten eines einzigen Herstellers bestehen. Ebenso kann es aber auch um einen Verbund aus offenen Systemen handelt, die über Schnittstellen miteinander kommunizieren.

6.1.4 Halboffenes System

Teilweise wird auch von halboffenen Systemen gesprochen. Diese werden sehr stark vom Hersteller kontrolliert, sind aber im Bezug auf ihre eigentlichen Funktionen sehr offen[14]. Ein Beispiel ist die Automobilwelt. „Ein BMW 7er läuft mit dem gleichen Benzin wie ein Toyota Prius und hat eine zumindest ähnliche „Benutzeroberfläche“, aber abgesehen davon sind diese zwei Fahrzeuge sehr verschieden. Niemand würde auf die Idee kommen, dass BMW-Ersatzteile auch im Prius funktionieren sollten. Autos teilen sich eine gemeinsame, offene Infrastruktur (das Tankstellennetz, das standardisiertes Benzin verkauft) und gewisse Bedienungsprinzipien (Steuerrad, Gaspedal etc.), aber ansonsten sind die Produkte sehr verschieden und proprietär.“[15] Auch in der IT ist ein Trend zu halboffenen Systemen erkennbar. So ist beispielsweise Google in vielen Bereichen sehr offen und nutzt quelloffene Elemente. Der Kernbereich, die Google Suchmaschine, ist jedoch geschlossen[16]. Hierdurch entstehen Produkte, die für den Konsumenten einfach und problemlos zu nutzen sind. Die Funktionsweise bleibt dem Nutzer jedoch verborgen.

6.2 Quelloffenheit

6.2.1 Quelloffenheit

Quelloffene Software (engl. Open Source) wird im allgemeinen Sprachgebrauch häufig mit offenem System gleichgesetzt. Die Begriffe dürfen jedoch nicht als Synonym gesehen werden. Quelloffene Software kann sowohl ein offenes wie auch ein geschlossenes System sein. Das Gegenteil von Quelloffenheit ist Quellgeschlossenheit (engl. Closed Source), nicht etwa geschlossenes System[17]. Allerdings ist es aufgrund der Eigenschaft von quelloffener Software durchaus möglich, aus einem geschlossenen System ein offenes zu machen.

Die wichtigste Eigenschaft von quelloffener Software ist, wie der Name bereits verdeutlicht, dass der Quellcode offen gelegt wird. Das fertige Programm muss sich hinsichtlich der Funktion nicht von Programmen in quellgeschlossener Software unterscheiden. Lediglich die Art der Erstellung, Verbreitung und Weiterentwicklung der Programme unterscheidet sich[18]. Quelloffene Software erweitert die Befugnisse des Anwenders im Gegensatz zu anderen Softwareformen erheblich[19]. Dabei geht es nicht nur um den kostenlosen bzw. sehr günstigen Erwerb der Software, sondern auch um die Rechte, die Software zu verändern, für beliebige Zwecke einzusetzen und an andere weiter zu geben[20]. Dabei ist zu beachten, dass auch quelloffene Software Lizenzen unterliegt. Die Opensource Initiative (http://www.opensource.org/docs/osd) entwickelte eine Liste von Anforderungen die Lizenzen erfüllen müssen, um als quelloffene Software anerkannt zu werden:

  • „Freie Weitergabe – Die Lizenz darf niemanden in der Weitergabe einschränken.
  • Es dürfen keine Lizenzgebühren oder andere Beiträge erhoben werden.
  • Quellcode – Der Quelltext der Software muss in einer verständlichen Programmiersprache öffentlich zugänglich vorliegen.
  • Modifizierte Versionen – Modifizierte Versionen müssen die gleichen Lizenzbedingungen wie das Original erhalten.
  • Unversehrtheit des Originalcodes – Bei der Verbreitung von verändertem Quellcode muss genau gekennzeichnet werden, welche Teile des Codes aus dem Original stammen und welche hinzuprogrammiert worden sind. Diese Änderungen müssen in einem externen Dokument festgehalten werden und zusammen mit der Software zur Verfügung stehen.
  • Keine Diskriminierung einzelner Personen oder Gruppen – Es gibt keine Einschränkung bei der Anzahl der Benutzer oder der Installationen. Zudem dürfen keine Personen oder Gruppen von dem Gebrauch ausgeschlossen werden.
  • Keine Einschränkung der Anwendungsbereiche – Die Lizenz darf kein bestimmtes Einsatzgebiet einschränken.
  • Verbreitung der Lizenz – Der Lizenz dürfen keine weiteren Klauseln hinzugefügt werden.
  • Die Lizenz darf nicht nur für ein bestimmtes Produkt gelten – Wenn in Softwarepaketen enthaltene Open-Source-Programme einzeln weiterverbreitet werden, gilt für diese parat stehende Anwendung dieselbe Lizenz wie für das Ausgangspaket.
  • Die Lizenz darf keine andere Software beeinträchtigen – Die Lizenz darf keine Programme, die beispielsweise in demselben Softwarepaket enthalten sind, einschränken.“[21]

Quelloffene Software, die unter der General Public License (GPL) steht, muss bei Weitergabe oder Modifizierung erneut unter GPL Lizenz gestellt werden. Somit wird eine Lizenzänderung verhindert. Ebenso darf GPL-Software keine Module enthalten, die nicht unter GPL stehen[22].

Die Apache License der Apache Software Foundation ist deutlich offener. So kann selbst erstellte Software durchaus auf Apache lizenzierte Software aufbauen und muss trotzdem nicht nach dieser lizenziert werden. Allerdings muss kenntlich gemacht werden, das Software nach Apache License verwendet wurde[23].

Quelloffene Software beinhaltet Vorteile und Nachteile. Diese sind in nachfolgender Tabelle gegenübergestellt.

Tabelle 1:Vor- und Nachteile von quelloffener Software[24]
Vorteile Nachteile
Anpassbarkeit Keine Gewährleistungsrechte
Wiederverwendbarkeit von Code (Oft) kein Support durch Entwickler
Höhere Produktqualität Höherer Schulungsaufwand
Anbieterunabhängigkeit Ungewisse Weiterentwicklung
Höhere Sicherheit Applikationen teilweise nicht erhältlich
Offene Standards Teilweise mangelnde Interoperabilität mit kommerzieller Software
Keine Lizenzkosten

6.2.2 quellgeschlossene Software

Quellgeschlossene Software, häufig auch als proprietäre Software bezeichnet, gehört in der Regel dem Hersteller. Der Käufer der Software erwirbt lediglich die Nutzungsrechte an der Software. Die Software wird als Binary ausgeliefert, der Quelltext verbleibt beim Hersteller. Das bedeutet, dass auch nur der Hersteller in der Lage ist, die Software weiter zu entwickeln oder Fehler zu beheben[25].

Für das Nutzungsrecht muss der Anwender ein Entgelt entrichten. Dieses kann sich je nach Hersteller auf unterschiedliche Aspekte der Nutzung der Software beziehen. Beispiele sind:

  • Anzahl der Nutzer
  • Anzahl oder Wert der verwalteten Objekte
  • Dauer der Nutzung
  • Infrastruktur des Anwenders, zum Beispiel Anzahl der Prozessoren[26].

In neueren Lizenzmodellen sind diese Gebühren nicht nur einmalig, sondern in monatlichen oder jährlichen Intervallen zu entrichten. Dafür werden dem Anwender alle neuen und fehlerbereinigten Versionen der Software kostenlos zur Verfügung gestellt.

Die meisten Nachteile von quelloffener Software können als Vorteile von quellgeschlossener Software angesehen werden. Die wichtigsten im professionellen Umfeld sind Gewährleistung und Support. Allerdings versuchen die Anbieter proprietärer Software zunehmend durch entsprechende Klauseln in den Lizenzbestimmungen auch die Gewährleistung und den Support einzuschränken[27].

6.3 Tablet PCs

6.3.1 Begriff

Tablet PCs sind wenige Zentimeter flache und tragbare Computer. Sie haben weder Maus noch Tastatur. Die Bedienung erfolgt direkt über den als Touchscreen ausgeführten Bildschirm. Je nach eingesetzter Technologie kann die Bedienung direkt mit den Fingern erfolgen oder mit einem drahtlosen Eingabestift[28].

6.3.2 Anwendungsbereich

In der Regel sind Tablet PCs leicht, handlich und haben eine lange Akkulaufzeit[29]. Dadurch können sie mobil eingesetzt werden. Im Gegensatz zu Notebooks benötigen Tablet PCs zudem keine Ablagefläche und können so im Stehen bedient werden. Damit ergeben sich für Tablet PCs Anwendungsbereiche, die für ein Notebook nicht infrage kommen. Beispielsweise in der Gastronomie zur Aufnahme von Bestellungen oder in Lagerlogistik zur Kontrolle von Waren.

6.3.3 Android

Android ist ein freies quelloffenes Betriebssystem für mobile Geräte wie beispielsweise Smartphones oder Tablet PCs. Die Entwicklung von Android wird vom Android Open Source Project (AOSP) unter der Leitung des Unternehmens Google durchgeführt[30]. Als Projektziel nennt das AOSP die Schaffung eines offenes Systems, indem kein Softwarehersteller die Anwendung anderer Software beschränken oder verbieten kann[31]. Android liegt aktuell in der Version 2.2 vor[32].

6.3.3.1 Technik

6.3.3.1.1 Software

Das AOSP hat klare Richtlinien geschaffen, wie Hardware- (z.B. Tablet PCs) bzw. Software-Entwicklungen erstellt werden müssen, damit diese den Anforderungen von Android entsprechen. Dazu hat das AOSP das Android Compatibility Program geschaffen. Dieses enthält definierte Richtlinien für Hardware- und Softwarehersteller, die Android als Plattform verwenden wollen. Diese Richtlinien sind im CDD niedergeschrieben. Weiterhin umfasst das Android Compatibility Program auch Tools mit denen sich die Kompatibilität prüfen lässt[33]. Diese Tools sind in der Compatibility Test Suite (CTS) zusammengefasst [34].

6.3.3.1.2 Hardwareanforderungen

Im CDD sind konkrete Vorgaben definiert, an die sich ein Gerätehersteller halten muss, wenn dieser Android einsetzen will. Verwendet ein Gerätehersteller beispielsweise eine Hardwarekomponente, die standardmäßig über eine Schnittstelle für Entwickler verfügt, so muss diese Schnittstelle auch implementiert werden. Der Gerätehersteller verpflichtet sich weiterhin folgende Schnittstellen und Funktionen in das Gerät zu integrieren:

  • USB
  • Touchscreen
  • WLAN
  • Kamera
  • Kompass
  • GPS
  • Mindestens 290 MB nicht flüchtiger Speicher[35]

Diese Liste ist nicht komplett. Soll aber aus Gründen des Umfanges nicht weiter beleuchtet werden.

6.3.3.2 Apps

Für Android Systeme lassen sich Anwendungen (engl. Applications, Abk. Apps) hinzukaufen, welche die Funktionalität des Tablet PCs erweitern können. Diese Apps können zum einen im Android Market erworben werden, zum anderen gibt es aber auch weitere Bezugsquellen für Apps, z.B. http://www.androidfreeware.org/. Im Android Market stehen aktuell mehrere Zehntausend Apps zur Verfügung[36]. Ein Beispiel für ein Android App ist „Wikitude“. Mit diesem lassen sich Restaurants und Sehnswürdigkeiten etc. anzeigen, die sich in der Nähe des Tablet PC-Anwenders befinden[37].

6.3.3.3 Geschäftsmodell

Android steht unter Apache 2.0 Lizenz. Hier gibt es jedoch in Einzelfällen Ausnahmen. Beispielsweise ist der für Android verwendete Linux Kernel unter GPLv2 lizenziert[38]. Das Betriebssystem Android wird Herstellern von mobilen Endgeräten und Anwendern frei zur Verfügung gestellt. Dennoch verfolgt Google mit der Verbreitung von Android eine Gewinnerzielungsstrategie. Ziel ist, durch standortabhängige Werbung Einnahmen zu erzielen[39].

6.3.4 iPhone OS

Das Apple Betriebssystem iPhone OS wird für die Geräte iPod, iPhone und für das iPad verwendet. iPhone OS basiert auf dem Macintosh Betriebssystem Mac OS X, mit dem es viele Funktionalitäten gemeinsam hat. Jedoch ist iPhone OS auf mobile Endgeräte spezialisiert. So besitzt es im Gegensatz zu Mac OS X Funktionen für Touchscreens und Bewegungssensoren[40].

6.3.4.1 Technik

6.3.4.1.1 Hardware

iPhone OS ist nur auf Apple Hardware installiert. Im Tablet PC Bereich wird aktuell nur das iPad angeboten. Apple liefert auf seiner Homepage einige Daten zum iPad, so ist es ca. 24 cm mal 19 cm groß und etwa 13,5 mm dick. Dabei wiegt es je nach Modell zwischen 680 g und 730 g. Die Eingabe erfolgt ausschließlich über einen 9,7 Zoll Touchscreen, sonstige Bedienelemente gibt es nur für den Ein-/Ausschalter, die Verriegelung des Displays und die Lautstärkeregelung. Folgende Ein- und Ausgänge werden zur Verfügung gestellt:

  • 30-poliger Dock-Anschluss
  • Stereo-Kopfhöreranschluss (3,5 mm)
  • Integrierter Lautsprecher
  • Mikrofon
  • Fach für Micro-SIM-Karte (nur beim Wi-Fi + 3G Modell)

die Kommunikation mit der Außenwelt erfolgt ansonsten per

  • Bluethooth
  • WLAN/Wi-Fi
  • und bei einigen Modellen 3G (UMTS/GSM).

Seinen Standort kann das iPad über die Funknetze oder per GPS ermitteln.
Es gibt Sensoren für das Umgebungslicht und einen Beschleunigungssensor, der auch die Informationen für das Umschalten zwischen Hoch- und Querformat liefert.
Es gibt Modelle mit 16GByte, 32GByte oder 64 GByte Flashspeicher.
Somit unterscheiden sich die verfügbaren Modelle nur in ihrer Speicherkapazität und dem Vorhandensein eines 3G Moduls[41].

6.3.4.1.2 Software

Das iPad wird derzeit ausschließlich mit iPhone OS in der Version 3.2. ausgeliefert. Andere Betriebssysteme sind bislang nicht lauffähig. Das iPhone OS 3.2 ist eine geringfügig erweiterte Version des Betriebsystems für das iPhone. So verbessert sich die Bedienbarkeit des iPad durch zwei neue Gesten für den Touchscreen, es wird der Anschluss eines externen Monitors unterstützt sowie eine Erleichterung bei der Eingabe von Texten eingebaut[42].
Einige Programme wie Browser, Mailprogramm und Bookreader sind im Lieferumfang des Betriebssystemes enthalten. Außerdem lassen sich viele Funktionen mittels Apps nachrüsten. Diese Apps müssen im Apple App Store bezogen werden. Eine andere Bezugsmöglichkeit ist von Apple nicht vorgesehen. Am 7. Juni 2010 hat Apple iPhone OS in iOS umbenannt. Außerdem wurde die Version 4.0 angekündigt. Diese unterstützt unter anderem Multitasking[43].

6.3.4.2 Apps

Ähnlich wie Android Systeme, lässt sich auch die Funktionalität des iPads durch Apps erweitern. Im Apple App Store sind zurzeit über 150.000 Apps verfügbar. Nutzer von iPods und iPhones haben zudem die Möglichkeit ihre Apps auch für das iPad zu verwenden. Laut Aussage von Apple funktionieren fast alle dieser Apps auch für das iPad. Ein Beispiel für ein iPad kompatibles App ist das „Kindle“. Mit diesem lassen sich eBooks aus dem Amazon Kindle Store lesen, so dass das iPad als eBook-Reader verwendet werden kann[44].

6.3.4.3 Geschäftsmodell

Über Apples Geschäftsmodell kann nur spekuliert werden, da Apple keine Zahlen hierzu veröffentlicht. Neben dem Verkauf der Hardware und Software wird Apple aber wohl einen Teil des Gewinns aus seinen Online Stores für Musik, Videos, eBooks und Apps ziehen.

6.4 Risikoanalyse

Ein Risiko wird im Allgemeinen als etwas Negatives, Bedrohliches oder auch Zukünftiges und Ungewisses angesehen[45]. Das Zukünftige und Ungewisse kann betriebswirtschaftlich aber auch eine Chance sein, wenn die Abweichung in positiver Richtung stattfindet. So enthält auch das chinesische Schriftzeichen für Risiko die Zeichen für Chance und Gefahr. Diese Art des Risikos wird als entscheidungsorientiertes Risiko bezeichnet[46].

Beschrieben wird das Risiko durch die Häufigkeit bzw. Wahrscheinlichkeit des Eintritts des gefährdenden Ereignisses sowie durch das zu erwartende Schadensausmaß[47].

Eine betriebswirtschaftliche Definition nach Königs lautet: „Ein Risiko ist eine nach Häufigkeit (Eintrittserwartung) und Auswirkung bewertete Bedrohung eines zielorientierten Systems. Das Risiko betrachtet dabei stets die negative, unerwünschte und ungeplante Abweichung von System-Zielen und deren Folgen.“[48].

Tritt der Risikofall ein, können die Folgen je nach Gegenstand der Betrachtung unterschiedlich ausfallen. So kann es in Projekten zu Abweichungen bezüglich „Dauer“, „Budget“ und „Qualität“ kommen[49]. In der IT können die grundlegenden Sicherheitswerte „Vertraulichkeit“, „Integrität“ und „Verfügbarkeit“ betroffen sein[50].

Damit ein Risikofall eintreten kann, muss es eine Bedrohung geben[51]. In Projekten kann die Bedrohung darin bestehen, dass Mitarbeiter unzureichend qualifiziert sind, worunter die Qualität des Projektergebnisses leiden wird. In der IT ist eine mögliche Bedrohung das Ausspähen von Daten, wodurch die Vertraulichkeit dieser nicht mehr gegeben ist. Die Bedrohungen in der IT lassen sich in 4 Kategorien einteilen:

  • Menschen
  • organisatorische Mängel
  • technisches Versagen
  • höhere Gewalt[52].

Weiterhin muss es für einen Risikofall auch eine Schwachstelle geben, durch welche die Bedrohung Schaden anrichten kann[53]. In dem Projektbeispiel kann dies ein unzureichender Test bei der Auswahl der Projektmitarbeiter sein, beim IT-Beispiel eine Schwachstelle in der Firewallsoftware.

Aus diesen Bedrohungen und Schwachstellen ergibt sich dann die Wahrscheinlichkeit, mit welcher der Risikofall eintreten kann[54]. Ist also die Bedrohung durch einen unqualifizierten Mitarbeiter gering, da die zu besetzende Stelle kaum Qualifizierung erfordert, wird auch die Wahrscheinlichkeit des Eintritts des Risikofalls „unzureichend qualifizierter Mitarbeiter“ gering sein.

Tritt der Risikofall ein, kommt es zu einem Schaden.

Der Begriff Analyse bezeichnet eine Untersuchung wie auch Zergliederung eines Ganzen in seine Teilbereiche. In der Risikoanalyse finden beide Möglichkeiten Anwendung. Zum einen als heuristische Untersuchung, zum anderen als Zergliederung eines Systems[55].

Die Risikoanalyse ist Teil des Risikomanagements. Hauptzweck ist die Ermittlung angemessener Sicherungsmaßnahmen. Des Weiteren kann eine Risikoanalyse zu einem verstärkten Sicherheitsbewusstsein der Mitarbeiter und Leitung führen. Das Verständnis relevanter Zusammenhänge wird verbessert. Nicht zuletzt werden mögliche Schwachstellen gefunden[56].

7 Risikoanalyse

7.1 Methodik

Um festzustellen ob der Einsatz eines offenen oder geschlossen Systems für Softwareentwicklungsformen die geringeren Risiken birgt, wird im Folgenden eine Risikoanalyse anhand eines Szenarios durchgeführt. Hierbei wird ein Risikovergleich zwischen dem als offenen System geltenden Android und dem als geschlossenen System geltenden iPhone OS bzw. iPad gezogen. Dabei soll die Risikoanalyse in Anlehnung an die Arbeit von Freiling[57] folgende Phasen durchlaufen werden:

  • Szenario: Es wird ein Szenario aufgestellt, indem eine virtuelle Firma geschaffen wird. Dazu wird ein Geschäftsfall entwickelt, auf den die Risikoanalyse angewendet wird.
  • Analysebereich: Im Anschluss wird der Analysebereich eingegrenzt. Dies ist notwendig, um die Übersicht zu bewahren und die Untersuchung nicht ausufern zu lassen. Des Weiteren soll erkennbar sein, welche Bereiche die Risikoanalyse abgedeckt und welche Bereiche für einen speziellen Anwendungsfall noch zu untersuchen sind.
  • Typisierung der Alternativen: Es soll untersucht werden, inwieweit sich iPhone OS und Android in offene und geschlossene Systeme kategorisieren lassen.
  • Szenarioanalyse: Die Szenarioanalyse unterteilt sich in einzelne Unterbereiche:
    • Identifikation der zu schützenden Werte: Hier wird untersucht, welche Werte tatsächlich relevant für das Unternehmen bzw. das Projekt sind. Nur wenn diese Werte gefährdet sind, besteht tatsächlich ein Risiko.
    • Identifikation von Gefahren: Hier werden die Gefahren identifiziert, welche die relevanten zu schützenden Werte tatsächlich bedrohen können.
    • Gefährdungsanalyse: In diesem Abschnitt werden die möglichen Folgen beim Eintritt einer Gefahr untersucht.
    • Risikobewertung: Hier wird eine Einschätzung der Wahrscheinlichkeit des Risikoeintritts und der Schadenshöhe vorgenommen. In diesem Szenario ist eine Arbeit mit genauen Geldwerten und prozentualen Wahrscheinlichkeiten nicht möglich. Daher wird die Kategorisierung an einer ordinalen Skalar durchgeführt.
    • Ergebnisse der Szenarioanalyse: Hier werden die Ergebnisse der Szenarioanalyse zusammengefasst und tabellarisch als auch grafisch dargestellt.
  • Risiko-Vergleich offene und geschlossene Systeme: In diesem Punkt werden die Ergebnisse der Szenarioanalyse, soweit es möglich ist, auf das Ursprungsthema offene und geschlossene Systeme portiert.

7.2 Szenario

Um festzustellen, ob der Einsatz eines iPad oder Android Systems für ein Unternehmen die geringeren Risiken birgt, wird eine Szenarioanalyse durchgeführt. Hierfür wurde folgendes Szenario aufgestellt:

Die GK Software GmbH ist ein Dienstelistungsunternehmen für IT Lösungen. Ein mittelständisches Gartenplanungsunternehmen, die Gartenplanung GmbH, tritt an die GK Software GmbH mit dem Auftrag heran, eine Lösung für die Vertriebsmitarbeiter zu entwickeln, die mit Tablet PCs ausgestattet werden sollen. Die insgesamt 10 Vertriebsmitarbeiter sollen beim Kunden vor Ort eine grobe Planung des Gartens erstellen. Die Wahl fiel auf den Einsatz von Tablet PCs, da die Planungssoftware fertige Gartenbauelemente enthalten soll, die einfach per Touchscreen im Gartenmodell angeordnet werden soll. Die Kunden der Gartenplanung GmbH sollen so den Gartenplanungsprozess der Vertriebsmitarbeiter verfolgen können und direkt bei der Planung mitwirken können. Zusätzlich soll der Tablet PC als digitaler Notiz- und Zeichenblock verwendet werden, um den Kunden einfache Skizzen zu präsentieren. Sobald der Kunde mit der Planung zufrieden ist, sollen alle planungsrelevante Daten über das Internet an einem Server der Gartenplanung GmbH übermittelt werden. Hierbei werden auch kundenbezogene Stammdaten wie Name und Adresse übertragen.

Die GK Software GmbH erhält den Auftrag eine entsprechende Gartenplanungssoftware als App zu entwickeln. Außerdem soll sie der Gartenplanung GmbH einen Vorschlag unterbreiten, welche Hardware einzusetzen ist. Die GK Software GmbH zieht die beiden Alternativen iPad und ein Android basiertes System in Betracht. Das Gartenplanungsapp soll zukünftig für die Gartenplanungsbranche eine neue Standardsoftware werden und nach Fertigstellung auch anderen Gartenplanungsunternehmen angeboten werden. Der Verkauf des Apps an weitere Unternehmen ist entscheidend, um die Entwicklungskosten zu decken und um Gewinne zu erzielen.

Vor Ausführung des Auftrages führt die GK Software GmbH eine Risikoanalyse durch, um zu ermitteln, für welche Plattform bei der Entwicklung, dem Vertrieb und beim späteren Einsatz des Apps die geringeren Risiken bestehen.

7.3 Analysebereich

In dieser Risikoanalyse wird der Schwerpunkt auf offene vs. geschlossene Systeme gelegt. Es soll untersucht werden, welche Risiken die Systeme beinhalten und ob aus unternehmerischer Sicht ein System zu bevorzugen ist. Diese Risikoanalyse wird aus Sicht der GK Software GmbH durchgeführt. Daher beinhaltet die Risikoanalyse einerseits wirtschaftliche Aspekte der GK Software GmbH (Entwicklungskosten, Zeitplanung), aber auch technische Aspekte für den späteren Betrieb beim Kunden. Die Risikoanalyse ist auch Grundlage für die Empfehlung eines Systems an den Kunden.

7.4 Typisierung der Alternativen

Zunächst werden Android und iPhone OS in die Kategorien offenes oder geschlossenes System eingeordnet. Für die Kategorisierung orientieren wir uns an den Merkmalen:

  • Portierbarkeit: Es soll untersucht werden, ob die Betriebssysteme und damit auch die Apps unter unterschiedlicher Hardware lauffähig sind.
  • Skalierbarkeit: Es soll untersucht werden, ob die Betriebssysteme um zusätzliche Funktionen erweitert werden können.
  • Interoperabilität: Es soll geprüft werden, ob das Betriebssysten mit anderen Systemen interagieren kann.
Tabelle 2: Kategorisierung Android und iPhone OS
Android iPhone OS
Portierbarkeit Android ist auf verschiedene Hardware Platformen portierbar. Damit ist es als Betriebssystem für Mobiltelefone, Netbooks, Tablet PCs und weitere Geräte verschiedener Hersteller einsetzbar.Um die Portierbarkeit sicherzustellen, müssen die Geräte den Richtlinien des CDD entsprechen. Damit ist Android weitesgehend portierbar. iPhone OS ist nur auf Apple Hardware lauffähig. Derzeit beschränkt sich der Einsatzbereich somit ausschließlich auf das iPod, iPhone und iPad. Somit ist iPhone OS nur auf Produkte von Apple portierbar. Im Bereich der Tablet PCs steht ausschließlich das iPad als Hardwareplattform zur Verfügung.
Skalierbarkeit Da Android quelloffen ist, lassen sich sowohl dem Betriebssystem als auch für den Anwender weitere Funktionen (z.B. über Apps) hinzuprogrammieren bzw. bestehende erweitern. Auch hier ist die Einhaltung der Richtlinien des CDD notwendig, um die Kompalität zu anderen Apps zu sichern. iPhone OS ist nicht quelloffen und daher nur durch Apple erweiterbar. Das Betriebssystem ist somit nicht frei skalierbar. Es existieren aber Schnittstellen durch die Anwenderfunktionen mittels Apps hinzugefügt werden können. Jeder Entwickler kann Apps für iPhone OS programmieren. Jedoch müssen die Apps durch Apple genehmigt werden. Daher kann iPhone OS nur als beschränkt skalierbar betrachtet werden.
Interoperabilität Wie auch bei der Skalierbarkeit gilt auch bei der Interoperabilität, dass sich nicht vorhandene Schnittstellen hinzuprogrammieren lassen. Daher können Android basierte Systeme theoretisch mit jedem IT-System kommunizieren und sind somit interoperabel. Bei iPhone OS sind Schnittstellen wie z.B. WLAN oder Software zur Nutzung des Internets vorhanden. Welche Schnittstellen angeboten werden bestimmt jedoch ausschließlich Apple. Zum einen da nur Apple iPhone OS anpassen kann, zum anderen müssen alle Apps durch Apple genehmigt werden. Die Fähigkeit zur Interoperabilität wird somit von Apple vorgegeben.

Android ist als offenes System zu betrachten, da es die vorgebenen Kriterien erfüllt. Beschränkungen kann es einzig durch die Richtlinien des CDD geben. iPhone OS kann weder als offenes noch als geschlossenes System angesehen werden. Geschlossene Systeme tauschen keinerlei Informationen mit der Außenwelt aus und besitzen keinerlei Schnittstellen. iPhone OS bietet jedoch sowohl Schnittstellen für den Anwender (bspw. durch die Internettauglichkeit), als auch für Entwickler, denen die Möglichkeit gegeben wird, Apps zu erstellen. Apple hat allerdings alleinige Entscheidungsgewalt über die angebotenen Schnittstellen und Apps und kann diese nach Belieben entfernen oder beschränken. Somit bestimmt Apple die Offenheit des Systems. Daher ist iPhone OS nicht als offenes System anzusehen sondern als halboffenes.

7.5 Szenarioanalyse

7.5.1 Identifikation der zu schützenden Werte

7.5.1.1 Sicherheitswerte

Da das zu erstellende App personenbezogene Kundendaten übertragen soll, ist der Schutz dieser Daten als besonders wichtig anzusehen. Das Bundesamt für Sicherheit in der Informationstechnik hat drei Sicherheitsziele für den Schutz von Daten festgelegt: Vertraulichkeit, Integrität und Verfügbarkeit.

  • „Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Vertrauliche Daten und Informationen dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein.“[58]
  • „Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Daten…“[59]
  • „Die Verfügbarkeit von Dienstleistungen, Funktionen eines IT-Systems, IT-Anwendungen oder IT-Netzen oder auch von Informationen ist vorhanden, wenn diese von den Anwendern stets wie vorgesehen genutzt werden können.“[60]

7.5.1.2 Wirtschaftliche Werte

Für die Entwicklung des Apps fallen Kosten an. Hierbei muss beachtet werden, dass diese sich im Rahmen der Kalkulation halten. Ebenso muss beachtet werden, dass das App in der mit dem Kunden vereinbarten Zeit fertiggestellt wird.

Auch die oben beschriebenen Sicherheitswerte beeinflussen wirtschaftliche Werte, da Probleme bei der Datensicherheit häufig auch zu finanziellen Schäden führen. Stehen beispielsweise Funktionen eines IT-Systems nicht zur Verfügung kann es zu Produktionsausfällen kommen.

7.5.2 Identifikation von Gefahren

7.5.2.1 Datensicherheit

Datensicherheit oder auch IT- und Informationssicherheit befasst sich mit dem Schutz von Informationen[61]. „IT-Sicherheit ist also der Zustand, in dem Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Informationstechnik durch angemessene Maßnahmen geschützt sind.“[62]

Für den Softwareanwender ergeben sich bzgl. der Datensicherheit beim Gartenplanungsapp folgende Gefahren:

  • Bezüglich dem Schutzziel der Vertraulichkeit:
    • Bei der Kommunikation zwischen Tablet PC und Server werden Kundendaten von dritter Seite abgefangen > Sehr leicht möglich bei unverschlüsselten WLAN Verbindungen.
    • Eine dritte Person verschafft sich unberechtigt Zugang auf den Tablet PC und stiehlt Daten > Zum Beispiel kann der Tablet PC verloren gehen oder gestohlen werden.
  • Bezüglich dem Schutzziel der Integrität:
    • Die an den Server übertragenen Daten werden durch einen Fehler verändert > Kann bei schlechten Verbindungen passieren, wenn die Software keine entsprechenden Fehlerkorrekturen vorsieht.
    • Die an den Server übertragenen Daten werden von dritter Seite manipuliert > Kann durch Viren auf dem Tablet PC passieren
    • Eine dritte Person verschafft sich unberechtigt Zugang auf den Tablet PC und manipuliert Daten > Wenn der Tablet PC verloren geht oder gestohlen wird.

Bezüglich dem Schutzziel der Verfügbarkeit:

  • Durch einen Angriff ist der Tablet PC nicht mehr verfügbar > Ein Virus kann den Tablet PC soweit in seiner Funktion stören, dass dieser nicht mehr benutzbar ist.
  • Die Übermittlung der Daten an den Server schlägt fehl, da das Apps aufgrund eines Softwarefehlers keine Verbindung zum Server aufbauen kann.

Neben technischen Faktoren existieren noch rechtliche und organisatorische Faktoren, die die Verfügbarkeit gefährden können. Diese sollen im folgenden Kapitel „Dienstleistungsausfall“ beleuchtet werden.

7.5.2.2 Dienstleistungsausfall

Dienstleistungsausfall bedeutet in dieser Arbeit, das vereinbarte Dienstleistungen nicht oder nicht vollständig erbracht werden können. Das kann sowohl zwischen der GK Software GmbH und der Gartenplanung GmbH als auch später zwischen der Gartenplanung GmbH und ihren Kunden der Fall sein. Im ersten Fall kann das geplante App nicht oder nicht den Anforderungen entsprechend fertig gestellt werden, im zweiten Fall kann die Gartenplanung GmbH ihrem Kunden die Dienstleistung der Gartenplanung nicht erbringen.

Bezüglich des Dienstleistungsausfalls bestehen somit folgende Gefahren:

  • Gefahren für die Gartenplanung GmbH:
    • Notwendige Schnittstellen können wegfallen. > Das Betriebssystem stellt Schnittstellen zur Verfügung, über die auf die Hardware des Tablet PC und externe Dienste zugegriffen werden kann. Der Hersteller des Betriebssystems kann nun festlegen, das zukünftig z.B. die Bluetooth Schnittstelle entfällt und so der Abgleich des Tablet PC mit externen Geräten nicht mehr möglich ist.
    • Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind. > So kann der Kunde nach einiger Zeit feststellen, dass der Abgleich über das Internet nicht optimal ist und ein Abgleich über z.B. Bluetooth besser wäre. Das Betriebssystem muss diese Schnittstelle unterstützen bzw. es muss die Schnittstelle nachrüstbar sein.
    • Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden. Eventuell läuft das App auf der neuen Plattform nicht mehr. > Es könnte sich herausstellen, das schnellere Hardware benötigt wird.
    • Das App kann von zentraler Stelle (Android oder Apple) deaktiviert werden[63]
  • Gefahren für die GK Software GmbH:
    • Notwendige Schnittstellen können wegfallen. > s.o.
    • Das App wird von zentraler Stelle (Android oder Apple App Store) nicht zugelassen oder zu einem späteren Zeitpunkt deaktiviert[64].
    • Der Entwicklungsaufwand ist größer als kalkuliert.

7.5.3 Gefährdungsanalyse

7.5.3.1 Datensicherheit

Wie in Kapitel 7.5.2.1 ausgeführt, beziehen sich die folgenden Punkte auf die Gartenplanung GmbH.
Daher bezieht sich der Begriff „Kunden“ in diesem Abschnitt auf die Kunden der Gartenplanung GmbH.

  • Mögliche Folgen bei Verletzung der Vertraulichkeit:

Werden aufgrund mangelnder Datensicherheit Kundendaten ausgespäht, könnte eine andere Gartenbaufirma diese Daten nutzen, um dem Kunden ein besseres Angebot zu machen. Dadurch kommt es für die Gartenplanung GmbH zu Umsatzausfällen.

Handelt es sich beim Kunden um eine Privatperson, können personenbezogene Daten ausgespäht werden. Dies führt zur Verletzung des informationellen Selbstbestimmungsrechts der betreffenden Person. Neben zivilrechtlichen Konsequenzen kann dies negative Auswirkungen auf das Unternehmensimage nach sich ziehen.

  • Mögliche Folgen bei Verletzung der Integrität:

Wenn Daten bei der Übertragung vom Tablet PC an den Server manipuliert oder aufgrund eines Softwarefehlers verloren gehen, besteht die Gefahr, dass Kundenaufträge falsch oder gar nicht ausgeführt werden. Dies kann zu Pflichtverletzungen bei Verträgen führen, was der Beziehung zum Kunden schadet oder gar Rechtsstreitigkeiten zur Folge haben kann. Die Nichterfüllung oder Falschausführung von Aufträgen sowie eventuelle Rechtsstreitigkeiten richten finanzielle Schäden an.

Mögliche Folgen bei Verletzung der Verfügbarkeit werden im folgenden Kapitel erläutert.

7.5.3.2 Dienstleistungsausfall

Wenn das App bzw. der Tablet PC nicht oder nur eingeschränkt zur Verfügung steht, kann es zu Dienstleistungsausfällen kommen.

  • Folgen für die Gartenplanung GmbH:
    • Notwendige Schnittstellen können wegfallen. Das App wird nicht mehr funktionieren und muss angepasst oder auf ein anderes System portiert werden. Dies führt zu Umsatzausfällen und zusätzlichen Kosten für die Anpassung bzw. Portierung.
    • Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind. Wenn diese Schnittstelle vom Betriebssystem nicht angeboten wird, muss das App auf ein anderes portiert werden. Das führt zu höheren Kosten als ursprünglich vorgesehen.
    • Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden. Eventuell läuft das App auf der neuen Plattform nicht mehr. Wenn das Betriebssystem auf keinen alternativen Hardwareplattformen lauffähig ist, muss das App portiert werden. Dies führt zu höheren Kosten.
    • Das App kann von zentraler Stelle (Android Market oder Apple App Store) deaktiviert werden. Im schlimmsten Fall ist die Anwendung auf absehbare Zeit nicht nutzbar. Der gesamte Gartenplanungsprozess muss angepasst werden, da nicht mehr auf die Tablett PC Variante gesetzt werden kann. Dies kann zu Umsatzverlusten und zusätzlichen Kosten führen.
  • Folgen für die GK Software GmbH:
    • Notwendige Schnittstellen können wegfallen. Das App wird nicht mehr funktionieren und muss angepasst oder auf ein anderes System portiert werden. Das App kann bis zur erfolgten Anpassung nicht an andere Gartenplanungsunternehmen verkauft werden. Dies führt zu Umsatzausfällen und zusätzlichen Kosten für die Anpassung bzw. Portierung.
    • Das App kann von zentraler Stelle (Android oder Apple App Store) nicht zugelassen oder zu einem späteren Zeitpunkt deaktiviert werden. Im schlimmsten Fall ist die Anwendung auf absehbare Zeit nicht nutzbar. Ist eine Einigung mit dem Betreiber des Market nicht möglich, kann dies zu Umsatzverlusten und Vertragsstrafen führen.
    • Der Entwicklungsaufwand ist größer als kalkuliert. Führt zu höheren Kosten bei der Entwicklung des Apps und eventuell zu Vertragsstrafen, da das App verspätet übergeben wird.

7.5.4 Risikobewertung

Die zuvor identifizierten Gefahren und deren mögliche Folgen werden in diesem Kapital bewertet. Ziel dabei ist es festzustellen, bei welchem System das geringste Risiko zu erwarten ist. Um das Risiko zu ermitteln werden die beiden Größen „Eintrittswahrscheinlichkeit“ und „Schadenshöhe“ zueinander in Bezug gebracht. Die Eintrittswahrscheinlichkeiten der ermittelten Gefahren lassen sich nicht in Zahlen messen. Hierfür ist der Einblick in beide Systeme zu gering bzw. die Vorhersehrbarkeit zukünftiger Entscheidungen von Apple und Google sind ungewiss. So lässt sich beispielsweise keine prozentuale Wahrscheinlichkeit festlegen, ob eine bestimmte Schnittstelle in Zukunft entfernt wird. Deshalb soll die Einschätzung der Schadenshöhe und Eintrittswahrscheinlichkeiten der Gefahren auf einer Ordinalskalar bewertet werden. Für die Ermittlung der Eintrittswahrscheinlichkeiten der Gefahren wurden folgende Kategorien gewählt:

  • Sehr gering: Der Eintritt des gefährdenden Ereignisses ist vernachlässigbar
  • Gering: Der Eintritt des gefährdenden Ereignisses ist unwahrscheinlich
  • Mittel: Durchschnittliche Wahrscheinlichkeit, dass das gefährdende Ereignis eintreten wird
  • Hoch: Das gefährdende Ereignis wird mit hoher Wahrscheinlichkeit eintreten

Bezüglich der Schadenshöhe wurden folgende Kategorien gewählt:

  • Sehr gering: Der Schaden ist komplett vernachlässigbar
  • Gering: Geringe finanzielle Verluste, die das Überleben der Unternehmung nicht gefährden
  • Mittel: Mittlere finanzielle Verluste, die zwar nicht zwangsläufig zum Konkurs führen, das Überleben der Unternehmung ist jedoch nicht gesichert
  • Exzistenzvernichtend: Der Schaden führt zum Konkurs der Unternehmung

Die Bewertung kann hier nur subjektiv erfolgen. Bei einer späteren Verwertung der Arbeit für einen konkreten Fall ist daher unbedingt eine Neubewertung entsprechend den dann geltenden Bedingungen vorzunehmen.

Um den Umfang dieser Arbeit nicht zu überschreiten, sollen in den folgenden Kapiteln nur noch die Risiken der GK Software GmbH betrachtet werden.

7.5.4.1 Dienstleistungsausfall

7.5.4.1.1 Android

Im Folgenden werden die ermittelten Gefahren für Android bewertet, indem Eintrittswahrscheinlichkeit und Schadeshöhe der Gefahr zugeordnet werden.

  • Notwendige Schnittstellen können wegfallen.

Es ist bisher nicht bekannt, dass das AOSP bestehende Schnittstellen entfernt hat. In den CDD ist sogar ausdrücklich festgelegt, dass Entwickler Schnittstellen implementieren müssen, wenn diese von einer Komponente zur Verfügung gestellt werden. Selbst wenn das AOSP zukünftig wichtige Schnittstellen im Android Betriebssystem entfernen würde, ließen diese sich aufgrund der Quelloffenheit Androids erneut einfügen. Die Wahrscheinlichkeit, dass Schnittstellen entfernt werden, kann somit als sehr gering bezeichnet werden. Die Schadenshöhe ist als gering zu bewerten, da lediglich geringe Programmieraufwände zu erwarten sind.

  • Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind.

Gründe für den Bedarf weiterer Schnittstellen können beispielsweise Fehler in der Konzeption sein, wenn notwendige Schnittstellen nicht eingeplant worden sind. Zusätzlich können sich die Anforderungen an das App ändern, wodurch ebenfalls neue Schnittstellen notwendig sind. Die Wahrscheinlichkeit, dass ein Bedarf an weiteren Schnittstellen besteht ist schwer ermittelbar. Mittelfristig gesehen, kann das Risiko als gering betrachtet werden, wenn bei der Konzeption keine elementaren Fehler gemacht wurden.
Wie auch bei der Gefahr des Wegfalls einer Schnittstelle, können bei quelloffenen Systemen wie Android Schnittstellen hinzuprogrammiert werden, falls diese nicht bereits standardmäßig vom Betriebssystem zur Verfügung gestellt werden. Somit entsteht in diesem Fall nur ein geringer Schaden für die Hinzuprogramierung der Schnittstelle. Je nach Komplexität der Schnittstelle kann die Schadenshöhe jedoch variieren.

  • Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden.

Im Betrieb kann sich herausstellen, dass die Hardware nicht den Anforderungen entspricht. Beispielsweise kann die Anforderung an die Leistungsfähigkeit der Hardware höher sein als erwartet. Die Wahrscheinlichkeit hierfür kann als mittel betrachtet werden, da es zu viele Unsicherheiten gibt. Beispielsweise kann sich in der Entwicklung des Apps herausstellen, dass das App mehr Hardwareressourcen benötigt als erwartet. Hier muss geprüft werden, ob das jeweilige Endgerät nachgerüstet werden kann. Im schlimmsten Fall muss ein alternatives Endgerät eingesetzt werden. Da Android inklusive der Apps durch die Richtlinien der CDD auf den gängigsten Plattformen lauffähig ist, kann problemlos ein Alternativprodukt gefunden werden. Als Schaden fallen vor allem die Preise für neue Endgeräte und deren Konfiguration an. Der Kauf von neuen Endgeräten ist zwar mit Kosten verbunden, jedoch entsteht hierdurch in der Regel keine Existenzgefährdung. Der Schaden wird somit als gering kategorisiert.

  • Das App kann von zentraler Stelle deaktiviert werden.

Google besitzt die Möglichkeit installierte Android Apps zu deaktivieren. Mögliche Gründe für eine Deaktivierung sind im „Android Market Developer Distribution Agreement“ aufgeführt. Nach dieser Vereinbarung kann Google Apps deaktivieren, wenn diese:

  • Rechte Dritter verletzen
  • gegen geltendes Recht verstoßen
  • pornografische Inhalte enthalten
  • schädliche Inhalte, beispielsweise Viren, enthalten
  • Google oder den Hersteller des Endgerätes für etwas haftbar macht
  • wenn sonstige Verstöße gegen das „Android Market Developer Distribution Agreement“ oder gegen Bedingungen des Endgeräte-Herstellers vorliegen[65]

Im „Developer Distribution Agreement“ führt Google jedoch an, dass das Unternehmen keine Absichten verfolgt, Apps zu überwachen und deaktivieren. Stattdessen würde Google eine Prüfung nur durchführen, wenn Hinweise für eine Verletzung des „Developer Distribution Agreements“ vorliegen. Ob eine Verletzung der Vereinbarung vorliegt, liegt dabei im eigenen Ermessen von Google[66].

Im Gegensatz zu Apple ist in der Vertragsvereinbarung von Google eine Entschädigung für User vorgesehen, deren gekaufte Apps deaktiviert wurden. Voraussetzung ist, dass das App innerhalb eines Jahres nach Kauf deaktiviert wurde. Die Entschädigung muss hierbei der Entwickler des Apps tragen. Der Entwickler muss sämtliche Einnahmen, die er mit dem App getätigt hat, an Google zurückzahlen. Neben den Einnahmen muss auch für eventuell entstandene Schäden oder Kosten des Geldverkehrs (z.B. Transaktionskosten) aufgekommen werden[67].

Google hat von der Möglichkeit Apps zu deaktiveren bereits Gebrauch gemacht. So wurden 2009 Apps entfernt, mit denen sich das Smartphone G1 als Modem (bspw. um einen PC einen Internetzugang zu ermöglichen) umfunktionieren ließ. Die Deaktivierung erfolgte nach dem der Betreiber des G1 „T-Mobile“ Druck auf Google ausgeführt hatte[68].

Für Android Apps gibt es im Gegensatz zu iPhone OS mehr als nur eine Bezugsquelle. Neben diversen Websites, die Android Apps anbieten, besteht beispielsweise die Möglichkeit das App im .apk-Format (Android package file) auf das Endgerät zu übertragen und dort zu installieren[69]. Bei dieser Vorgehensweise wäre eine zentrale Deaktivierung des Apps nicht ohne weiteres möglich, da Google nichts über die Existenz des Apps wüsste.

Es konnten keine Hinweise gefunden werden, dass Google im großen Maße Apps deaktiviert. Die Wahrscheinlichkeit das Apps bei Einhaltung des Android Market Developer Distribution Agreements von Google gelöscht werden, kann somit als sehr gering bezeichnet werden. Eine größere Wahrscheinlichkeit bestünde, wenn das App einen Interessenskonflikt mit dem Mobilfunkbetreiber oder Google auslöst. Hier zeigt das Beispiel des G1 Smartphones, dass Google bereit ist, Apps zu deaktivieren.

Da der Entwickler von kostenpflichtigen Apps dazu verpflichtet ist, seine Kunden bei der Deaktivierung von Apps zu entschädigen, hängt die mögliche Schadenshöhe maßgeblich davon ab, wie viel Apps insgesamt im Umlauf gebracht wurden. Die sofortige Leistung von Entschädigungszahlungen kann die GK Software GmbH in Zahlungsschwierigkeiten oder sogar zur Zahlungsunfähigkeit bringen. Nach § 17 Insolvenzordnung ist Zahlungsunfähigkeit ein Insolvenzgrund. Daher wird die Deaktivierung des Gartenplanung Apps im schlimmsten Falle einen existenzvernichtenden Schaden anrichten.

  • Der Entwicklungsaufwand ist größer als kalkuliert.

Jedes größere Softwareprojekt birgt das Risiko, dass die zuvor vorgenommene Kalkulation vom tatsächlichen Entwicklungsaufwand abweicht. Bei der Entwicklung von Android Apps kommt erschwerend hinzu, dass die Programmierung an strenge Richtlinien gebunden ist. Diese Richtlinien sollen die Kompatibilität auf verschiedenen Endgeräten ermöglichen. So müssen beispielsweise diverse Schnittstellen programmiert werden oder unterschiedliche Bildschirmauflösungen diverser Endgeräte berücksichtigt werden. Im Android Market werden Apps nur gelistet, wenn diese den Kompatibilitätstest der CTS bestanden haben[70]. Durch die große Hardwarevielfalt an Android Endgeräten erhöht sich die Wahrscheinlichkeit, dass zwischen App und einigen Endgeräten eine Inkompalibilität aufkommt, die durch zusätzlichen Programmieraufwand beseitigt werden muss. Die zusätzliche Programmierung sowie das Testen auf Kompatibilität birgt eine hohe Wahrscheinlichkeit, dass Kalkulation und tatsächlicher Aufwand abweichen, wenn keine Pufferzeit eingeplant wird. Verzögerungen bei der Fertigstellung des Apps können im schlimmsten Falle hohe Konventionalstrafen sowie eine Belastung des Verhältnisses zum Kunden nach sich ziehen. Zusätzlich bleiben einkalkulierte Erlöse aus dem Verkauf des Apps aus. Hierdurch kann die GK Software GmbH im schlimmsten Falle zahlungsunfähig werden, so dass dieser Schaden als existenzvernichtend einzustufen ist.

7.5.4.1.2 iPhone OS

Im Folgenden werden die ermittelten Gefahren für iPhone OS bewertet, indem Eintrittswahrscheinlichkeit und Schadeshöhe der Gefahr zugeordnet werden.

  • Notwendige Schnittstellen und Technologien können wegfallen.

Apple hat in der Vergangenheit deutlich gemacht, dass die Entscheidung welche Technologien eingesetzt werden, einzig von Apple selbst getroffen werden. So hat Apple bewusst darauf verzichtet, die Flashtechnologie für iPhone OS zu implementieren, obwohl Flash eine weit verbreitete Technologie im Internet ist. So nutzt beispielsweise das Video Portal youtube.com den Adobe Flashplayer zum Abspielen der Videos[71]. Apple Geschäftsführer Steve Jobs begründete diese Entscheidung in einem offenen Brief. Darin nannte er als Gründe u.a., dass Flash eine veraltete Technologie sei und zudem viele Sicherheitslücken beinhalte[72]. Da Apple offenbar bereit ist, auch etablierte Technologien nicht zu implementieren, besteht die hohe Wahrscheinlichkeit, dass Apple bei zukünftigen iPhone OS Versionen oder Apple Endgeräten, Technologien nicht mehr unterstützen wird, die unter Umständen elementar für die Funktion des Gartenplanung Apps sind. Im schlimmsten Fall ist das Gartenplanung App auf zukünftigen Apple Geräten nicht mehr lauffähig. Der entstehende Schaden kann als „mittel“ kategorisiert werden. Entweder muss eine Neuprogrammierung des Apps stattfinden oder es muss einen Verzicht auf dem Vertrieb der Software für neue Geräte erfolgen.

  • Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind.

Die Wahrscheinlichkeit, dass ein Bedarf an weiteren Schnittstellen besteht ist schwer ermittelbar. Mittelfristig gesehen, kann das Risiko als gering betrachtet werden, wenn bei der Konzeption keine elementaren Fehler gemacht wurden. Da iPhone OS im Gegensatz zu Android quellgeschlossen ist, ist es nicht möglich weitere Schnittstellen hinzuzuprogrammieren. Somit ist eine Erweiterung des Apps nur begrenzt möglich. Sollten wichtige Schnittstellen bereits bei der Konzeption nicht bedacht worden sein und dies erst in der Entwicklung auffallen, müsste die Entwicklung für iPhone OS abgebrochen werden und das App auf ein anderes System portiert werden. Je nach Aufwand für die Portierung muss mit einem geringen bis mittleren Schaden für den zusätzlichen Programmieraufwand gerechnet werden.

  • Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden.

Wie auch beim Android System kann sich bei der Entwicklung des Apps herausstellen, dass das App mehr Hardware-Ressourcen benötigt als erwartet. Die Wahrscheinlichkeit kann auch hier als mittel eingeschätzt werden. iPhone OS ist nur auf Apple Endgeräten lauffähig. Sollte sich das eingesetzte Endgerät in der Praxis als ungeeignet erweisen, gibt es kaum Möglichkeiten ein alternatives Gerät zu finden. Hierbei kann nur auf die Apple Produktfamilie zurückgegriffen werden. Im Tablet PC Bereich steht zurzeit sogar ausschließlich das iPad in verschiedenen Produktvarianten zur Verfügung. Auch eine Aufrüstung des iPads ist nicht möglich. So lässt sich weder eigenständig der Akku austauschen noch der Speicher erweitern[73]. Im schlimmsten Fall wird das App nicht lauffähig sein und kann somit nicht eingesetzt werden. Wenn dies erst nach Fertigstellung des Apps erkenntlich wird, gibt es kurzfristig keine Möglichkeit den Vertrag mit der Gartenplanung GmbH fristgerecht zu erfüllen. Hier drohen hohe Konventionalstrafen, Umsatzausfälle, da das App nicht weiter vertrieben werden kann sowie Kosten für die Portierung auf ein alternatives System. Der größtmögliche Schaden wäre eine Zahlungsunfähigkeit der GK Software GmbH. Somit ist der Schaden als existenzvernichtend einzustufen.

  • Das App kann von zentraler Stelle deaktiviert werden.

Apps für Apple Systeme lassen sich ausschließlich über den Apple App Store beziehen. Eine andere Möglichkeit Software auf das iPad zu installieren gibt es nicht. Darüber hinaus verfügt Apple ähnlich wie Google auch über die Möglichkeit Apps zu deaktivieren. In der Vergangenheit wurde bereits mehrfach von dieser Möglichkeit Gebrauch gemacht. Das Internet Magazin „Mac Rumors“ berichtet, dass alleine im Februar 2010 über 5.000 Apps von Apple deaktiviert wurden. Dies seien 3% aller damals zur Verfügung stehenden Apps gewesen. Die Löschung der Apps wurde durchgeführt, da diese von Apple als sexuell anstößig eingestuft worden[74].

Doch nicht nur Apps mit sexuellen Inhalten wurden gelöscht. Auch Apps, die auf dem Dienst „Google Voice“ des Konkurrenten Google zurückgreifen, wurden gelöscht. Bei Google Voice handelt es sich um einen Dienst mit dem über das Internet telefoniert werden kann[75].

Als Begründung für die Löschung sämtlicher auf Google Voice basierender Apps führte Apple an, dass der Dienst die gleichen Funktionen wie das Betriebssystem iPhone OS bereitstelle (Internettelefonie)[76].

Die Wahrscheinlichkeit, dass das Gartenplanungsapp aus dem App Store entfernt wird, kann langfristig im mittleren Bereich gesehen werden. Dies begründet sich aus der Deaktivierung von tausenden Apps. Hier muss jedoch zur Relativierung hinzugefügt werden, dass die deaktivierten Apps hauptsächlich aus sexuellen Gründen deaktiviert wurden. Das Beispiel der auf Google Voice basierenden Apps zeigt jedoch, dass Apple auch Apps entfernt, wenn diese eine Konkurrenz zu eigenen Produkten darstellen oder auf einer Technologie der Konkurrenz basieren.

Im Gegensatz zu Android Apps gibt es bei iPhone OS keine Möglichkeit, die Apps auf einer anderen Plattform als über den Apple App Store zu vertreiben. Somit lässt sich bei einer Deaktivierung des Apps seitens Apple dem Anwender das App nicht mehr zur Verfügung stellen. Das App kann also nicht weiter vertrieben werden. Anders als bei Android gibt es bei Apple keine Vertragsbedingungen, die dem Entwickler verpflichtet die Käufer des Apps zu entschädigen. Der entstehende Schaden beschränkt sich also auf ausbleibende Verkaufserlöse. Allerdings besteht die Möglichkeit, dass das App sofort nach Veröffentlichung deaktiviert oder gar nicht erst zugelassen wird. In diesem Falle fallen als Schaden die gesamten Entwicklungskosten an. Wenn diese sich über Monate hingezogen haben, kann der Schaden im schlimmsten Falle als existenzvernichtend bezeichnet werden.

  • Der Entwicklungsaufwand ist größer als kalkuliert.

Wie bei jedem Softwareprojekt kann es auch bei der Entwicklung von Apps für das iPhone OS zu Fehlkalkulationen kommen. Im Gegensatz zu Android müssen aber weniger Vorgaben beachtet werden, da das Gartenplanung App nicht mit einer Vielzahl von Endgeräten kompatibel sein muss. Lediglich die Kompatibilität mit dem iPad muss sichergestellt werden. Dies vermindert die Wahrscheinlichkeit, dass eventuelle Inkompatibilitäten mit Endgeräten auftreten und ein zusätzlicher Programmieraufwand entsteht. Daher kann die Wahrscheinlichkeit als gering betrachtet werden. Erwartete Schäden sind schlimmstenfalls hohe Konventionalstrafen und eine Belastung des Verhältnisses zum Kunden. Zusätzlich bleiben einkalkulierte Erlöse aus dem Verkauf des Apps aus. Hierdurch kann die GK Software GmbH im schlimmsten Falle zahlungsunfähig werden, so dass dieser Schaden als existenzvernichtend einzustufen ist.

7.5.5 Ergebnisse der Szenarioanalyse

Die Ergebnisse der Szenarioanalyse sind in nachfolgender Tabelle dargestellt.

Tabelle 3: Ergebnisse der Szenarioanalyse
Gefahr Eintrittswahrscheinlichkeit Schadenshöhe
Android iPhone OS Android iPhone OS
Notwendige Schnittstellen / Technologien fallen weg sehr gering hoch gering mittel
Weitere Schnittstellen sind notwendig gering gering gering gering-mittel
Hardware entspricht nicht den Anforderungen und muss gewechselt werden mittel mittel gering existenzvernichtend
Das App wird von zentraler Stelle deaktiviert sehr gering mittel existenzvernichtend existenzvernichtend
Der Entwicklungsaufwand ist größer als kalkuliert hoch gering existenzvernichtend existenzvernichtend

In Abbildung 1 sind die Ergebnisse grafisch dargestellt.

Risikomatrix

Abbildung 1: Risikomatrix

Die Szenarioanalyse zeigt, dass beide Alternativen für Entwickler Risiken bergen. Risikopotential bei Android liegt insbesondere bei dem komplexen Entwicklungsprozess für Apps. Hierbei müssen eine Vielzahl von Richtlinien des CDD eingehalten werden und die Kompatibilität mit einer Vielfalt an verschiedenen Endgeräten sichergestellt werden. Dies kann den Entwicklungsaufwand deutlich erhöhen. Weiterhin birgt eine Klausel im Android Market Developer Distribution Agreement das Risiko, dass Käufer entschädigt werden müssen, sollte Google von der Möglichkeit gebrauch machen ein App zu entfernen. Die Vorteile von Android zeigen sich jedoch in der großen Anpassbarkeit, da das Betriebssystem quelloffen ist. Somit lassen sich Schnittstellen hinzuprogrammieren oder erweitern. Die große Hardwarevielfalt an androidfähigen Endgeräten erhöht zwar den Entwicklungsaufwand, bringt aber den Vorteil, dass das App auf Endgeräten verschiedener Hersteller lauffähig ist.

iPhone OS hat die Schwachstelle, dass einzig Apple bestimmt welche Schnittstellen und Technologien zur Verfügung stehen. Dies birgt die Gefahr, dass in Zukunft wichtige Schnittstellen bzw. Technologien wegfallen, die für die Funktion eines Apps elementar sind. Auch ist es nicht möglich weitere Schnittstellen hinzuzuprogrammieren, da iPhone OS ein quellgeschlossenes Betriebssystem ist. Wie auch bei Android besteht bei iPhone OS das Risiko, dass das App von Apple aus dem App Store entfernt und auf allen Apple Geräten deaktiviert wird. Diese Vorgehensweise wird von Apple weit aus häufiger genutzt als von Google. Eine zusätzliche Schwachstelle von iPhone OS ist, dass es zurzeit nur auf einem einzigen Tablet PC (dem iPad) lauffähig ist. Ein Wechsel des Endgerätes ist deshalb nicht möglich. Vorteil von iPhone OS ist hingegen der geringere Entwicklungsaufwand für Apps.

7.6 Risiko-Vergleich offene und geschlossene Systeme

Das Ziel dieser Arbeit war ein Risikovergleich zwischen offenen und geschlossen Systemen. Bei der Bearbeitung dieser Fallstudie hat sich jedoch herausgestellt, dass es sich beim verglichenen System iPhone OS nicht um ein vollkommen geschlossenes System handelt. Stattdessen handelt es sich bei iPhone OS um ein halboffenes System, da es Schnittstellen für die Kommunikation mit der Umwelt bereithält. Somit ist kein Risikovergleich zwischen einem offenem und geschlossenem System durchgeführt worden sondern zwischen einem offenen und halboffenen. Generell hat sich beim Vergleich beider Systeme gezeigt, dass offene Systeme weniger Risiken bergen, da sie anpassungsfähiger sind und auf geänderte Umweltbedingungen flexibler reagieren können. Die Risiken, die bei Android höher eingestuft wurden als beim iPhone OS beruhen nicht auf der Eigenschaft von offenen Systemen sondern auf Richtlinien, die Google dem Android System aus Kompatibilitätsgründen auferlegt.

8 Schlussbetrachtung

Zusammenfassend lässt sich festhalten, dass Android für den Entwickler mehr Flexibilität und Freiheiten bei der Entwicklung von Apps bereithält als iPhone OS. Dadurch ist das Risiko, dass das App zuküntig nicht mehr lauffägig ist, geringer. Android Systeme haben dagegen den Nachteil, dass der Entwicklungsaufwand in der Regel größer ist als bei iPhone OS. Zudem müssen im Falle einer Deaktivierung des Apps Entschädigungen an die Käufer gezahlt werden.

Bei der Ergebnisbetrachtung muss jedoch bedacht werden, dass die Einordnungen der Wahrscheinlichkeiten und Schadenshöhen einer subjektiven Einschätzung unterliegen, da keine genauen verwertbaren Zahlen vorlagen.

Die Ergebnisse lassen sich jedoch nicht direkt auf offene und geschlossene Systeme übertragen. Bei Durchführung der Fallstudie wurde festgestellt, dass iPhone OS nicht als komplett geschlossenes sondern eher als halboffenes System betrachtet werden kann. Zudem basieren einige Risiken von Android nicht auf typische Eigenschaften von offenen Systemen sondern auf Richtlinien und Beschränkungen die Google dem System auferlegt. Somit konnte das Ziel der Fallstudie, einen Risikovergleich zwischen einem offenen und einem geschlossenen System durchzuführen, nicht erreicht werden. Dennoch konnte aufgezeigt werden, dass je offener ein System ist, die Risiken für Entwickler sinken.

In dieser Fallstudie wurden ausschließlich Risiken bewertet, die im Falle eines Dienstleitungsausfall bestehen. Anders als eingeplant, wurden wichtige Aspekte der Datensicherheit, beispielsweise Datenintegrität und Vertraulichkeit nicht in der Risikoanlyse behandelt. Grund hierfür war einerseits eine Unterschätzung des Zeitaufwandes der gesamten Fallstudie als auch die Unterschätzung des Umfanges der alleine durch die Betrachtung des Dienstleistungsausfalles zustande kam. Für eine fundierte Entscheidungsfindung sollte der Aspekt der Datensicherheit berücksichtigt werden. Nach der Risikoanlyse wäre der nächste Schritt, für die ermittelten Risiken Gegenmaßnahmen zu finden.

9 Fußnoten

  1. Bundeszentrale für politische Bildung
  2. vgl. Das Digitale Wörterbuch der deutschen Sprache des 20. Jahrhunderts
  3. Mock, Ralf, S. 2
  4. vgl. Bues, Manfred, S. 19
  5. Bues, Manfred, S. 22
  6. Wheeler, Tom, S. 4
  7. vgl. Bues, Manfred, S. 23
  8. vgl. Bues, Manfred, S. 27
  9. vgl. Bues, Manfred, S. 28
  10. vgl. Bues, Manfred, S. 29
  11. vgl. Bues, Manfred, S. 24f
  12. vgl. Wheeler, Tom, S. 4
  13. vgl. Bues, Manfred, S. 19
  14. vgl. Göldi, Andreas
  15. Göldi, Andreas
  16. vgl. Göldi, Andreas
  17. vgl. Bues, Manfred, S. 19
  18. vgl. Schiffner, Thomas, S. 4
  19. vgl. Schiffner, Thomas, S. 6
  20. vgl. Schiffner, Thomas, S. 5
  21. Henning, Stephan, S. 93ff
  22. vgl. Renner, Thomas; Vetter, Michael; Rex, Sascha; Kett, Holger, S. 21
  23. Apache License
  24. Renner, Thomas; Vetter, Michael; Rex, Sascha; Kett, Holger, S. 19
  25. vgl. Henning, Stephan, S. 7
  26. vgl. Henning, Stephan, S. 17f
  27. vgl. Renner, Thomas; Vetter, Michael; Rex, Sascha; Kett, Holger, S. 17
  28. vgl. ITWissen
  29. vgl. ITWissen
  30. vgl. About the Android Open Source Project
  31. vgl. Android Philosophy and Goals
  32. vgl. Android 2.2 Platform
  33. vgl. Android Compatibility
  34. vgl. Android Compatibility Program Overview
  35. vgl. Android CDD, S. 17 – 22
  36. vgl. Android Market
  37. vgl. Wikitude World Browser
  38. vgl. Android Licenses
  39. vgl. Wentz, Dr. Rolf-Christian
  40. vgl. iPhone OS Overview
  41. vgl. iPad Technische Daten
  42. vgl. Apple iPad: Details über das iPhone OS 3.2
  43. vgl. Apple iPhone OS Wikipedia
  44. vgl. iTunes
  45. vgl. Stelzer, Dirk, S. 2
  46. vgl. Prokein, Oliver, S. 7
  47. vgl. Stelzer, Dirk, S. 2
  48. Koenigs, Hans-Peter, S. 9
  49. vgl. Koenigs, Hans-Peter, S. 9
  50. vgl. Prokein, Oliver, S. 11
  51. vgl. Koenigs, Hans-Peter, S. 9
  52. vgl. Prokein, Oliver, S. 13
  53. vgl. Koenigs, Hans-Peter, S. 10
  54. vgl. Koenigs, Hans-Peter, S. 10
  55. vgl. Stelzer, Dirk, S. 2
  56. vgl. Stelzer, Dirk, S. 3f
  57. vgl. Freiling, Jens: S. 12ff
  58. BSI Grundschutzkatalog S. 56
  59. BSI Grundschutzkatalog S. 50
  60. BSI Grundschutzhandbuch S. 56
  61. vgl. BSI Grundschutzkatalog S. 49
  62. BSI Grundschutzkatalog S. 51
  63. vgl. Perez, Marin
  64. vgl. Perez, Marin
  65. vgl. Android Market Developer Distribution Agreement, Punkt 7.2
  66. vgl. Android Market Developer Distribution Agreement, Punkt 7.2
  67. vgl. Android Market Developer Distribution Agreement, Punkt 7.2
  68. vgl. Mick, Jason
  69. vgl. All4Phones
  70. vgl. Android Compatibility
  71. vgl. Google Support
  72. vgl. Apple Thoughts on Flash
  73. vgl. TabletPCs Kindle, iPad & Co
  74. vgl. Macrumors.com
  75. vgl. Google Voice on iphone
  76. vgl. Apple: Google Voice aus AppStore entfernt

10 Literatur- und Quellenverzeichnis

About the Android Open Source Project: http://source.android.com/about/index.html, 27.5.2010 14:54
All4Phones: http://www.all4phones.de/forum/android-programme-apps/24168-anleitung-android-anwendungen-installieren.html, 8.6.2010 14:09
Android 2.2 Platform: http://developer.android.com/sdk/android-2.2.html, 28.5.2010 16:36
Android CDD: http://source.android.com/compatibility/android-2.1-cdd.pdf, 12.06.2010 15:55
Android Compatibility Program Overview: http://source.android.com/compatibility/overview.html, 28.5.2010 10:13
Android Compatibility: http://source.android.com/compatibility/, 28.5.2010 10:13
Android Compatibility: http://source.android.com/compatibility/index.html, 10.6.2010 16:52
Android Licenses: http://source.android.com/source/licenses.html, 01.06.2010 14:03
Android Market Developer Distribution Agreement: http://www.android.com/us/developer-distribution-agreement.html, 9.6.2010 14:45
Android Market: http://www.android.com/market/#app=com.epocrates, 01.06.2010 13:18
Android Philosophy and Goals: http://source.android.com/about/philosophy.html, 27.5.2010 15:24
Apache License: http://www.apache.org/licenses/LICENSE-2.0, 27.05.2010 13:45
Apple iPad: Details über das iPhone OS 3.2: http://www.heimtechnik.com/apple-ipad-details-ueber-das-iphone-os-3-2-bekannt-11009, 12.06.2010 16:23
Apple iPhone OS Wikipedia: http://de.wikipedia.org/wiki/IPhone_OS, 12.06.2010 16:15
Apple Thoughts on Flash: http://www.apple.com/hotnews/thoughts-on-flash, 10.6.2010 19:38
Apple: Google Voice aus AppStore entfernt: http://www.netzwelt.de/news/80377-apple-google-voice-appstore-entfernt-update.html, 11.6.2010 16:29
BSI Grundschutzkatalog, https://www.bsi.bund.de/cae/servlet/contentblob/478418/publicationFile/54753/it-grundschutz-kataloge_2009_EL11_de.pdf, 25.05.2010 20:30
Bues, Manfred: Offene Systeme – Strategien, Konzepte und Techniken für das Informationsmanagement, Springer-Verlag Berlin 1994
Bundeszentrale für politische Bildung, http://www.bpb.de/popup/popup_lemmata.html?guid=6TTRE1, 25.05.2010 21:39
Das Digitale Wörterbuch der deutschen Sprache des 20. Jahrhunderts, http://www.dwds.de/?kompakt=1&qu=System, 25.05.2010 21:33
Freiling, Jens: Risikoanalysen und Sicherheitslücken, www.uni-koblenz.de/~steigner/seminar-net-sec/sem11.pdf, 28.05.2010 19:46
Göldi, Andreas: http://netzwertig.com/2010/02/05/markttrends-die-kommende-aera-der-halbgeschlossenen-aber-konsumentenfreundlichen-it/, 04.06.2010 13:30
Google Support: http://www.google.com/support/youtube/bin/answer.py?hl=de&answer=56115, 10.6.2010 19:34
Google Voice on iphone: http://www.google.com/support/forum/p/voice/thread?tid=74bb9d1bb9401719&hl=en, 11.6.2010 16:22
Henning, Stephan: Open Source-Software für mittelständische Unternehmen, 1. Auflage, IGEL Verlag GmbH, 2009
iPad Technische Daten: http://www.apple.com/de/ipad/specs/, 25.05.2010 16:45
iPhone OS Overview: http://developer.apple.com/iphone/library/referencelibrary/GettingStarted/URL_iPhone_OS_Overview/index.html, 01.06.2010 17:47
iTunes: http://itunes.apple.com/us/app/kindle/id302584613?mt=8, 28.5.2010 14:13
ITWissen: http://www.itwissen.info/definition/lexikon/Tafel-PC-tablet-PC.html, 01.06.2010 14:50
Koenigs, Hans-Peter: IT-Risiko-Management mit System, 2. korrigierte Auflage, Friedr. Vieweg & Sohn Verlag GWV Fachverlage GmbH, Wiesbaden, 2006
Macrumors.com: http://www.macrumors.com/2010/02/21/over-5000-overtly-sexual-apps-pulled-from-app-store-and-counting, 11.6.2010 16:02
Mick, Jason: http://www.dailytech.com/Google+Pulls+the+Plug+on+G1+Tethering+Apps/article14717.htm, 9.6.2010 18:21
Mock, Ralf: Moderne Methoden der Risikobewertung komplexer Systeme, http://www.nsl.ethz.ch/index.php/en/content/view/full/351, 30.05.2010 20:32
Perez, Marin, http://www.informationweek.com/news/internet/google./showArticle.jhtml?articleID=211200988, 06.06.2010 21:30
Prokein, Oliver: IT-Risikomanagement, 1. Auflage, Betriebswirtschaftlicher Verlag Dr. Th. Gabler GWV Fachverlage GmbH, Wiesbaden, 2008
Renner, Thomas; Vetter, Michael; Rex, Sascha; Kett, Holger: Open Source Software – Einsatzpotenziale und Wirtschaftlichkeit, Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO, 2005
Schiffner, Thomas: Open Source Software: Freie Software im deutschen Urheber- und Vertragsrecht, VVF Verlag V. Florentz GmbH, München 2002
Stelzer, Dirk: Risikoanalyse – Konzepte, Methoden und Werkzeuge, http://informationsmanagement.wirtschaft.tu-ilmenau.de/forschung/documents/, 30.05.2010 21:14
TabletPCs Kindle, iPad & Co: http://hardware.magnus.de/desktop-server/artikel/tabletpcs-kindle-ipad-co-was-bieten-die-neuen-ebooks-und-tabletpcs.2.html, 11.6.2010 14:08
Wentz, Dr. Rolf-Christian: http://die-innovationsmaschine.de/?p=92, 01.06.2010 19:16
Wheeler, Tom: Offene Systeme – Ein grundlegendes Handbuch für das praktische DV-Management, Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden 1993
Wikitude World Browser: http://www.wikitude.org/category/02_wikitude/world-browser, 01.06.2010 13:29

Schlagwörter: Fallstudie, iPad, iPhone OS, Systeme, Tablet PC

Artikelname: Fallstudie: Offene vs. geschlossene Systeme – Risikoanalyse am Beispiel Android und iPhone OS

Hast Du Fragen oder Anmerkungen zum Artikel? Schreibe einen Kommentar.

Schreibe einen Kommentar

Die Angabe der E-Mail-Adresse ist freiwillig. Die E-Mail-Adresse wird nicht veröffentlicht.