Anhang - Thomas Büsser

Mobile Anwendung zur
Kommunikation von
schulrelevanten Informationen
Abschlussarbeit Gymnasium 2012
Verfasser:
Kevin Stierli, P13
Raphael Haslebacher, NP12
Schwerpunktfach:
Physik und Anwendungen
der Mathematik
Betreuende Lehrperson:
Thomas Büsser
Lehrer für Informatik
Schulische Institution:
Kantonsschule Sargans
Datum:
3. Februar 2012

Inhaltsverzeichnis II
Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................................ II
1 Einleitung ...................................................................................................................... 1
1.1 Ziele der Arbeit ...................................................................................................... 1
1.2 Motivation .............................................................................................................. 1
1.3 Methodik ................................................................................................................ 1
2 Einführung ..................................................................................................................... 3
2.1 Begriffserklärung .................................................................................................... 3
2.1.1 Kommunikation ....................................................................................................3
2.1.1.1 Allgemeines ..........................................................................................................3
2.1.1.2 Computervermittelte Kommunikation .................................................................3
2.1.2 Android ................................................................................................................3
2.1.3 Programmiersprachen ...........................................................................................4
2.1.3.1 Java .......................................................................................................................4
2.1.3.2 C ...........................................................................................................................4
2.1.3.3 C# .........................................................................................................................5
2.1.4 Client-Server-Modell ...........................................................................................5
3 Umfrage und deren Resultate ...................................................................................... 6
3.1 Ziel und Methodik der Umfrage .............................................................................. 6
3.2 Auswertung der Umfrage ....................................................................................... 6
3.2.1 Bedürfnisabklärung ..............................................................................................6
3.2.2 Mobile Betriebssysteme .......................................................................................7
3.2.2.1 Unsere Wahl: Android .........................................................................................8
3.3 Fazit ....................................................................................................................... 9
4 Arbeiten des praktischen Teils .................................................................................. 10
4.1 Vorgehensmodelle zum Softwareentwicklungsprozess ........................................ 10
4.1.1 Analyse und Vergleich verschiedener Modelle ..................................................10
4.1.1.1 Wasserfallmodell ................................................................................................10
4.1.1.2 Spiralmodell .......................................................................................................11
4.1.1.3 V-Modell ............................................................................................................12
4.1.1.4 Extreme Programming (XP) ...............................................................................12
4.1.1.5 Scrum .................................................................................................................13
4.1.2 Unsere Wahl: Scrum ..........................................................................................14
4.1.3 Bearbeitungsablauf .............................................................................................15
4.2 Produktanforderungen und Tests ......................................................................... 15
4.2.1 Produktanforderungen ........................................................................................15
4.2.2 Use-Cases ...........................................................................................................15
4.2.3 Test-Cases ..........................................................................................................16
4.3 Probleme, und wie sie gelöst wurden ................................................................... 17
5 Architektur und Prozessschema des Gesamtsystems ............................................ 18
5.1 Funktionsweise des Systems ............................................................................... 18
5.1.1 Infrastruktureinheiten .........................................................................................18
5.1.1.1 Sekretariats-Computer ........................................................................................18

Inhaltsverzeichnis III
5.1.1.2 Server .................................................................................................................18
5.1.1.3 Mobiles Endgerät ...............................................................................................19
5.1.1.3.1 Android System Design .....................................................................................19
5.1.2 Softwareanforderungen ......................................................................................20
5.1.3 Datenübertragung ...............................................................................................21
5.1.3.1 Verbindungsauf- und -abbau ..............................................................................21
5.1.4 Sicherheit ............................................................................................................22
5.1.4.1 Risikoanalyse .....................................................................................................22
5.1.4.2 Angemessenes Sicherheitsniveau .......................................................................22
5.1.4.3 Funktionsweise ...................................................................................................23
5.2 Benutzeroberfläche .............................................................................................. 23
5.2.1 Sekretariatsanwendung .......................................................................................24
5.2.1.1 Bedienung der Anwendung ................................................................................24
5.2.1.2 Aufgaben der Sekretärin .....................................................................................26
5.2.2 Mobile Anwendung ............................................................................................26
5.2.2.1 Bedienung der Anwendung ................................................................................27
5.2.2.2 Funktionen der Anwendung ...............................................................................27
6 Zusammenfassung ..................................................................................................... 28
7 Literatur-/Quellenverzeichnis ....................................................................................... V
8 Abbildungsverzeichnis ................................................................................................ IX
Anhang ...............................................................................................................................A1
1 Umfrage-Formular .......................................................................................................A1
2 Rohdaten der Umfrage ...............................................................................................A2
2.1 Bedürfnisabklärung .............................................................................................. A2
2.2 Mobile Betriebssysteme ....................................................................................... A3
3 Codebeispiele .............................................................................................................A4
3.1 C# ........................................................................................................................ A4
3.2 Java ..................................................................................................................... A5
3.3 C .......................................................................................................................... A6

Einleitung 1
1 Einleitung
1.1 Ziele der Arbeit
Die Arbeit soll am Schluss als Produkt eine IT-Infrastruktur (bestehend aus einer mobilen Applikation,
Anwendung für das Sekretariat und Server) bereitstellen, mit der die Schüler der Kantonsschule
Sargans (KSS) schulrelevante Informationen bequem auf ihrem mobilen Endgerät abrufen können. So
soll der Schüler beispielsweise am Morgen vor der Schule eine Meldung bekommen, falls eine Stunde
im Verlaufe des Tages ausfallen wird. Es ist natürlich wünschenswert, dass dieses Projekt schlussend-
lich auch wirklich eingesetzt wird.
Zuerst wollten wir aufgrund einer Umfrage abklären, welche mobilen Betriebssysteme bei den Schü-
lern der KSS im Einsatz sind und ob unsere geplante mobile Anwendung auch Verwendung finden
würde.
Nicht zuletzt würden wir uns freuen, wenn dieses Projekt auch ein paar andere Schüler der KSS für die
Informatik begeistern würde, denn Nachwuchs in dieser Branche ist Mangelware und wird in naher
Zukunft bzw. schon heute stark gefragt sein.
1.2 Motivation
Den Grundstein dieses Projekts bildet das beiderseitige Bedürfnis zweier Schulkollegen, gemeinsam
eine Anwendung schreiben zu wollen, die nützlich ist für den Alltag. Wir haben generell ein sehr gros-
ses Interesse an Informatik, zudem stören wir uns zunehmend an der analogen Kommunikation an der
Schule. Des Weiteren haben wir sehr viele sich ergänzende Interessen, einerseits besteht ein grosses
Interesse an Smartphones allgemein, Google-Produkten wie z. B. Android, Dokumentengestaltung und
grundsätzlich allen neuen IT-Produkten, auf der anderen Seite am Programmieren, Internetkommuni-
kation, Verschlüsselungstechnik und Betriebssystemfunktionsweise. Zudem ist es für uns sehr profita-
bel, da wir durch dieses Projekt viel Neues lernen, was sich später in einem angestrebten Informatik-
Studium sicher als nützlich erweisen wird.
1.3 Methodik
Nach einer generellen Einleitung werden einige wichtige Begriffe erklärt, die durch die ganze Arbeit
begleiten. Anschliessend wird kurz auf einige Programmiersprachen eingegangen, mit denen wir den
grössten Teil unserer Anwendungssoftware programmiert haben. Diese mussten wir zum Teil zuerst
noch mithilfe von Büchern erlernen.
Im wissenschaftlichen Teil der Maturaarbeit wurde aufgrund einer Umfrage eine Bedürfnisabklärung
für den Kommunikationsdienst sowie eine Bestandsaufnahme der genutzten mobilen Plattformen er-
stellt. In diesem Teil wird auch noch genauer auf unsere Wahl von Android als mobiles Betriebssys-
tem eingegangen.

Einleitung 2
Bei der Softwareentwicklung wollten wir uns auf eines der zahlreichen vorhandenen Modelle zum
Softwareentwicklungsprozess stützen; dieses musste allerdings zuerst noch durch einen aufwendigen
Vergleich mehrerer Modelle ausgewählt werden.
Danach folgt ein umfangreicher Teil über die ganze Infrastruktur. Im ersten Teil davon geht es um die
Funktionsweise im Hintergrund der Anwendungen, im zweiten um die Funktionsweise auf der Ober-
fläche. Im erstgenannten Teil soll u. a. auch erklärt werden, wie das Betriebssystem Android funktio-
niert.
Abgeschlossen wird die Arbeit mit einer kurzen Zusammenfassung über das gesamte Projekt.

Einführung 3
2 Einführung
Durch eine Begriffserklärung am Anfang soll der Einstieg in das Thema erleichtert werden.
2.1 Begriffserklärung
Mehrere Begriffe sind in der ganzen Maturaarbeit von grosser Bedeutung, einige davon werden an
dieser Stelle erklärt.
2.1.1 Kommunikation
2.1.1.1 Allgemeines
Unter Kommunikation versteht man die Verständigung untereinander, bzw. der zwischenmenschliche
Verkehr besonders mithilfe von Sprache und Zeichen (Bibliographisches Institut GmbH, 2011). Bei
diesem Informationsaustausch braucht es immer einen Sender und einen Empfänger, das ist auch bei
unserer praktischen Arbeit nicht anders (vgl. 2.1.4). Der Begriff stammt ursprünglich vom lateinischen
Wort „communicatio“ für „Mitteilung“ (Bibliographisches Institut GmbH, 2011). Infolge der neuen
Medien gewinnt er zunehmend an Bedeutung. In dieser Arbeit ist v. a. die computervermittelte Kom-
munikation relevant.
2.1.1.2 Computervermittelte Kommunikation
Mit „Computervermittelte Kommunikation“ (cvK) ist die Kommunikation über das Internet (oder
Intranet 1 ) gemeint, also die Kommunikation mithilfe von digitalen Medien 2 . Einige ältere Formen der
cvK sind E-Mail-Nachrichten, Blogs und Foren, neuerdings setzen sich aber Chats, Internettelefonie
(VoIP 3 ) und Videokonferenzen 4 immer mehr durch. Der Grösste Vorteil der cvK ist mit Sicherheit die
Unabhängigkeit von Raum und Zeit.
2.1.2 Android
Android ist in erster Linie ein Betriebssystem, vor allem für Smartphones und Tablets 5 . Es wird von
der Open Handset Alliance 6 unter der Leitung von Google entwickelt (Google Inc., 2011) und baut auf
einem Linux-Kernel auf. 7 Das erste Smartphone mit Android als Betriebssystem wurde im Oktober
2008 veröffentlicht. Seit da an erlangte Android eine immer grösser werdende Beliebtheit, so ist And-
roid unter den mobilen Betriebssystemen in den USA mit 53 % Marktanteil die Nummer eins, gefolgt
von Apples iOS mit 29 % und RIMs Blackberrys mit 10 % (AOL Inc., 2011).
1
Internes Netzwerk von Unternehmen und Organisationen (siemax CMS Webdesign & Internetservice
Feldkirchen, 2011)
2
Z. B. Mobiltelefonen
3
Voice over IP, IP = Internet Protocol
4
Z. B. über Skype
5
Tragbarer flacher Computer mit grossem Touchscreen
6
Konsortium von 80 Firmen (Stand: 1. Januar 2012)
7
Mehr zum Android System Design auf S. 14

Einführung 4
2.1.3 Programmiersprachen
Um sich in fremden Ländern zu verständigen, muss man die jeweilige örtlich gesprochene Sprache
beherrschen. Beim Programmieren ist das nicht anders, und da sich unser Projekt in verschiedene Ge-
biete hinein erstreckt, brauchen wir auch mehr als nur eine Sprache; jede davon hat ihre eigenen Stär-
ken.
2.1.3.1 Java
Wenn es um plattformunabhängige Programmiersprachen geht, ist
Java das Mass der Dinge. Mehr als 4.5 Milliarden Geräte werden un-
terstützt (Oracle, 2011), alle Geräte, für welche eine sogenannte Java
Virtual Machine (JVM) existiert, die dann wiederum das in Java ge-
schriebene Programm ausführt. Neben der Hardwareunabhängigkeit ist
die hohe Sicherheit ein weiterer wichtiger Vorteil von der Ausführung
des Codes in einer JVM.
Im Auftrag der Firma Sun Microsystems 8 wurde Oak 9 von James Gos-
ling und seinem Team 1991 und 1992 ursprünglich zur Steuerung von
Haushaltsgeräten entwickelt (Kersken-Canbaz, 2008). 1995 wurde
Oak beerdigt, Teile davon aber unter dem heutigen Namen Java wei-
tergeführt. Den Namen und das Logo erhielt Java aufgrund der Lieb-
lings-Kaffeesorte seiner Entwickler (Infoworld, 2011). Bis heute wur-
de die objektorientierte 10 , an C/C++ angelehnte Sprache Java
(Kersken-Canbaz, 2008) ständig weiterentwickelt und ist derzeit mit
fast 18 % Marktanteilen die beliebteste Programmiersprache bei den
Programmierern (IDG Communications, 2011).
Da für Android in Java programmiert wird, findet Java in unserem Projekt bei der Android-
Applikation Verwendung (vgl. 5.2.2). Zur Veranschaulichung von Java-Code vgl. Anhang 3.2.
2.1.3.2 C
Abbildung 1: Die Kaffeetasse als
Java-Logo (Wikipedia, 2006)
C ist die zweitbeliebteste Programmiersprache hinter Java (IDG Communications, 2011). Im Gegen-
satz zu Java ist C keine objektorientierte Programmiersprache, sondern eine imperative 11 , prozedurale.
C findet vor allem Verwendung wenn es um hardwarenahe Programmierung und hohe Ausführungs-
geschwindigkeit geht (Sommergut, 1997). Nur in Assembler geschriebene Programme werden schnel-
ler ausgeführt, diese sind allerdings prozessorabhängig, somit also nicht portabel. Die Grammatik und
Semantik von Assembler ist auch um einiges komplizierter als jene von C und somit noch fehleranfäl-
8 Wurde Ende Januar 2010 von Oracle aufgekauft
9 Object Application Kernel, engl. für „Eiche“ (in Anlehnung an die Eiche, die vor Goslings Fenster stand)
10 auf der Idee, Verwendung von Objekten beruhend (Bibliographisches Institut GmbH, 2011)
11 befehlend, zwingend, bindend (Bibliographisches Institut GmbH, 2011)

Einführung 5
liger. Aus diesen Gründen werden Betriebssysteme, Compiler und auch Gerätetreiber meist in C pro-
grammiert, so z. B. Linux oder auch Windows, grösstenteils.
Erfunden wurde die im Jahre 1972 veröffentlichte Sprache C von Dennis Ritchie und Brian Kernig-
han, sie ist eine Weiterentwicklung von BCPL und B. C wurde für die Entwicklung des Betriebssys-
tems UNIX verwendet (Sommergut, 1997), dessen Erfolg wiederum C zum Durchbruch verhalf.
In unserem Fall findet C aufgrund seiner Geschwindigkeit Einsatz beim Server (vgl. 5.1.1.2). Ge-
schriebener Code dieser Programmiersprache befindet sich in Anhang 3.3.
2.1.3.3 C#
C# (see sharp) wurde von Microsoft entwickelt und im Jahre 2001 veröffentlicht. Es wird standard-
mässig mit Microsofts Visual Studio 12 ausgeliefert. In Kombination mit dem .NET Framework 13 wer-
den mit C# vor allem Windows-Anwendungen, Webdienste und z. B. Steuerelemente erstellt
(Microsoft, 2011).
C# ist eigentlich eine Weiterentwicklung von C++, so kam es auch zu seinem Namen 14 . Durch die
Erhöhung um eine Stufe (++ in Programmiersprachen) von C++ entsteht ein vierfaches Plus, das als
Doppelkreuz dargestellt wurde. C# weist enorme Ähnlichkeiten mit Java auf, so besitzt C# als Pendant
zur JVM eine .NET Framework Common Language Runtime (Hinzberg).
Zur Anwendung kommt bei uns C# beim Windows-Programm für das Sekretariat (vgl. 5.2.1). In An-
hang 3.1 ist C#-Code zu sehen.
2.1.4 Client-Server-Modell
Ein Client-Server-System 15 besteht dem Namen entsprechend aus Server und Clienten, die durch ein
Netzwerk verbunden sind. Der Server, der Dienste für die Clienten bereitstellt, wartet passiv auf eine
Anforderung von einem Clienten. Kommuniziert wird dabei zwischen dem Client-Programm und dem
Server-Programm. Das Client-Programm sendet dem Server-Programm Befehle, die vom Server-
Programm ausgeführt werden, wodurch danach dem Client-Programm die angeforderten Daten über-
mittelt werden (Dehmer, 2003).
Im Gegensatz zum Peer-to-Peer-Modell 16 werden beim Client-Server-Modell die Ressourcen zentral
auf dem Server gespeichert. Die Verwaltung der Ressourcen findet somit auf Ebene des Servers statt
und gestaltet sich dadurch relativ einfach, die Clienten müssen dabei also nicht speziell beachtet wer-
den (Kioskea, 2009).
12 Vgl. http://www.microsoft.com/germany/express/
13 eine Klassenbibliothek für Microsoft Windows
14 Ausführliche Geschichte vgl. http://www.cul.de/data/csharppr2.pdf
15 Auf Deutsch: Kunden-Diener-System
16 Netzwerk ohne zentralen Server, alle Systeme sind Server und Client zugleich

Umfrage und deren Resultate 6
3 Umfrage und deren Resultate
3.1 Ziel und Methodik der Umfrage
Mithilfe einer schulinternen Umfrage (siehe Anhang 1) an der Kantonsschule Sargans wollten wir
einerseits herausfinden, wie gross die Nachfrage für eine App ist, die z. B. über Stundenausfälle in-
formiert, und andererseits wollten wir in Erfahrung bringen, wie es mit den Marktanteilen der mobilen
Betriebssysteme bei uns an der Schule steht.
Die Umfrage wurde persönlich an die Klassenchefin/den Klassenchef geschrieben, die/der dann die
Umfrage für die ganze Klasse ausfüllen sollte, nach Rücksprache mit den einzelnen Schülern. Wir
erhofften uns dadurch eine grössere Teilnehmeranzahl. Die Gefahr, dass das Umfrageblatt umgehend
ohne Beachtung entsorgt wird ist unserer Ansicht nach kleiner, wenn eine Person die Verantwortung
für die ganze Klasse trägt, als wenn jede Schülerin/jeder Schüler selbst ein Blatt bekommt. Ferner
konnten wir dank dieser Taktik zudem eine sinnlose Papierverschwendung vermeiden. Damit wir auch
für den zweiten Teil der Umfrage mit einer hohen Teilnehmeranzahl rechnen konnten, baten wir die
Klassenchefin/den Klassenchef, diesen Teil von einer Person der Klasse ausfüllen zu lassen, die sich
besonders gut mit Handys auskennt.
3.2 Auswertung der Umfrage
3.2.1 Bedürfnisabklärung
Bei der Bedürfnisabklärung handelte es sich - wie schon gesagt - um die Frage, ob die befragten Per-
sonen eine App, wie sie von uns geplant war, herunterladen und installieren würden, falls sie für ihr
jeweiliges Handy verfügbar wäre. Als Antwort standen „Ja“, „Nein“, „Vielleicht“ oder „kein Handy“
zur Auswahl.
Von den ca. 710 Schüler/innen der Kantonsschule (Kantonsschule Sargans, 2011), die maximal an der
Umfrage hätten teilnehmen können, wirkten ansehnliche 490 mit, was einer Beteiligung von knapp
mehr als zwei Dritteln (69 %) entspricht. 12 Personen gaben an, kein Handy zu besitzen. Dieser Anteil
von gut 2 % stimmt erfreulich exakt mit dem Ergebnis der sogenannten JAMES 17 -Studie überein, bei
der 2010 über 1000 Jugendliche von der ZHAW 18 befragt wurden (Willemse Isabel, 2010).
„Vielleicht“ haben 11 % der Befragten als Antwort angegeben, „Nein“ 8 % und erstaunliche 78 %
gaben an, die App herunterladen und installieren zu wollen. Ob sie das auch wirklich tun würden ist
wiederum eine andere Frage. Aber grundsätzlich kann man sicherlich sagen, dass ein grosses Interesse
vorhanden ist.
17 Jugend, Aktivitäten, Medien – Erhebung Schweiz
18 Zürcher Hochschule für Angewandte Wissenschaften

Umfrage und deren Resultate 7
Kein Handy
Vielleicht
Abbildung 2: Diagramm zum Marktpotenzial einer Kommunikations-App an der KSS
3.2.2 Mobile Betriebssysteme
Beim zweiten Teil der Umfrage wollten wir vor allem herausfinden, wie gross der Marktanteil von
Android bei uns an der Schule ist, denn eine App für ein Betriebssystem, das niemand nutzt, wäre
nicht sinnvoll. Aus diesem Grund mussten die befragten Personen angeben, welches Betriebssystem
auf ihrem Handy installiert ist. Zur Auswahl gaben wir „Android“ von Google, „iOS“ von Apple,
„Windows Phone 7“ von Microsoft, „Symbian“ von Nokia und „Sonstiges“ vor, zu dem wir alle ande-
ren mobilen Betriebssystem und sämtliche individuellen Eigenproduktionen von den Handyherstellern
zählen.
Nein
Ja
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
Logischerweise konnten alle Schüler, die nicht im Besitze eines Handys sind, sich bei diesem Teil
nicht beteiligen. Somit ergab sich eine Teilnehmeranzahl von 478 Personen. Der grösste Anteil geht an
die Kategorie „Sonstiges“. Dies ist nicht weiter erstaunlich, da zu dieser Kategorie beispielsweise alle
alten, beliebten Handys von Sony Ericsson und alle Blackberrys dazugezählt werden. Des Weiteren
haben wir zu dieser Kategorie auch alle Antwortenden dazugerechnet, die nicht wussten, welches Be-
triebssystem auf ihrem Handy installiert ist. Diese Kategorie ist allerdings auch nicht von allzu grosser
Bedeutung, da sich für diese Handys keine App mit solchen Funktionen, wie wir sie verwenden woll-
ten, programmieren lässt. Symbian, das vor ein paar Jahren bei den Smartphones noch dominierend
war, kommt noch auf einen bescheidenen Anteil von knapp 7 %. Noch weniger Marktanteile verbuch-
te Windows Phone 7, immerhin steht es im Gegensatz zu Symbian nicht auf dem absteigenden Ast.
Mit gut 1 % Anteil konnte sich Microsofts neues mobiles Betriebssystem allerdings auch bei uns in
der Schule noch überhaupt nicht behaupten.
Marktpotenzial
142 Teilnehmer nutzt iOS, dies entspricht einem beträchtlichen Anteil von 30%, es besitzt also fast
jeder dritte Schüler ein iPhone! Mit bemerkenswerten 26% (126 Geräte) liegt Android erstaunlich

Umfrage und deren Resultate 8
knapp hinter iOS. Dieses Resultat ist für uns doch ziemlich erstaunlich, da Android noch ein relativ
junges Betriebssystem ist und wir iOS dominierender erwartet hätten. Zudem ist das iPhone in der
Schweiz traditionell sehr beliebt. So lief im Jahre 2010 in der Schweiz auf jedem zweiten Smartphone
(52%) iOS, mit knapp 23% lag Android deutlich auf dem zweiten Rang (20 Minuten AG, 2012).
Windows Phone 7
Marktverteilung der mobilen Betriebssysteme
Sonstiges
Symbian
iOS
Android
Abbildung 3: Diagramm zur Marktverteilung der mobilen Betriebssysteme an der KSS
3.2.2.1 Unsere Wahl: Android
Wenn man für iOS entwickeln will stösst man als Windows-, bzw. Linux-User, wie wir es sind,
schnell auf die erste Hürde. Man benötigt dazu einen Mac mit Intel-Prozessor, auf dem OS X Snow
Leopard oder neuer läuft (Apple Inc., 2011). Zusätzlich fallen noch Kosten von 99$/Jahr an (Apple
Inc., 2011), damit man Member beim iOS Developer Program ist. Ohne diese Mitgliedschaft kann
man keine Apps im App-Store veröffentlichen. Auch um für Android zu entwickeln kommt man nicht
kostenlos davon, allerdings gibt es hier nur eine einmalige Registrierungsgebühr in Höhe von 25$
(Google, 2011). Apple überprüft im Gegensatz zu Google alle eingereichten Apps, bevor sie im App-
Store veröffentlicht werden. Das ist natürlich mit einer gewissen Wartezeit verbunden und somit für
uns auch nicht optimal.
Der für uns entscheidende Grund ist die Tatsache, dass wir beide weder ein iPhone noch ein iPad be-
sitzen, sondern beide ein Android-Smartphone. Theoretisch wäre es schon möglich eine App für ein
iPhone zu entwickeln, ohne eines zu besitzen, aber es ist nicht gerade empfehlenswert. Für uns wäre es
also eine kostspielige Angelegenheit geworden, für iOS zu entwickeln. Abgesehen davon liegt uns die
Philosophie von Google besser als jene von Apple. Android ist ein offenes Betriebssystem, kommt auf
einer Vielfalt von Geräten mehrerer Hersteller zum Einsatz, und man ist nicht wie bei iOS von iTunes,
iPhone etc. abhängig.
0% 5% 10% 15% 20% 25% 30% 35% 40%

Umfrage und deren Resultate 9
Der wichtigste Punkt, den es bei unserer Entscheidung zu beachten gab, sprach allerdings gegen And-
roid: die Anzahl der Benutzer. Es muss ja ein Ziel sein, dass unser Endprodukt von möglichst vielen
Schülern verwendet werden kann. Es wäre also aufgrund der Umfrage naheliegender, eine App für
iOS zu schreiben. Aber nicht zuletzt deswegen sind wir hocherfreut über das Resultat der Umfrage,
die zeigt, dass Android nur knapp dahinter am Zweitmeisten angewendet wird. Unsere Angst, eine
App nur für ein paar wenige Schüler zu entwickeln, hat sich glücklicherweise nicht bestätigt. Und
auch die Tatsache, dass Android im Aufschwung ist, stimmt uns positiv. Es wäre nicht erstaunlich,
wenn in einem Jahr mehr Schüler der Kantonsschule Android als iOS nutzen würden. (Vgl. z. B. Arti-
kel: Android überholt Apple iOS in Deutschland (SPIEGELnet GmbH, 2011))
3.3 Fazit
Die Umfrage werten wir als vollen Erfolg, da zum einen eine überwältigende Mehrheit von 78 % der
Kantonsschüler Interesse an unserer App gezeigt hat und da zum anderen unsere Wahl Android nicht
widerlegt wurde. Gestützt auf diese Umfrage könnten wir ohne schlechtes Gewissen das Sekretariat
der KSS bitten, unsere Infrastruktur zumindest für eine gewisse Testphase einzusetzen. Voraussicht-
lich wird es die mobile Applikation allerdings nur für Android geben, eine Version für iOS wird even-
tuell zu einem späteren Zeitpunkt noch folgen, abhängig davon ob die Android-App schlussendlich
wirklich Anklang findet.

Arbeiten des praktischen Teils 10
4 Arbeiten des praktischen Teils
4.1 Vorgehensmodelle zum Softwareentwicklungsprozess
Softwareentwicklungsprojekte werden oft rasch sehr komplex. Damit man nicht den Faden verliert, ist
es ratsam, eines der zahlreichen, möglichen Vorgehensmodelle anzuwenden. Sie umfassen je nach
Modell den ganzen Prozess von der Analyse der Anforderungen für eine Anwendung bis hin zur War-
tung des Endprodukts (Informatik Forum Simon GmbH, 2011).
4.1.1 Analyse und Vergleich verschiedener Modelle
Hier folgend werden einige bekannte Vorgehensmodelle etwas genauer erklärt.
4.1.1.1 Wasserfallmodell
Anforderungen
Schritt
Phase
Einstufige Iteration
Analyse
Entwurf
Programmierung
Implementierung
Test
Abbildung 4: Die einzelnen Schritte des Wasserfallmodells, gemäss (TEIA AG, 2009)
Inbetriebnahme
Wartung
Wie ein Wasserfall geradlinig nach unten fällt geht man bei diesem Modell Schritt für Schritt in Rich-
tung Ziel. Man fängt beim ersten Schritt an, schliesst ihn vollständig ab und geht zum nächsten. Ein-
stufige Iterationen 19 sind grundsätzlich möglich, aber häufig nicht erwünscht. In der Geschäftswelt ist
dieses Modell nicht stark verbreitet, da auf Kundenwünsche im Nachhinein nicht mehr reagiert werden
kann (Baur, 2011). Allerdings liefert es im Grunde genommen eine gute Basis, weshalb viele andere
Modelle vom Wasserfallmodell her abgewandelt und weiterentwickelt worden sind (Software Quality
Lab, 2003, S. 4).
19 Lat. iteratio = Wiederholung

Arbeiten des praktischen Teils 11
4.1.1.2 Spiralmodell
Abbildung 5: Das Spiralmodell von Barry W. Boehm (Wikipedia, 2004)
Das Spiralmodell ist ein Beispiel einer Weiterentwicklung des Wasserfallmodells. Im Gegensatz dazu
aber ist es iterativ, da die einzelnen Schritte mehrmals durchlaufen werden. Das Softwareprodukt
wächst spiralförmig, wobei die Entwicklung in vier Quadranten 20 unterteilt ist. Ein vollständiger Um-
lauf ergibt dabei den nächsten Prototyp (Baur, 2011), nach dem letzten Durchlauf ist das Produkt fer-
tig.
Im Gegensatz zu vielen anderen Modellen besitzt das Spiralmodell eine umfassende Risikoanalyse,
wodurch das Flop-Risiko beträchtlich abnimmt. Dadurch wird es aber auch zeitintensiv und kostspie-
lig.
20 Je ein 90°-Sektor

Arbeiten des praktischen Teils 12
4.1.1.3 V-Modell
Anforderungsdefinitionen
Grobentwurf
Feinentwurf
Modulimplementation
Modultest
Abbildung 6: Schichten des (vereinfachten) V-Modells, gemäss (Bürger, 2003)
Integrationstest
Systemtest
Abnahmetest
Für die deutschen Bundesbehörden ist das V-Modell 21 der Entwicklungsstandard. Es bekam seinen
Namen durch die schematische Darstellung, bei dem es für jede Phase auf dem Weg zur Modulimple-
mentation auch entsprechend eine Phase auf dem Weg zur Abnahme gibt (Golesny, 2006, S. 40). Die-
ses Modell ist je nach Ausführung sehr umfangreich und berücksichtigt abgesehen vom eigentlichen
Entwicklungsprozess auch weitere Bereiche wie Projektmanagement und Qualitätsmanagement
(Software Quality Lab, 2003, S. 4). Im Jahre 2005 wurde dieses Modell überarbeitet und durch das V-
Modell XT 22 ersetzt. So lässt sich dieses Modell nun durch Tailoring 23 an die eigenen Bedürfnisse und
an die Umstände anpassen. Somit ist es für Grossprojekte, aber auch für kleine, gut anwendbar.
4.1.1.4 Extreme Programming (XP)
Geschichten
(Anforderungen)
Architekturtreffen
Funktionstests
Fehler
Metapher Versions- Versionsplan akt. Version
plan
Iteration
Akzeptanz- vollständige
tests
Release
Version
geänderte
Anforderungen
Abbildung 7: Ablauf eines XP-Projekts (FHS St. Gallen, 2011)
21 Das V-Modell baut ebenfalls auf dem Wasserfallmodell auf.
22 V-Modell Extreme Tailoring, engl. to tailor = schneidern
23 wegschneiden bzw. anpassen von Teilen des V-Modells
Nächste Iteration

Arbeiten des praktischen Teils 13
Bei XP, der bekanntesten Methode der agilen 24 Entwicklungsprozesse, geht es vor allem um die Er-
stellung des Quellcodes und den kürzesten Weg dorthin (FHS St. Gallen, 2011), es wird also zu Be-
ginn der Entwicklung auf einen umfassenden Anforderungskatalog verzichtet (Golesny, 2006, S. 45).
Alle denkbaren Phasen der Softwareentwicklung laufen in kurzen Schritten nacheinander, also fast
parallel ab, das hat den Vorteil, dass man sehr schnell auf neue Kundenwünsche eingehen kann. Für
XP eignen sich nur kleine Teams, häufig wird auch zu zweit programmiert, wodurch die Fehlerrate
massiv abnimmt und komplexe Sachverhalte sich in kürzester Zeit lösen lassen. Nachteilig bei dieser
Methode sind, dass ständig ein Kunde vor Ort sein sollte und dass Festpreisprojekte und fixe Fertig-
stellungstermine kaum möglich sind (FHS St. Gallen, 2011).
4.1.1.5 Scrum
Abbildung 8: Grafische Darstellung von Scrum (it-agile, 2008)
Scrum 25 ist mittlerweile ebenfalls eine der bekanntesten agilen Entwicklungsmethoden. Es folgt den
Prinzipien Transparenz, Überprüfung und Anpassung, d. h., dass immer alle Beteiligten über den aktu-
ellen Entwicklungsstand informiert sind, dass verschiedene Aspekte des Prozesses immer wieder auf
inakzeptable Abweichungen inspiziert werden und dass, falls solche vorhanden sind, der Entwick-
lungsprozess schnell angepasst wird.
24 agil = von großer Beweglichkeit zeugend (Bibliographisches Institut GmbH, 2012)
25 Der Begriff stammt vom Rugby-Sport und bezeichnet das sogenannte „Angeordnete Gedränge“.

Arbeiten des praktischen Teils 14
In Scrum gibt es drei Rollen für am Prozess beteiligte Personen: den ScrumMaster, den Product-
Owner und das (Entwicklungs-) Team. Der ScrumMaster beseitigt Hindernisse und schaut dafür, dass
Scrum möglichst gut angewendet wird. Der Product-Owner erstellt die Anforderungen an das System
und priorisiert sie (Kriegisch, 2010). Das Team entwickelt das eigentliche Produkt.
Die vom Product-Owner erstellte Liste mit allen Anforderungen an das Produkt nennt sich Product
Backlog. Es ist veränderlich, es wird also ständig durch neue bzw. veränderte Anforderungen aktuali-
siert. Aus dem Product Backlog werden in regelmässigen Abständen (z. B. vier Wochen) mehrere
Aufgaben herausgenommen und zu einer neuen Liste, dem Sprint Backlog, zusammengefügt. Dieses
Sprint Backlog wird danach vom Team in einem sogenannten Sprint (z. B. vier Wochen) ungestört
abgearbeitet. Nach jedem Sprint ist ein Teil des Produkts fertiggestellt, es wäre also potenziell auslie-
ferbar. Zu Beginn von jedem Arbeitstag findet ein Daily Scrum statt, das dem Informationsaustausch
zwischen den Team-Mitgliedern dient.
Scrum basiert also v. a. durch seine Sprints auf einem iterativen, inkrementellen 26 Ansatz.
Für mehr Informationen über Scrum bzw. über weitere Elemente von Scrum verweisen wir an dieser
Stelle auf den offiziellen Scrum-Guide: http://www.scrum.org/scrumguides/ (Schwaber & Sutherland,
2011).
4.1.2 Unsere Wahl: Scrum
Scrum haben wir gewählt, weil es unseren Vorstellungen mit seinen Sprints relativ gut entsprach, es
uns mehrfach empfohlen wurde und wir ein Entwicklungsmodell anwenden wollten, das in der Reali-
tät auch häufig eingesetzt wird. Es könnte also durchaus sein, dass zumindest einer von uns dieses
Modell später allenfalls in professionellem Umfeld einsetzen wird. Als weiterer Punkt zur Wahl von
Scrum hat die Aussage beigetragen, Scrum sei verhältnismässig einfach zu lernen und lasse sich
schnell einsetzten (it-agile, 2008), was wir nun allerdings nur teilweise bestätigen können.
Da wir lediglich ein Zweier-Team sind und der ScrumMaster nicht gleichzeitig auch den Product-
Owner verkörpern darf, waren die Rollen in unserem Fall schnell verteilt. Da unser Projekt nicht von
riesiger Komplexität ist, ist es auch kein Problem, dass sowohl der ScrumMaster als auch der Product-
Owner selbst Entwickler sind. Wir mussten das Prozessschema anbelangend einige Anpassungen vor-
nehmen, so z. B. aufgrund der geringen Produktgrösse die Dauer eines Sprints etwas herabsetzen. Wir
haben allgemein aufgrund der Grösse der Arbeit alles etwas verkleinert und gekürzt.
Im Nachhinein ist an dieser Stelle zu ergänzen, dass wir uns sehr schwer taten mit dieser Methode. Die
ersten Wochen klappte das Ganze noch recht gut, mit der Zeit ging jedoch Element um Element verlo-
ren. Nur das Daily-Scrum konnte sich bis zum Schluss durchsetzen. Unser effektiv angewendetes Mo-
dell entwickelte sich selbstständig immer mehr in Richtung von XP, sodass wir das nächste Mal an-
statt auf Scrum auf XP setzen würden.
26 inkrementell = schrittweise erfolgend, aufeinander aufbauend (Bibliographisches Institut GmbH, 2012)

Arbeiten des praktischen Teils 15
Unserer Meinung nach ist Scrum für ein solch kleines Projekt wie das unsrige etwas zu komplex und
verkompliziert die Sache mehr als dass es ihr nützt. Wir können uns gut vorstellen, dass es ein sehr
gutes Entwicklungsmodell ist für eine Gruppe von etwa zehn Personen, aber für ein Zweierteam
scheint es nicht geeignet zu sein.
4.1.3 Bearbeitungsablauf
Nach der Wahl eines Software-Entwicklungsmodells ging es an das eigentliche Werk, das Program-
mieren der Anwendungen und das Erklären im schriftlichen Teil. Diese Arbeiten waren sehr umfas-
send und zogen sich über mehrere Monate hin. Speziell das Programmieren war sehr zeitraubend; man
sieht sich, v. a. als nicht professionelle Entwickler, laufend mit irgendwelchen Problemen konfrontiert.
Kaum einer wird die Anzahl Stunden erahnen, die unser Endprodukt verschlungen hat.
Damit wir möglichst viel von der Arbeit profitieren konnten, wollten wir zuerst beide sowohl pro-
grammieren als auch beschreiben. Aufgrund der unterschiedlichen Ausgangslage und Kenntnisse kam
es allerdings relativ rasch zu einer Aufteilung der beiden Bereiche. Durch intensiven Austausch über
den Werdegang, den Stand der Arbeiten sowie über Probleme und deren Lösungen konnten wir den-
noch parallel vorwärtsarbeiten. Die Qualität der Arbeit hat dadurch sicher profitiert.
4.2 Produktanforderungen und Tests
Damit man bei der Software-Entwicklung nicht vom Weg abkommt, sollte man sein Ziel immer vor
Augen haben, sprich: man sollte am Anfang die Produktanforderungen festlegen, damit immer klar ist,
was erreicht werden will. Zudem ist es auf dem Weg zum Endprodukt wichtig, kontinuierlich Tests
durchzuführen, damit gravierende Fehler rasch aufgedeckt werden können. Vor Veröffentlichung des
Produkts wird es eingehend ausgetestet, damit selbst kleine Schönheitsfehler vermieden werden kön-
nen.
4.2.1 Produktanforderungen
Unsere eigenen Anforderungen an das Produkt sind, dass es den einzelnen Schüler mindestens über
Stundenausfälle informieren kann. Die App soll den Benutzer selbständig über einen Ausfall informie-
ren, damit der Endnutzer nicht jeden Morgen selbst nachschauen muss. Zudem sollte die App den
Schüler auch nur relevante Informationen liefern, d. h. nur für diejenigen Lehrer eine Benachrichti-
gung ausgeben, bei denen er auch wirklich Schule hätte. Zudem legen wir grossen Wert auf die Si-
cherheit, so müssen z. B. Passwörter unabdingbar verschlüsselt übertragen werden. Die Benutzerober-
fläche der App sollte so einfach wie möglich aufgebaut sein, damit sie auch jeder versteht. Für erfah-
renere Benutzer sollte es zusätzlich eine Möglichkeit geben, einige Parameter wie z. B. die Aktualisie-
rungshäufigkeit selber zu verändern.
4.2.2 Use-Cases
Aus den Produktanforderungen können die Anwendungsfälle direkt abgeleitet werden. In unserem Fall
sind sie sehr kurz gefasst, es handelt sich somit vielmehr um sogenannte User-Stories.

Arbeiten des praktischen Teils 16
Unsere drei wichtigsten User-Stories:
Absenz erstellen
Benachrichtigung
Sicherheit
4.2.3 Test-Cases
Die Sekretärin erstellt mittels Windows-Programm eine Absenz, damit die Basis
zur digitalen Benachrichtigung gelegt ist.
Die Android-App gibt eine Benachrichtigung aus, sobald für den Schüler eine
relevante Information vorliegt, damit er frühzeitig informiert ist.
Das ganze System muss sicher sein, damit keine persönlichen Daten verloren
gehen können und damit keine Rückgriffe auf das EDV-System der KSS mög-
lich sind.
Testen ist im Grunde genommen eine sehr mühselige Angelegenheit, denn fertig ist man damit eigent-
lich nie. Es kann durchaus auch vorkommen, dass man dabei Fehler findet, die man gar nicht gesucht
hat. Ab einer gewissen Komplexität der Anwendung wird es praktisch unmöglich, alle Fehler zu fin-
den. So wird davon ausgegangen, dass durchschnittlich etwa 3 Fehler pro 1000 Zeilen geschriebenem
Softwarecode existieren (Ezunov & Grundmeier, 2011).
Aufgrund unserer sehr abstrakt abgefassten Use-Cases ergeben sich aus einem einzelnen Anwen-
dungsfall sehr viele kurze Test-Cases. Sie werden zudem unterteilt in Positiv- und Negativ-Testfälle.
Es wird also einerseits untersucht, ob die Anforderungen erfüllt sind, andererseits werden durch be-
wusst falsche Benutzereingaben Fehler erzwungen. Ziel dabei ist es, dass das Programm am Schluss
auf jede noch so falsche Eingabe des Benutzers stabil reagiert, z. B. in Form einer hilfreichen Fehler-
meldung.
Einige Beispiele für Testfälle zum Anwendungsfall „Absenz erstellen“:
Schritt: Erwartetes Ergebnis:
Sekretärin klickt auf den Button „Absenz hin-
zufügen“
Sekretärin wählt in den Dropdown-Feldern
„Von“ bzw. „Bis“ „Lektion 1“ bzw. „Lektion
8“ aus (jeweils gleiches Datum)
Sekretärin wählt in den Dropdown-Feldern
„Von“ bzw. „Bis“ „Lektion 8“ bzw. „Lektion
1“ aus (jeweils gleiches Datum)
Dialogfenster „Absenz erstellen…“ öffnet sich
Die Absenz wird erfolgreich mit der Absenz-
Gültigkeit von Lektion 1 bis Lektion 8 gespei-
chert
Auswahl von „Lektion 1“ ist nicht möglich (auf-
grund des gleichen Datums und „Lektion 1“
„Lektion 8“)

Arbeiten des praktischen Teils 17
Nach der Durchführung eines Testfalls erfolgt die Testauswertung; wenn das erwartete Ergebnis ein-
trifft, ist er somit erledigt, wenn nicht, bleibt er offen. Der Test muss nach der notwendigen Bearbei-
tung des Codes erneut ausgeführt werden.
4.3 Probleme, und wie sie gelöst wurden
Während des Programmierens stösst man ab und zu auf ein Problem, das sich in den nächsten Stunden
nicht lösen lassen wird. Einige uns widerfahrene Probleme dieser Art werden hier beispielhaft etwas
genauer erläutert.
Eines der ersten Probleme stellte die Kommunikation über das Internet dar. Wie kann mit einem ande-
ren Computer via Internet kommuniziert werden, bzw. wie kann eine Verbindung von Smartphone zu
Server aufgebaut werden? Gelöst wurde dies mittels KSSP/TCP/IP 27 (vgl. 5.1.3).
Durch die Lösung dieser Frage entstand bereits ein zweites Problem, und zwar folgendes: Die Daten
werden primitiv übertragen, und theoretisch könnte somit jedermann diese abfangen und manipulie-
ren. Dies wollten wir natürlich nicht zulassen. Deshalb verwenden wir Verschlüsselungen und andere
Schutzmassnahmen.
Während der Bewältigung des zweiten Problems sahen wir uns im Rahmen der Absicherung der Da-
tenübertragung bereits mit einem weiteren konfrontiert. Ein Prozessor kann „nur“ mit Zahlen bis zu
einer durch ihn begrenzten Grösse direkt rechnen (z. B. mit Zahlen im Bereich von 0 bis für
vorzeichenlose Zahlen oder von bis für vorzeichenbehaftete Zahlen). Um jedoch ext-
rem grosse Zahlen (z. B. Zahlen im Bereich von 0 bis ) zu berechnen, braucht es mathemati-
sche Funktionen aus dem Gebiet der Algorithmischen Zahlentheorie 28 . Wir bedienten uns Funktions-
Bibliotheken, da das Thema zu komplex ist und den Umfang der praktischen Arbeit sprengen würde.
Wie man sieht, hört das nie auf. Ein Problem entsteht durch das andere.
27 KSSP steht für das von uns genutzte, eigene Protokoll
28 U. a. Primzahltests, Logarithmusberechnungen und Faktorisierungs-Algorithmen, vgl.
http://www.kuertz.name/files/Zahlentheorie.pdf

Architektur und Prozessschema des Gesamtsystems 18
5 Architektur und Prozessschema des Gesamtsystems
5.1 Funktionsweise des Systems
Der grösste Teil der Zeit, die die Erstellung eines Programms verschlingt, wird in den Programm-Code
gesteckt. Beim fertigen Produkt sieht man allerdings nur die Benutzeroberfläche und nicht, was sich
im Hintergrund alles abspielt. Um diesen Sachverhalt zu erklären wurde dieser Berichts-Teil erstellt.
5.1.1 Infrastruktureinheiten
Für unser Projekt braucht es nicht nur das Android-Handy und die Android-Anwendung, sondern auch
einen PC mit einer Windows-Anwendung für das Sekretariat und einen Server mit darauf ausgeführ-
tem Programm.
mobile
Endgeräte
Z. B. UMTS
Wireless
Haus eines Schülers
Internet
Abbildung 9: Infrastruktureinheiten: Sekretariats-PC, Server und zwei mobile Endgeräte
5.1.1.1 Sekretariats-Computer
KSS
Server
Sekretariats-PC
Wenn ein Lehrer z. B. krank ist ruft er aufs Sekretariat an und gibt der Sekretärin Bescheid. Sie füllt
anschliessend von Hand ein Absenzen-Formular aus und bringt es am Anschlagbrett an. Für unsere
digitale Lösung füllt die Sekretärin ebenfalls ein Absenzen-Formular aus, allerding eines in digitaler
Form. Dazu muss unser erstelltes Sekretariats-Programm auf ihrem PC installiert sein. Nachdem die
Sekretärin das für Absenzen vorgesehene Formular ausgefüllt und gespeichert hat, wird vom Pro-
gramm eine Verbindung zum Server aufgebaut (vgl. 5.1.3.1), die Absenz über die Verbindung über-
mittelt und auf dem Server gespeichert. Die Sekretärin greift also via den Sekretariatscomputer auf
den Server zu, um eine neue Datei darauf zu speichern, die gespeicherten Daten zu verändert oder zu
löschen, dies z. B. wenn die Absenz wieder gelöscht werden muss.
5.1.1.2 Server
Der Server bzw. das darauf installierte Programm ist dafür verantwortlich, dass die vom Sekretariats-
Programm erhaltenen Befehle und Daten ausgeführt bzw. richtig gespeichert werden. Des Weiteren
muss der Server auch Anfragen von Seiten des Android-Handys bearbeiten und die angeforderten

Architektur und Prozessschema des Gesamtsystems 19
Daten zur Verfügung zu stellen. Der Server wartet also passiv, dem Client-Server-Modell (vgl. 2.1.4)
entsprechend, auf Anfragen und Befehle.
5.1.1.3 Mobiles Endgerät
Das Android-Handy kontaktiert (aktiv) in einem bestimmten Intervall 29 den Server. Falls neue Infor-
mationen auf dem Server vorliegen, die für den Schüler des nachfragenden Handys von Bedeutung
sind, wird der Schüler durch eine Benachrichtigung darauf aufmerksam gemacht.
5.1.1.3.1 Android System Design
Eine wichtige Rolle bei der App-Programmierung spielt natürlich das auf dem Handy installierte Be-
triebssystem. Da dies in unserem Fall Android ist, wird an dieser Stelle die technische Basis von And-
roid etwas genauer betrachtet.
Android ist ein Linux-Betriebssystem 30 . Da es ein Smartphone-Betriebssystem ist, wurden typische
Desktoperweiterungen weggelassen und es wurde v. a. für Telefonie-Funktionen optimiert, allerdings
auch für das Zusammenspiel mit diversen Sensoren. Bedient wird ein Android-Smartphone über einen
Touchscreen und die Tasten "Home", "Menü" und "Zurück".
Abbildung 10: Architektur von Android (Google, 2011)
29 In unserem Fall standardmässig alle fünf Minuten
30 Linux-Kernel 2.6x

Architektur und Prozessschema des Gesamtsystems 20
Die Architektur von Android besteht aus vier Schichten: die Apps, das Application Framework, die
Bibliotheken neben der Android Runtime und der Linux-Kernel.
Zur obersten Schicht gehört all das, was der Benutzer sieht, so z. B. ein Mailprogramm oder den
Webbrowser.
Das Application Framework 31 beinhaltet Anwendungen wie den Resource Manager, den Content Pro-
vider (zuständig für den Austausch von Daten zwischen verschiedenen Anwendungen), den Telephony
Manager (für alle Telefonie-Dienste) und den für uns v. a. wichtigen Notification Manager, durch den
es möglich ist, Benachrichtigungen in der Statusleiste anzuzeigen.
Eine Schicht darunter liegen die Bibliotheken und die Android Runtime 32 . Neben Java-Bibliotheken
gibt es auch neue Android-Bibliotheken; sie stellen Entwicklern fertige Methoden für u. a. Datenban-
ken, Multimedia und den Browser bereit. Die Core-Bibliotheken mit der Java-API 33 sowie Androids
virtueller Maschine, der Dalvik Virtual Machine (DVM), stellt die Android Runtime zur Verfügung.
Zuunterst liegt der Linux-Kernel, der für die Speicher- und Prozessverwaltung verantwortlich ist. Zu-
sätzlich verwaltet er die Hardware-Treiber und kümmert sich um das Power-Management.
Dieser Abschnitt wurde sinngemäss übernommen vom Artikel „Technik erklärt: Google Android-
Architektur im Detail“ (PC Welt, 2010). Wir empfehlen den Artikel auch für zusätzliche Informatio-
nen z. B. über die DVM oder den Lebenszyklus einer Android-App.
5.1.2 Softwareanforderungen
Um das Sekretariatsprogramm ausführen zu können, muss Windows XP oder höher 34 installiert sein.
Da auf allen Computern der Schule Windows 7 zum Einsatz kommt, stellt dies überhaupt kein Prob-
lem dar.
Das Server-Programm wurde für Ubuntu 35 geschrieben, es läuft aber auch auf den anderen uns be-
kannten Linux-Distributionen. Server, auf denen eine Linux-Distribution installiert ist, sind keine Sel-
tenheit, daher gibt es im Internet auch genügend Angebote von Servern, auf denen Ubuntu bereits
vorinstalliert ist, die man mieten kann.
Die Android-Applikation haben wir auf Basis von Android 2.1 (Eclair 36 ) programmiert. Mit den vor-
hergehenden Versionen wird sie also nicht kompatibel sein. Dazu gehören allerdings nur etwa 2 %
aller Android-Geräte.
31 Der Anwendungsrahmen
32 Die Laufzeitumgebung
33 application programming interface = Programmierschnittstelle
34 D. h. Windows XP, Windows Vista oder Windows 7
35 Eine bekannte Linux-Distribution, vgl. http://www.ubuntu.com/
36 Die Android-Versionen werden üblicherweise mit dem Namen einer süssen Leckerei versehen

Architektur und Prozessschema des Gesamtsystems 21
Android 4 (Ice Cream Sandwich)
Android 2.3 (Gingerbread)
Abbildung 11: Die Android-Versionen im Vergleich, Stand: 3. Januar 2012 (Google Inc., 2012)
5.1.3 Datenübertragung
Damit das Android-App und das Sekretariatsprogramm mit dem Server kommunizieren können, wird
ein Protokoll zur Übertragung der Daten benötigt. Ein Protokoll regelt das Format und die Reihenfolge
der gesendeten Daten. Bekannt ist z. B. das HTTP 37 , das dazu verwendet wird, um Webseiten aus dem
WWW 38 in einen Webbrowser 39 zu laden. In unserem System kommt ein vergleichbares Protokoll
zum Einsatz, das gleichermassen auf TCP 40 basiert und zur Anwendungsschicht 41 gehört. Allerdings
ist es nicht so komplex wie HTTP, und es wurde darauf ausgelegt, dass möglichst einfach z. B. Ab-
senzenformulare vom Server abgerufen werden können oder neue Lehrpersonen ins Lehrerverzeichnis
hinzugefügt werden können.
Die Android-Versionen im Vergleich
Android 3 (Honeycomb)
Android 2.2 (Froyo)
Android 2.1 (Eclair)
Android 1.6 (Donut)
Android 1.5 (Cupcake)
5.1.3.1 Verbindungsauf- und -abbau
Um Daten zu übermitteln muss zuerst eine Verbindung zum Server aufgebaut werden. Dies geschieht
in dem der Client, das Android-App oder das Sekretariatsprogramm, ein sogenanntes SYN-Paket 42 an
den Server sendet. Wenn jener das Paket erhält, sendet er ein SYN/ACK-Paket 43 zurück, sowohl um
den Erhalt des SYN-Pakets zu bestätigen, als auch um seinerseits eine Bestätigung des Erhalts anzu-
fordern. Dies geschieht mit dem darauffolgend vom Client gesendeten ACK-Paket. Nachdem nun
beide Seiten die Verbindung bestätigt haben, ist sie aufgebaut und kann verwendet werden.
37
Hypertext Transfer Protocol
38
World Wide Web
39
Z. B. Internet-Explorer, Google Chrome, Mozilla Firefox
40
Transmission Control Protocol
41
Vlg. dazu OSI-Modell, http://de.wikipedia.org/wiki/OSI-Modell
42
SYN für synchronize
43
ACK für acknowledgement = Bestätigung
0% 10% 20% 30% 40% 50% 60%

Architektur und Prozessschema des Gesamtsystems 22
Client
SYN
SYN/ACK
ACK
Server
Abbildung 12: Verbindungsauf- und abbau
FIN
FIN/ACK
ACK
Server / Client Client / Server
Ähnlich wie der Aufbau funktioniert auch der Abbau einer Verbindung. Statt des SYN- bzw. des
SYN/ACK-Pakets wird ein FIN- bzw. ein FIN/ACK-Paket 44 gesendet, das dem Empfänger signali-
siert, dass keine Daten mehr vom Sender kommen werden. Mit dem Abbau der Verbindung kann so-
wohl der Client als auch der Server beginnen.
5.1.4 Sicherheit
Sicherheit wird immer wichtiger im Bereich der Informatik. Hacker-Angriffe sind an der Tagesord-
nung. Viele Firmen lassen sich daher die Sicherheit einiges kosten. Auch wir wollen diesen Bereich
nicht missachten.
5.1.4.1 Risikoanalyse
Jeder Schüler muss sich beim erstmaligen Starten der Android-App mit Benutzernamen und Passwort
anmelden. Es wird also ein Passwort vom Smartphone an den Server übermittelt, auf Wunsch von der
App gespeichert und auf dem Server auf Korrektheit überprüft. Ein Hacker kann sich theoretisch auf
dem Smartphone, auf dem Server oder während der Übertragung des Passworts Zugriff darauf ver-
schaffen 45 . Folglich muss es zwangsläufig verschlüsselt übertragen werden.
Des Weiteren sind mehr oder weniger heikle Daten auf dem Server gespeichert. Eine Lehrerabsenz
müsste nicht gross geschützt werden, da jede Person Zutritt zur KSS hat und sich diese Absenz auch
vor Ort in Augenschein nehmen kann, schaden kann es jedoch nicht. In einem weiteren Stadium könn-
ten aber durchaus auch persönlichere Daten auf dem Server gespeichert werden. Dies ist der Fall wenn
die App um neue Funktionen wie z. B. einer Notentabelle erweitert werden sollte. Solche Informatio-
nen müssen dann wiederum unbedingt verschlüsselt abgelegt sein.
5.1.4.2 Angemessenes Sicherheitsniveau
Die Passwörter anbelangend wollen wir keinen Aufwand scheuen und alles uns mögliche unterneh-
men, um sie bestmöglich zu schützen. Das ist uns ein sehr wichtiges Anliegen, weil es viele Personen
gibt, die ein und dasselbe Passwort für mehrere Accounts verwenden (IDG Communications AG,
2008). Es muss hier nicht weiter ausgeführt werden, welche Folgen es also haben könnte, wenn es
jemandem gelingen sollte, sich die Passwörter durch unser System anzueignen.
44 FIN für finisch = Ende
45 Genannt Phisphing

Architektur und Prozessschema des Gesamtsystems 23
Was die restlichen Daten betrifft, ergibt es keinen zusätzlichen Aufwand auch diese verschlüsselt zu
übermitteln, im Gegenteil. Es werden also auch jene Daten verschlüsselt versandt, die nicht notwendi-
gerweise geschützt werden müssten.
5.1.4.3 Funktionsweise
Um eine sichere Übertragung der Daten zu garantieren nimmt die clientseitige Software zuerst mit
dem Server eine Verbindung auf und fragt ihn nach dem öffentlichen Schlüssel 46 . Danach verschlüs-
selt der Client einen Sitzungsschlüssel 47 mithilfe des erhaltenen öffentlichen Schlüssels und übermit-
telt ihn dem Server. Da der Server den privaten Schlüssel 48 kennt, kann er den Sitzungsschlüssel ent-
schlüsseln. Somit kennen nun beide Seiten den Sitzungsschlüssel. Mit ihm werden die Informations-
Daten verschlüsselt.
Um sicherzustellen, dass die verschlüsselten Daten unterwegs nicht manipuliert wurden, wird vor dem
Versand ein Hashwert 49 erstellt und den Daten angehängt. Er wird bei Erhalt nach der Entschlüsselung
nochmals erstellt und mit dem versandten verglichen. Stimmen beide Werte überein, sind die Daten
aller Wahrscheinlichkeit nach nicht manipuliert worden.
Dazu einige Code-Beispiele im Anhang (Anhang 3).
5.2 Benutzeroberfläche
Mit der Benutzeroberfläche ist das gemeint, was der Benutzer von einem Programm auch wirklich
sieht. Die Sekretariats-Anwendung und das Android-App sind mit einer GUI 50 ausgestattet. Der Server
wird vollständig über die Konsole 51 bedient, weil er keine solche grafische Oberfläche besitzt.
46
Bestandteil der implementierten RSA-2048-Verschlüsselung
47
Mittels AES-256-Methode
48
Bestandteil der implementierten RSA-2048-Verschlüsselung
49
Mittels der BLAKE-512-Methode, vgl. http://en.wikipedia.org/wiki/BLAKE_(hash_function)
50
Graphical User Interface
51
Auch Kommandozeile, Eingabeaufforderung oder Terminal genannt

Architektur und Prozessschema des Gesamtsystems 24
5.2.1 Sekretariatsanwendung
Abbildung 13: Hauptfenster der Sekretariatsanwendung
5.2.1.1 Bedienung der Anwendung
Die Anwendung wird gleich gestartet wie jede andere
Windows-Anwendung, z. B. durch einen Doppelklick auf das
Desktop-Icon. Beim erstmaligen Starten wird man nach dem
Hostname 52 des Servers, dem zugewiesenen Port 53 , dem Be-
nutzernamen und dem Passwort gefragt (vgl. Abbildung 14
und Abbildung 15). Nach erfolgreicher Eingabe erscheint das
normale Fenster der Anwendung, zu dem man ab jetzt bei
Abbildung 15: Dialogfenster zur Abfrage der
Benutzer-Daten
jedem weiteren Starten direkt weitergeleitet wird (vgl. Ab-
bildung 13). Diese Einstellungen lassen sich zu einem spä-
teren Zeitpunkt im Menüpunkt „Extras“ verändern.
Im Programmfenster sind von oben nach unten die Menü-
Leiste, die Symbol-Leiste und eine Tab-Leiste platziert; sie
sind permanent sichtbar. Darunter folgt dar Hauptbereich,
der sich dem gewählten Tab entsprechend präsentiert.
Die Menü-Leiste besteht aus den Schaltflächen „Datei“, „Extras“ und „Hilfe“. Unter „Datei“ befinden
sich die Grundfunktionen der Anwendung 54 (vgl. Abbildung 16), die zusätzlich auch in der Symbol-
Leiste sind. Eine ausführliche Bedienungsanleitung lässt sich unter „Hilfe“ finden (vgl. Abbildung
18).
52 Adresse zur eindeutigen Identifizierung eines Rechners im Internet
53 „Türe“ durch die eine Verbindung hergestellt werden kann
54 Wie z. B. „Absenz erstellen…“
Abbildung 14: Dialogfenster zur Abfrage
der Server-Daten

Architektur und Prozessschema des Gesamtsystems 25
Abbildung 16: Untermenü von
„Datei“
entfernen…“ gelöscht werden.
Um im Hauptbereich eine Liste der Benutzer oder der
Stundenpläne zu sehen klickt man auf den entspre-
chenden Tab. Aufgrund der allfällig enormen Länge
der Benutzerliste befinden sich in der Symbolleiste
ein Such- und ein Dropdown-Feld. Durch das
Dropdown-Feld wird eine der Benutzer-Gruppen
(Administrator/in, Sekretär/in, Lehrer/innen oder
Schüler/innen) ausgewählt, die in Folge dessen im
Hauptbereich angezeigt wird 55 . Durch das Such-Feld
lässt sich die Auswahl noch genauer einschränken.
Eine genaue Bedienungsanleitung befindet sich in der
Sekretariatsanwendung selbst im Menü „Hilfe“ (vgl.
CD-ROM auf der hinteren Umschlagseite).
Abbildung 18: Hauptfenster der Hilfe
55 Standardmässig ist die Gruppe Lehrer/innen ausgewählt
In der Symbol-Leiste befinden sich die bereits erwähnten Buttons,
um Benutzer, Absenzen und Stundenpläne hinzuzufügen bzw. wie-
der zu entfernen. So öffnet sich beispielsweise nach Auswahl einer
Lehrperson und einem Klick auf „Absenz erstellen…“ ein Dialog-
fenster (vgl. Abbildung 17), in das die Sekretärin Start-, Endtermin
und Grund der Absenz einträgt. Nach einem bestätigenden Klick auf
„Erstellen“ wird die Absenz auf dem Server gespeichert und er-
scheint nun in der Liste der Absenzen im Hauptbereich. Nach Ab-
lauf der Absenz wird sie selbstständig entfernt, bei Bedarf kann sie
aber auch manuell per Auswahl derselben und Klick auf „Absenz
Abbildung 17: Dialogfenster zur Erstellung einer
Absenz

Architektur und Prozessschema des Gesamtsystems 26
5.2.1.2 Aufgaben der Sekretärin
Die Aufgabe der Sekretärin besteht nun darin, die Listen der Benutzer, der Absenzen und der Stun-
denpläne auf dem Laufenden zu halten. Der Schwerpunkt liegt dabei natürlich auf den Absenzen, die
unter Umständen mehrmals täglich aktualisiert werden müssen. Benutzer müssen jeweils am Anfang
des Schuljahres hinzugefügt werden, wenn neue Schüler/Lehrpersonen an die Schule kommen bzw.
sie verlassen. Damit man nicht jede/n Schüler/in einzeln hinzufügen muss, besteht die Möglichkeit,
alle Schüler/innen direkt aus einer Schülerliste im Excel 56 -Format, wie sie dem Sekretariat sowieso
vorliegt, zu importieren. Die Stundenpläne müssen jeweils vor Semesterbeginn neu importiert werden.
Dazu wird eine Textdatei verwendet, die zuvor aus dem Programm GP-Untis 57 , mit dem die Schullei-
tung die Stundenpläne erstellt (Kantonsschule Sargans, 2011), exportiert werden muss.
5.2.2 Mobile Anwendung
Abbildung 19: Die Android-App, von der Installation bis zu den Details einer Absenz
Die mobile Anwendung sieht eher unspektakulär aus. Sie besteht zum grössten Teil aus weisser
Schrift auf schwarzem Hintergrund, sowie dem Kanti-Logo.
56
Tabellen- und Kalkulationsprogramm aus dem Hause Microsoft
57
Vgl. http://www.grupet.at/

Architektur und Prozessschema des Gesamtsystems 27
5.2.2.1 Bedienung der Anwendung
Nach einem Tippen auf das Icon unserer App erscheint beim erstmaligen Start ebenfalls ein Fenster,
das den Anwender nach den Server- und Benutzer-Daten fragt. Danach folgt eine Übersicht mit allen
Funktionen der Anwendung (vgl. Abbildung 19.3). Nach Betätigung der Menü-Taste kann man die
App beenden oder weiter in die Einstellungen gelangen. Eine Funktion wählt man durch einfaches
Antippen aus.
Wenn eine Benachrichtigung (vgl. 5.1.1.3.1 und Abbildung 19.6) der App eintrifft, zieht der Schüler
die Status-Leiste nach unten und tippt auf den entsprechenden Eintrag, die App startet und der Schüler
bekommt die Informationen zur betreffenden Absenz (vgl. Abbildung 19.7).
5.2.2.2 Funktionen der Anwendung
Zum jetzigen Zeitpunkt besteht die Anwendung lediglich aus einer Funktion, der Absenzen-Funktion.
Sie präsentiert dem Schüler übersichtlich alle zurzeit aktuellen Lehrer-Absenzen, dazu Anfangs- und
Enddatum, den Grund und eventuell noch sonstige Informationen zu der jeweiligen Absenz.
Weitere Funktionen wie z. B. eine Notentabelle oder ein Chat-Client sind in Planung und werden zu
einem späteren Zeitpunkt lanciert, falls die App Anklang finden sollte und wirklich eingesetzt wird.
Der Aufwand für die Programmierung solcher Funktionen würde sich in Grenzen halten, da die ganze
Basis, bestehend aus Verbindungsprotokollen, Verschlüsselungstechnologien usw., bereits komplett
implementiert ist. Die Anwendung ist somit beliebig erweiterbar und auf weitere Systeme portierbar
(z. B. an anderen Schulen, etc.).

Zusammenfassung 28
6 Zusammenfassung
Durch diese Arbeit wurde klar aufgezeigt, dass von Seite der Schüler ein grosses Bedürfnis besteht,
per Smartphone-Applikation über schulrelevante Informationen, wie z. B. Stundenausfälle, informiert
zu werden. In einer Umfrage an der KSS gaben 78 % der befragten Personen an, dass sie eine mobile
Applikation, die diesen Dienst bieten würde, auf ihr Smartphone herunterladen und installieren wür-
den. Gegenüber dem jetzigen Informations-Medium der KSS, dem Anschlagbrett, bietet eine solche
digitale Lösung enorme Vorteile. Die Informationen gelangen praktisch in Echtzeit zum Schüler, und
sie können auf den Schüler spezifisch zugeschnitten werden.
Für die Entwicklung einer App mit dazu benötigtem Serverprogramm und Anwendung für das Schul-
sekretariat wurde als Hilfsmittel zuerst ein Vorgehensmodell für den Softwareentwicklungsprozess
zugezogen. Dies bedurfte zuerst einer Analyse diverser Modelle. Anhand des gewählten Modells und
verschiedener Programmiersprachen wurden nun die angestrebten Funktionen programmiert und op-
timiert. Nun steht eine Infrastruktur bereit, zumindest für eine kurze Testphase, eingesetzt zu werden.
Um den Entwicklungsprozess zu vereinfachen wurden zuerst diverse Vorgehensmodell zum Software-
entwicklungsprozess analysiert, eines davon ausgewählt und danach mithilfe von diesem entwickelt.
Zurzeit beschränkt sich die App ausschliesslich auf die Absenzen-Funktion, dafür wurde darauf geach-
tet, dass diese auf einer soliden Basis aufbaut, sodass die Grundelemente und zahlreiche Sicherheits-
vorkehrungen in vollem Umfang vorhanden sind. Die App kann somit ohne weiteres zu einem späte-
ren Zeitpunkt und ohne grossen Aufwand mit neuen Funktionen erweitert werden.
Aus Sicherheitsgründen darf auf einem Computer einer kantonalen Schule eine x-beliebige Anwen-
dung nicht ohne weiteres ausgeführt bzw. installiert werden. Sie bedarf zuerst einer Zertifizierung
durch den Kanton; für diesen Prozess muss mit einer Wartezeit von zwei Monaten gerechnet werden.
Eine allfällige Testphase könnte demnach im April/Mai 2012 stattfinden.

Literatur-/Quellenverzeichnis V
7 Literatur-/Quellenverzeichnis
20 Minuten AG. (11. Januar 2012). 20 Minuten Online - Android im Sinkflug - News. Von
http://www.20min.ch/digital/dossier/google/story/29298110 abgerufen
AOL Inc. (14. Dezember 2011). Android leads US market share, iOS may have stopped growing, RIM
is still falling -- Engadget. Von http://www.engadget.com/2011/12/14/shocker-android-grew-
us-market-share-after-q2-ios-was-static/ abgerufen
Apple Inc. (2011). Apple Developer Program Enrollment. Abgerufen am 21. Oktober 2011 von Apple
Developer Program Enrollment: http://developer.apple.com/programs/start/standard/
Apple Inc. (2011). iOS Developer Program - Apple Developer. Abgerufen am 21. Oktober 2011 von
http://developer.apple.com/programs/ios/
Aumasson, J.-P., Henzen, L., Meier, W., & Phan, R. C.-W. (16. Dezember 2010). SHA-3 proposal
BLAKE.
Baur, S. K. (16. Januar 2011). Entwicklungsmodelle. Abgerufen am 22. Juli 2011 von
http://www.stefan-baur.de/cs.se.modelle.html?glstyle=print
Becker, A., & Pant, M. (Mai 2009). Android - Grundlagen der Programmierung.
Bibliographisches Institut GmbH. (31. Dezember 2011). Duden | imperativ | Bedeutung,
Rechtschreibung, Synonyme, Grammatik. Von
http://www.duden.de/rechtschreibung/imperativ abgerufen
Bibliographisches Institut GmbH. (2011). Duden | Kommunikation | Bedeutung, Rechtschreibung,
Synonyme, Grammatik. Abgerufen am 13. Juli 2011 von
http://www.duden.de/rechtschreibung/Kommunikation
Bibliographisches Institut GmbH. (31. Dezember 2011). Duden | objektorientiert | Bedeutung,
Rechtschreibung. Von http://www.duden.de/rechtschreibung/objektorientiert abgerufen
Bibliographisches Institut GmbH. (1. Januar 2012). Duden | agil | Bedeutung, Rechtschreibung,
Synonyme, Herkunft. Von http://www.duden.de/rechtschreibung/agil abgerufen
Bibliographisches Institut GmbH. (1. Januar 2012). Duden | inkrementell | Bedeutung,
Rechtschreibung, Herkunft. Von http://www.duden.de/rechtschreibung/inkrementell abgerufen
Bürger, R. (25. März 2003). V-Modell. Von http://www.ralfbuerger.de/sse/Vorgehensweise/Fenster/V-
ModellSeite.htm abgerufen
Dehmer, J. (4. Juli 2003). Informatik in der Oberstufe - Vernetzung von Rechnern (1). Abgerufen am
25. August 2011 von http://www.lehrer.uni-
karlsruhe.de/~za714/informatik/infkurs/vernetzung1.html

Literatur-/Quellenverzeichnis VI
Ezunov, A., & Grundmeier, N. (15. März 2011). Fehler im Programmcode | Sicherheitslücken im
Internet. Von http://www.informatik.uni-oldenburg.de/~iug10/sli/index01ce.html abgerufen
FHS St. Gallen. (25. März 2011). Extreme Programming (altervative Beschreibung) – FHS Software
Engineering Wiki. Abgerufen am 22. Juli 2011 von
http://morpheus.fhsg.ch/~mw_swe/index.php/Extreme_Programming_(altervative_Beschreibu
ng)
Frauenhofer Institut Rechnerarchitektur und Softwaretechnik FIRST. (18. Juni 2004).
Testfallerzeugung aus Use-Case-Beschreibungen. Von http://www.gm.fh-
koeln.de/~winter/tav/html/tav21/TAV21F5Friske.pdf abgerufen
Free Software Foundation. (2011). The GNU MP Bignum Library. Von http://gmplib.org/ abgerufen
Golesny, D. (1. Februar 2006). 5.2.3 Vorgehensmodelle. Abgerufen am 22. Juli 2011 von
http://www.golesny.de/bin/diplom/diplomarbeit.pdf
Google. (2011). Anmeldung für Entwickler. Abgerufen am 21. Oktober 2011 von
https://market.android.com/publish/signup
Google. (27. Oktober 2011). What is Android? | Android Developers. Von
http://developer.android.com/guide/basics/what-is-android.html abgerufen
Google Inc. (2011). Philosophy and Goals | Android Open Source. Abgerufen am 16. Juli 2011 von
http://source.android.com/about/philosophy.html
Google Inc. (3. Januar 2012). Platform Versions | Android Developers. Von
http://developer.android.com/resources/dashboard/platform-versions.html abgerufen
Gummlich, W. (18. Januar 2007). Advanced Encryption Standard Rijndael.
Hinzberg, H. (kein Datum). C# Übersicht. Abgerufen am 24. August 2011 von
http://www.hinzberg.net/csharp/csharp/uebersicht.html
IDG Communications. (11. Januar 2011). Java bleibt beliebteste Programmiersprache -
computerworld.ch. Abgerufen am 25. Juli 2011 von
http://www.computerworld.ch/news/software/artikel/java-bleibt-beliebteste-
programmiersprache-55440/
IDG Communications AG. (23. Januar 2008). Immer das gleiche Passwort - Sie auch? - PCtipp.ch -
News. Von
http://www.pctipp.ch/news/sicherheit/42015/immer_das_gleiche_passwort_sie_auch.html
abgerufen

Literatur-/Quellenverzeichnis VII
Informatik Forum Simon GmbH. (2011). INffORUM: Anwendungsentwicklung - Vorgehensmodell
Software Engineering. Abgerufen am 13. Juli 2011 von
http://www.infforum.de/themen/anwendungsentwicklung/thema_SE-vorgehensmodelle.htm
Infoworld. (2011). So why did they decide to call it Java? - JavaWorld. Abgerufen am 25. Juli 2011
von http://www.javaworld.com/javaworld/jw-10-1996/jw-10-javaname.html?page=3
it-agile. (2008). it-agile: Was ist Scrum? Abgerufen am 21. August 2011 von http://www.it-
agile.de/scrum.html
Jürgen, W. (2009). C von A bis Z. Bonn: Galileo Press.
Kantonsschule Sargans. (2011). Stundenplan. Von
http://www.kantisargans.ch/home/service/stundenplan.html abgerufen
Kantonsschule Sargans. (2011). Zahlen & Fakten. Abgerufen am 10. Oktober 2011 von
http://www.kantisargans.ch/home/unsere_schule/zahlen___fakten.html
Kersken-Canbaz, S. (2008). Geschichte | Programmieren in Java. Abgerufen am 25. Juli 2011 von
http://programmieren-in-java.de/de/content/geschichte
Kioskea. (1. April 2009). Client/Server Umgebung. Abgerufen am 25. August 2011 von
http://de.kioskea.net/contents/cs/csintro.php3
Kriegisch, A. (2010). Scrum - auf einer Seite erklärt. Abgerufen am 21. August 2011 von http://scrum-
master.de/Was_ist_Scrum/Scrum_auf_einer_Seite_erklaert
Kühnel, A. (2010). Visual C# 2010. Bonn: Galileo Press.
Microsoft. (2011). Erste Schritte mit Visual C#. Abgerufen am 24. August 2011 von
http://msdn.microsoft.com/de-de/vcsharp/dd919145.aspx
Oracle. (7. April 2011). Lernen über Java-Technologie. Abgerufen am 25. Juli 2011 von
http://www.java.com/de/about/
PC Welt. (17. September 2010). Smartphone-Grundlagen - Technik erklärt: Google Android-
Architektur im Detail - Smartphone - PC-WELT. Abgerufen am 14. September 2011 von
http://www.pcwelt.de/ratgeber/Smartphone-Grundlagen-Technik-erklaert-Google-Android-
Architektur-im-Detail-1005294.html
Queins, D. S., & Rupp, C. (15. September 2003). Vom Use-Case zum Test-Case. Von
http://www.gm.fh-koeln.de/~winter/tav/html/tav20/P7RuppQueinsTAV20.pdf abgerufen
RSA Laboratories. (14. Juni 2002). RSA Cryptography Standard.
Schwaber, K., & Sutherland, J. (Juli 2011). Scrum Guides - Scrum.org. Abgerufen am 22. August
2011 von http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20DE.pdf

Literatur-/Quellenverzeichnis VIII
siemax CMS Webdesign & Internetservice Feldkirchen. (2011). Glossar:: Begriffe wie Homepage,
Website und WWW werden hier für den Internet-User erklärt. Abgerufen am 13. Juli 2011 von
http://www.siemax.com/DE/h_computer.html
Software Quality Lab. (8. November 2003). http://www.software-quality-lab.at/. Abgerufen am 22.
Juli 2011 von http://www.software-quality-lab.at/swql/uploads/media/SWQL-Newsletter-
200311.pdf
Sommergut, W. (1. Oktober 1997). Was ist C ?: C im Vergleich zu anderen Programmiersprachen.
Abgerufen am 23. August 2011 von http://c-buch.sommergut.de/Kapitel1/C-im-Vergleich-zu-
anderen-Programmiersprachen.shtml
SPIEGELnet GmbH. (9. Mai 2011). Smartphone-Studie: Android überholt Apple iOS in Deutschland -
SPIEGEL ONLINE - Nachrichten - Netzwelt. Von
http://www.spiegel.de/netzwelt/netzpolitik/0,1518,761434,00.html abgerufen
Stein, S. (26. Mai 2004). 6.3.2 Vorgehensmodell Wasserfallmodell und V-Modell. Von
http://emergenz.hpfsc.de/html/node42.html abgerufen
TEIA AG. (1. Juni 2009). Projektplanung und Projektoptimierung mit MS Project 2003 - 2.2.3
Vorgehensmodelle - TEIA AG. Von http://www.teialehrbuch.de/Kostenlose-
Kurse/Projektplanung-mit-MS-Project-2003/31132-Vorgehensmodelle.html abgerufen
Ullenboom, C. (2011). Java ist auch eine Insel. Bonn: Galileo Press.
Wikipedia. (17. November 2004). Datei:Spiralmodel nach Boehm.png – Wikipedia. Von
http://de.wikipedia.org/w/index.php?title=Datei:Spiralmodel_nach_Boehm.png abgerufen
Wikipedia. (21. Dezember 2006). Datei:Java-Logo.svg – Wikipedia. Von
http://de.wikipedia.org/wiki/Datei:Java-Logo.svg abgerufen
Willemse Isabel, W. G. (2010). www.news.admin.ch - Medienmitteilungen und Reden. Abgerufen am
11. Oktober 2011 von
http://www.news.admin.ch/NSBSubscriber/message/attachments/24286.pdf

Abbildungsverzeichnis IX
8 Abbildungsverzeichnis
Abbildung 1: Die Kaffeetasse als Java-Logo (Wikipedia, 2006) ............................................................ 4
Abbildung 2: Diagramm zum Marktpotenzial einer Kommunikations-App an der KSS ....................... 7
Abbildung 3: Diagramm zur Marktverteilung der mobilen Betriebssysteme an der KSS ...................... 8
Abbildung 4: Die einzelnen Schritte des Wasserfallmodells, gemäss (TEIA AG, 2009) ..................... 10
Abbildung 5: Das Spiralmodell von Barry W. Boehm (Wikipedia, 2004) ........................................... 11
Abbildung 6: Schichten des (vereinfachten) V-Modells, gemäss (Bürger, 2003)................................. 12
Abbildung 7: Ablauf eines XP-Projekts (FHS St. Gallen, 2011) .......................................................... 12
Abbildung 8: Grafische Darstellung von Scrum (it-agile, 2008) .......................................................... 13
Abbildung 9: Infrastruktureinheiten: Sekretariats-PC, Server und zwei mobile Endgeräte .................. 18
Abbildung 10: Architektur von Android (Google, 2011) ...................................................................... 19
Abbildung 11: Die Android-Versionen im Vergleich, Stand: 3. Januar 2012 (Google Inc., 2012) ...... 21
Abbildung 12: Verbindungsauf- und abbau .......................................................................................... 22
Abbildung 13: Hauptfenster der Sekretariatsanwendung ...................................................................... 24
Abbildung 14: Dialogfenster zur Abfrage der Server-Daten ................................................................ 24
Abbildung 15: Dialogfenster zur Abfrage der Benutzer-Daten ............................................................ 24
Abbildung 16: Untermenü von „Datei“................................................................................................. 25
Abbildung 17: Dialogfenster zur Erstellung einer Absenz ................................................................... 25
Abbildung 18: Hauptfenster der Hilfe ................................................................................................... 25
Abbildung 19: Die Android-App, von der Installation bis zu den Details einer Absenz ...................... 26

Anhang A1
Anhang
1 Umfrage-Formular
Kantonsschule Sargans Kevin Stierli,
Gymnasium Raphael Haslebacher
Umfrage Abschlussarbeit 2012 Physik und Anwendungen der Mathematik
Liebe/r Klassenchef/in
Im Rahmen unserer Maturaarbeit mit dem Titel „Mobile Anwendung zur Kommunikation von
schulrelevanten Informationen“ werden wir eine Applikation (App) für Handys erstellen, mit der es
unter anderem möglich sein wird, sich über Stundenausfälle zu informieren, beispielsweise wenn
eine Lehrperson krank ist. Die App soll also nicht zuletzt als digitales Anschlagbrett dienen.
Wir bitten dich, den ersten Teil dieser Umfrage mit Hilfe deiner Klasse auszufüllen und uns dieses
Blatt bis spätestens Freitag, 9. September 2011, ins Klassenfach der 3P oder der 4NP zu legen. Den
zweiten Teil sollte eine Person der Klasse ausfüllen, die sich besonders gut mit Handys auskennt.
1. Teil – Bedürfnisabklärung
Angenommen es gäbe bereits heute eine App wie oben beschrieben, wie viele Personen der Klasse
(jeweils Anzahl einsetzen) würden diese App herunterladen und auf ihrem Handy installieren, wenn
diese App für ihr jeweiliges Handy verfügbar wäre; wie viele „vielleicht“ und wie viele „nicht“?
Ja: ______ Nein: ______ Vielleicht: ______ kein Handy: ______
2. Teil – Mobile Betriebssysteme
In diesem Teil möchten wir erfahren, wie viele Personen der Klasse welches der folgenden mobilen
Betriebssysteme auf ihrem Handy installiert haben.
� Android von Google (z. B. Samsung Galaxy S, HTC Desire, Sony Ericsson Xperia)
� iOS von Apple (iPhone)
� Windows Phone 7 von Microsoft (z. B. HTC 7 Trophy, Samsung Omnia 7)
� Symbian von Nokia (fast alle Nokia-Modelle)
Viele vor allem ältere Handys, wie z. B. das Sony Ericsson W810i, besitzen
individuelle Eigenproduktionen, die in dieser Umfrage unter „Sonstiges“
einzutragen sind.
Android-Geräte erkennt man beispielsweise
durch die drei immer vorhandenen Tasten:
Zurück, Menu und Home, eventuell zusätzlich noch Suchen.
Für Windows Phone 7 ist die quadratische Menüführung (meist hellblau) und das
Windows-Logo als Home-Button charakteristisch.
Android: ______ iOS: ______ WP7: ______ Symbian: ______
Sonstiges: ______
Name der Klasse: ________ Vielen Danke für eure Teilnahme!
29.08.2011 Seite 1/1

Anhang A2
2 Rohdaten der Umfrage
2.1 Bedürfnisabklärung
n = 490
Klasse Ja Nein Vielleicht kein Handy
1bNPW 16 2 1 6
1F 12 9 4 0
1GM 15 2 7 0
1LWA 19 2 0 2
1NP 14 2 4 1
1WB 15 1 1 0
2bNPW 21 1 1 0
2F 12 1 4 0
2IWA 15 3 5 0
2LS 16 0 1 1
2NP 18 0 3 0
2WB 15 0 0 0
3EA 13 0 3 0
3F 19 0 1 0
3GM 10 7 1 0
3IS 18 0 0 0
3LN 17 0 3 0
3P 16 0 0 1
3WA 8 1 11 0
3WB 18 0 0 0
4FP 10 1 1 0
4IL 12 6 0 0
4NP 17 0 2 1
4S 23 0 0 0
4WA 15 3 0 0
Summe 384 41 53 12
Prozent 78.4 % 8.4 % 10.8 % 2.5 %
Abweichungen zu 100 % sind rundungsbedingt.

Anhang A3
2.2 Mobile Betriebssysteme
Klasse Android iOS WP7 Symbian Sonstiges
1bNPW 7 9 0 0 3
1F 5 4 0 4 12
1GM 6 1 0 4 13
1LWA 12 7 0 2 0
1NP 5 6 0 3 6
1WB 3 11 0 1 2
2bNPW 9 5 1 1 7
2F 9 2 1 3 2
2IWA 10 4 0 0 9
2LS 5 5 0 0 7
2NP 7 8 0 2 4
2WB 4 6 0 0 5
3EA 2 9 0 0 5
3F 4 7 0 0 9
3GM 5 5 1 0 7
3IS 1 4 0 0 13
3LN 2 8 0 1 9
3P 8 3 1 4 0
3WA 4 5 0 0 11
3WB 5 8 0 2 3
4FP 0 3 1 0 8
4IL 3 2 0 1 12
4NP 2 8 1 3 5
4S 2 6 0 1 14
4WA 6 6 0 0 6
Summe 126 142 6 32 172
Prozent 26.4 % 29.7 % 1.3 % 6.7 % 36.0 %
n = 478
Abweichungen zu 100 % sind rundungsbedingt.

Anhang A4
3 Codebeispiele
Die folgenden drei Codebeispiele sind dazu da, um in der schriftlichen Arbeit, neben der Benutzer-
oberfläche der Anwendungen (vgl. 5.2), einen weiteren Eindruck der praktischen Arbeit zu vermitteln.
Es soll einem bewusst werden, was wirklich hinter der Oberfläche steckt. Wir haben für jede von uns
verwendete Programmiersprache einen Ausschnitt aus dem Quellcode als Beispiel zur Veranschauli-
chung des jeweiligen Code-Bilds ausgewählt. Die nachfolgenden 184 Programmier-Zeilen stellen nur
etwa 1.5 % der beinahe 12‘000 Code-Zeilen dar. Die vollständigen Quellcodes der erstellten Pro-
gramme befinden sich auf der beiliegenden CD-ROM.
C# findet bei der Sekretariatsanwendung Verwendung. Als Beispiel dazu wird beschrieben, wie eine
Absenz zum Server hochgeladen wird. Durch das Java-Beispiel wird veranschaulicht, wie die benut-
zerspezifischen Absenzen durch das Android-Smartphone vom Server heruntergeladen werden. Wie
sie aus Sicht des Servers dem Android-Client übertragen werden, ist im dritten Beispiel dargestellt.
3.1 C#
/*
Funktion: bool addAbsence(PAddAbsence abs);
Beschreibung: Lädt eine Absenz abs zum Server hoch.
Rückgabewert: true bei Erfolg, false bei Fehler
*/
private static bool addAbsence(PAddAbsence abs)
{
SecureSocket ssock = new SecureSocket(Config.getHostname(), Config.getPort(),
RSAPUBLICKEY); // sicheres Socket erstellen
}
if (!ssock.connect()) // Verbindung zu Server herstellen
{
return false;
}
KSSPRequest req = new KSSPRequest(Const.VERSION, Cmd.ADD_ABSENCE, Config.getUsername(),
Config.getPassword(), abs.getBytes());
// Anfrage mit Benutzername, Passwort und Absenz erstellen
ssock.send(req.getEncryptedBytes()); // Anfrage senden
byte[] buf; // Puffer
if ((buf = ssock.receive(KSSPResponse.bytelength, TIMEOUT)) == null)
// Antwort empfangen
{
ssock.close();
return false;
}
ssock.close(); // Verbindung schliessen
KSSPResponse resp = new KSSPResponse(buf); // Antwort erstellen
return resp.successful();

Anhang A5
3.2 Java
/*
Funktion: ArrayList getAbsences();
Beschreibung: Lädt alle benutzerspezifischen Absenzen herunter.
Rückgabewert: Eine Absenzenliste(ArrayList) mit allen
heruntergeladen Absenzen bei Erfolg, null bei Fehler
*/
private ArrayList getAbsences(){
KSSPRequest req=new KSSPRequest(Const.VERSION,
Cmd.GET_PERSONAL_ABSENCES, this.username, this.password, null);
// Anfrage mit Benutzername und Passwort
try{
SecureSocket ssock=new SecureSocket(this.hostname, this.port, RemoteService.RSAPUBLICKEY,
getApplicationContext());
// sicheres Socket erstellen
ssock.connect(); // Verbindung zu Server herstellen
ssock.send(req.getBytes()); // Anfrage senden
ArrayList absl=new ArrayList(); // Absenzenliste
Absence abs; // Absenz
KSSPResponse resp; // Antwort
byte[] buf; // Puffer
}
for(;;){
if((buf=ssock.receive(KSSPResponse.bytelength, RemoteService.TIMEOUT))==null){
// Antwort empfangen
ssock.close();
return null;
}
}
resp=new KSSPResponse(buf); // Antwort erstellen
if(resp.getState()==KSSPResponse.STATE_FIN ||
!resp.successful()){ // Status überprüfen
break;
}
if((buf=ssock.receive(Absence.length, RemoteService.TIMEOUT))==null){
// Absenz empfangen
ssock.close();
return null;
}
abs=new Absence(buf); // Absenz erstellen
absl.add(abs); // Absenz der Absenzenliste hinzufügen
ssock.close(); // Verbindung schliessen
if(absl.size()==0){ // Absenzenliste überprüfen
absl=null;
}
return absl;
}
catch(Exception e){
return null;
}

Anhang A6
3.3 C
/*
Funktion: int _getpersabss(int clnd, struct _usr *usr, char *aeskey);
Beschreibung: Alle Absenzen, die für den Benutzer usr bestimmt sind,
werden mithilfe des AES-256-Schlüssels aeskey
AES-256-verschlüsselt an den Clienten mit dem Deskriptor
clnd übertragen.
Rückgabewert: 0(SUC) bei Erfolg, -1(ERR) bei Fehler
*/
int _getpersabss(int clnd, struct _usr *usr, char *aeskey){
int fd; // Datei-Deskriptor
if((fd=open(ABSFILE, O_RDONLY|O_CREAT, ACC_RIGHTS))==ERR){
// Absenzen-Datei mit Leserechte öffnen
return ERR;
}
struct _abs abs; // Absenzen-Variable
struct _usr tchr; // Lehrer-Variable
struct _sched sched; // Stundenplan-Variable
int ret;
resp.state=STATE_MORE; // Status für Client
for(;;){
_zero((char*)&abs, sizeof(struct _abs));
// Absenzen-Variable leeren
if((ret=read(fd, &abs, sizeof(struct _abs)))==ERR){
// Absenz einlesen
break;
}
if(ret

Anhang A7
}
}
if(abs.strtdw6 || abs.enddw6){
// Absenz überprüfen
continue;
}
strtless=(abs.strtdw-1)*LESS_PER_DAY+abs.strtl;
// Lektionsstart berechnen
endless=(abs.enddw-1)*LESS_PER_DAY+abs.endl;
// Lektionsende berechnen
int yes;
yes=0;
if(strtless

Selbstständigkeitserklärung
Wir, Kevin Stierli und Raphael Haslebacher, bestätigen hiermit, dass wir diese Maturaarbeit unter
Verwendung der angegebenen Quellen selbstständig entwickelt, gestaltet und geschrieben haben.
Sargans, 3. Februar 2012 _________________________________
_________________________________