Konzeption und Implementierung einer iPad Applikation für ein Meeting-Support-System


Thèse de Bachelor, 2011

68 Pages, Note: 1,3


Extrait


Inhaltsverzeichnis

Erklärung

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Abstract

1 Einführung
1.1 Motivation der Problemstellung
1.2 Aufgabenstellung
1.3 Übersicht über die folgenden Kapitel der Arbeit

2 Grundlagen
2.1 Besprechung(Meeting)
2.1.1 Begriffserklärungen
2.1.2 Meeting-Phasen
2.1.3 Werkzeuge
2.1.4 Besprechungstypen
2.2 Gruppenwahrnehmung (Awareness)
2.2.1 Begriffserklärungen
2.2.2 Arten derAwareness-Informationen
2.2.3 Klassifikation von Groupware
2.3 Elektronisches MeetingSystem (EMS)
2.3.1 Begriffserklärungen
2.3.2 Sitzungsunterstützung durch EMS
2.4 TechnischeGrundlagen
2.4.1 iOS Architektur
2.4.2 Xcode Entwicklungsumgebung
2.4.3 Cocoa Design Patterns

3 Anforderungsanalyse
3.1 Szenarien
3.1.1 Anmeldenam System
3.1.2 Meetingstartet
3.1.3 Darstellung besprechungsspezifischer Informationen
3.1.4 Konfiguration des Meeting-Fortschritts
3.1.5 Wortmeldungen
3.1.6 Meetingbeenden
3.2 Akteure
3.3 Anwendungsfalldiagramm
3.4 Zusammenfassung der Anforderungen

4 StandderForschung
4.1 Darstellung existierender Ansätze
4.1.1 GroupSystemsThinkTank
4.1.2 DOLPHIN
4.1.3 CiscoWebEXMeeting Center
4.2 Zusammenfassung
4.2.1 Klassifikation nach Raum/ Zeit
4.2.2 Defizite

5 Lösungskonzept
5.1 Softwarearchitektur
5.2 Entwurfsentscheidungen
5.2.1 Datenmodell
5.2.2 Programmablauf

6 Implementierungsdetails
6.1 AllgemeineAnforderungen
6.2 Living Agendas Schnittstelle
6.2.1 Schnittstellentyp und Austauschformat
6.2.2 Services
6.3 Clientimplementierung
6.3.1 Datenmodell
6.3.2 Grafische Darstellung der Benutzerschnittstelle
6.3.3 Wortmeldungen
6.4 Eingesetzte Fremd-Bibliotheken
6.4.1 SBJson
6.4.2 ASIHTTPRequest
6.4.3 ISO8601DateFormatter

7 Fazit
7.1 Zusammenfassung
7.2 Vorschläge zur Weiterentwicklung
7.2.1 Apple Push Notification Service
7.2.2 Protokollierung von Wortmeldungen und Ergebnissen
7.2.3 Zugriff auf alte Meetings und Protokolle
7.2.4 Bearbeiten und verschieben von Wortmeldungen

8 Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2-1 - Raum-Zeit-Matrix nach Johansen (Teufel, et al. 1995)

Abbildung 2-2 - Klassifikationsschema nach Unterstützungsfunktionen (Teufel, et al. 1995)

Abbildung 2-3 - Apple iOS System Layer

Abbildung 2-4 - MVC-Pattern (Koller 2011)

Abbildung 2-5 - Organisation von MVC in Cocoa (Buck und Yacktman 2009)

Abbildung 3-1 - Identifizierte Akteure von SL

Abbildung 3-2 - Grobes Anwendungsfalldiagramm von SL

Abbildung 4-1 - GroupSystems ThinkTank im Einsatz

Abbildung 4-2 - DOLPHIN im Einsatz

Abbildung 4-3 - Cisco WebEX iPad Applikation

Abbildung 5-1 - Softwarearchitektur

Abbildung 5-2 - Datenmodell von Speaker's List

Abbildung 5-3 -Speaker's List Programmstart

Abbildung 5-4 - Speaker's List Hauptansicht „Meeting Auswahl"

Abbildung 5-5 - Speaker's List Hauptansicht "Aktive Meeting-Session"

Abbildung 5-6 - Prozessablauf „Agendapunkt schließen"

Abbildung 5-7 - Speaker's List Detailansichten für Agendapunkte und Teilnehmer

Abbildung 5-8 - Speaker's List Hauptansicht "Neue Wortmeldung hinzufügen"

Abbildung 5-9 - Wortmeldungen Zustandsübergangsdiagramm

Abbildung 5-10 - Wortmeldungen löschen

Abbildung 5-11 - Wortmeldung verschieben

Abbildung 5-12 - Speaker's List Hauptansicht "Bitte sprechen Sie jetzt"

Abbildung 6-1 - Living Agendas API

Abbildung 6-2 - Beispieldatenrepräsentation für Datenstruktur Meeting

Abbildung 6-3 -TableView Methode "number Of Rows lnSection"

Abbildung 6-4-TableView Methode "cell For Row At lndex Path"

Abbildung 6-5 - Konfiguration einer UITableViewCell

Abbildung 6-6 - TableView Methode "numberOfSectionslnTableView"

Abbildung 6-7-TableView Methode "titleForHeaderlnSection"

Abbildung 6-8-TableView Methode "titleForFooterlnSection"

Abbildung 6-9 - TableView Delegate Methode "did Selec Row At lndex Path"

Abbildung 6-10-TableView Delegate Methode "editing Style ForRow At lndex Path"

Abbildung 6-11-TableView Delegate Methode "commit Editing Style"

Abbildung 6-12 - TableView Delegate Methode "can MoveRow At lndex Path"

Abbildung 6-13 - TableView Delegate Methode "target lndex Path For Move From Row At lndex Path" .

Abbildung 6-14-TableView Delegate Methode "moveRowAtlndexPath"

Abbildung 6-15 - lSO8601DateFormatter Beispiel-lmplementierung

Abbildung 6-16 - Invalidieren einer gecachten Sitzung 55

Abbildung 6-17 - Einsatz von ASIHTTPRequest

Abbildung 6-18 - ISO8601DateFormatter Beispiel-Implementierung

Tabellenverzeichnis

Tabelle 2-1 - Phasen der Gesprächsdurchführung

Tabelle 3-1 -Tabellarische Darstellung der Anforderungen

Tabelle 4-1 - Klassifizierung der Applikationen nach Raum-Zeit-Matrix

Tabelle 6-1 - Living Agendas "Meetings" Schnittstelle

Tabelle 6-2 - Living Agendas „Agenda" Schnittstelle

Tabelle 6-3 - Living Agendas „Benutzer" Schnittstelle

Tabelle 6-4 - Living Agendas „Wortmeldungen" Schnittstelle

Tabelle 6-5 - Living Agendas „Aufgaben" Schnittstelle

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abstract

Am Lehrgebiet Kooperative Systeme der FernUniversität in Hagen wird ein Meeting Support System entwickelt, dessen Einsatzbereich in der computerunterstützten Durchführung von Besprechungen vor Ort liegt. Es handelt sich um ein web-basiertes System, welches über einen Browser aufgerufen werden kann. Eine Administrationsoberfläche bietet die Möglichkeit, Meetings anzulegen oder zu verwalten. Die vorliegende Abschlussarbeit behandelt die Konzeption und konkreten Umsetzung der Apple iPad Applikation Speaker's List, die als Schnittstelle zwischen den Teilnehmern des Meetings und dem o.g. MSS fungiert und verschiedene, sitzungsunterstützende Werkzeuge bereithält. Die Umsetzung erfolgt als native iOS-Anwendung, bei der sowohl die Verarbeitung der Daten als auch die grafische Benutzeroberfläche realisiert wird.

1 Einführung

Im heutigen Arbeitsalltag sind Meetings (in dieser Arbeit auch als Konferenzen, Besprechungen oder Sitzungen bezeichnet, vgl. 2.1.1) beinahe nicht mehr wegzudenken. So treffen Tag für Tag in vielen verschiedenen Unternehmen unterschiedlichster Branchen Gruppen von Teilnehmern zusammen, um Entscheidungen zu fällen, Probleme zu diskutieren und zu lösen, Projekte und die nächsten Schritte zu planen oder einer Präsentation beizuwohnen (vgl. Abschnitt 2.1.4). Dabei beginnt eine Besprechung schon vor der eigentlichen Zusammenkunft und erfordert als vorgelagerte Phase zum Teil weitreichende Vorbereitungen wie das Organisieren von benötigten Ressourcen oder das Ver­senden einer Einladung. Aber auch nach dem Termin erfordert ein Meeting Nachbereitungszeit, in der z.B. Berichte verfasst und versendet werden müssen. In der eigentlichen Meeting-Durchführung können die Teilnehmer informiert, Vorgaben ausgearbeitet oder auch Abstimmungen gefällt wer­den. Diese Phase bietet vielfältige Möglichkeiten für Softwareanwendungen, Prozesse effizient zu unterstützen, mögliche Werkzeuge sind z.B. Brainstorming- oder Abstimmungstools.

Ein Schwerpunkt der Forschungsarbeiten im Gebiet der Computer Supported Coordinated Work (CSCW) stellt die computerunterstützte Durchführung von Meetings durch Sitzungsunterstützungs­systeme dar. Diese Systeme bieten einen vielversprechenden Ansatz, da mit ihrer Hilfe die bekann­ten Werkzeuge und Methoden programmatisch umgesetzt und erforderliche Workflows für die Pro­zessstrukturierung bereitgehalten werden. Diese können im Rahmen einer Besprechung gezielt ein­gesetzt werden und zu einer Effizienzsteigerung und erhöhten Produktivität führen.

Am Lehrgebiet Kooperative Systeme wird das Meeting Support System (MSS) Living Agendas (LA) entwickelt, welches als Web-Anwendung über einen Browser aufgerufen und bedient werden kann. Es bietet derzeit Werkzeuge, mit denen Meetings geplant und vorbereitet werden können. Durch eine bereitgestellte Schnittstelle (vgl. 6.2.2) kann gezielt auf die gespeicherten Daten zugegriffen werden, um diese auch in Client-Anwendungen auswerten und weiterverarbeiten zu können.

1.1 Motivation der Problemstellung

Die Durchführung von Meetings kann sich als zeitraubende und ineffiziente Beschäftigung erweisen, vor allem wenn sie den Manageralltag dominieren und nur selten den gewünschten Erfolg erzielen. (Case 1962) schreibt dazu sehr passend: „If any substantial reduction were to be made in the execu­tive working days (...), the most fruitful place to begin would be to cut down on conference time." Diesem Wunsch nach einer effizienteren Durchführung von Konferenzen und der Reduktion der Besprechungszeit könnte eine Vielzahl weiterer Zitate aus der Literatur oder Kommentaren aus Dis­kussionsforen im Internet folgen. Es gibt eine ganze Reihe an verschiedenen Büchern und Ratgebern, in denen Lösungsansätze zur effizienten Durchführung von Meetings vorgeschlagen werden. Auffällig ist hierbei, dass im Regelfall Methoden und Werkzeuge zur Prozessstrukturierung (vgl. Abschnitt 2.1.3) angeboten werden, wie z.B. das Festlegen von Zeitrahmen und Agenda, das strukturierte Füh­ren durch die Agenda, die Nutzung verschiedener Kreativitätstechniken zur Erfassung neuer Ideen oder zur Entscheidungsfindung.

Jedem Leser kommen die folgenden beschriebenen Auszüge aus dem Meeting Alltag sicherlich be­kannt vor. Sie beschreiben Situationen, in denen Computerunterstützung durch eine Software, die von den Teilnehmern ausgeführt wird, durchaus hilfreich und vorstellbar wäre: Gerade in Meetings mit größerer Teilnehmeranzahl ist immer wieder festzustellen, dass einem Teilnehmer nach einer kurzen Ablenkung der Wiedereinstieg in das Geschehen meist nur durch Rückfrage möglich zu sein scheint. Hilfreich wäre es, wenn der Teilnehmer jederzeit die Möglichkeit hätte, sowohl den Meeting Fortschritt als auch den aktuellen Agendapunkt einzusehen. Ein weiteres Phänomen ist bei Wort­meldungen festzustellen, bei denen einzelne Teilnehmer häufiger zu Wort kommen als andere oder aber Themen in hitzigen Diskussionen enden. Es wäre sinnvoll, wenn Teilnehmer ihre Wortmeldun­gen gegenüber einem System registrieren könnten und der Moderator so die Möglichkeit hat, jeden Sprechwunsch nach einem strukturierten Vorgehen freizugeben.

1.2 Aufgabenstellung

Im Rahmen dieser Bachelorarbeit wird die native Client-Applikation Speakers' List (SL) für Apples Tablet-Computer iPad entwickelt. Dabei wird unter einer nativen Applikation verstanden, dass sie für ein bestimmtes Betriebssystem entwickelt wird und dieses somit nativ unterstützt. Dies hat den Vorteil, dass keine weiteren Programme oder Emulatoren für die Ausführung erforderlich sind und auf spezifische Funktionalitäten und Bibliotheken des zugrundeliegenden Betriebssystems zugegrif­fen werden kann.

SL soll Werkzeuge und Techniken zur Verfügung stellen, die die Teilnehmer und den Moderator wäh­rend eines Meetings unterstützen. SL soll gegenüber dem Meeting-Support-System Living Agendas (LA) bereits vorliegende Daten zum Meeting abfragen und diese in der Anwendung darstellen kön­nen. Darüber hinaus sollen die im Folgenden dargestellten Prozesse und Workflows implementiert werden, die eine gezielte Bedienung von LA durch SL ermöglichen.

Eine der zentralen Aufgaben von SL ist die Unterstützung bei der Erstellung und Verwaltung von Wortmeldungen. Teilnehmer sollen die Möglichkeit haben, Sprechwünsche zu Agendapunkten, zu Aufgaben oder allgemeinen Anlässen über die Applikation (kurz App genannt) anzumelden. Diese werden dann durch den Moderator genehmigt oder abgewiesen. Zu den weiteren Aufgaben zählen die Visualisierung des Meeting-Fortschritts und die Darstellung der Agenda und möglicher weiterer Informationen wie z.B. Detailinformationen zu einem Teilnehmer.

1.3 Übersicht über die folgenden Kapitel der Arbeit

Die vorliegende Arbeit gliedert sich wie folgt: Kapitel 2 Grundlagen spezifiziert die zentralen Begriffe Besprechung, elektronisches Meeting System und Gruppenwahrnehmung und stützt sich hierbei auf die Definitionen und Vorgaben verschiedenerwissenschaftlicherArbeiten.

In Kapitel 3 Anforderungsanalyse werden die funktionalen und technischen Anforderungen erarbei­tet, die aus der Aufgabenstellung hervorgehen. Anschließend wird mittels konkreter Szenarien der Einsatz von SL beschrieben. Daraus werden konkrete Anforderungen an die Applikation SL und die

Schnittstelle zu LA abgeleitet und die involvierten Akteure identifiziert. Abschließend findet eine Visualisierung der Prozesse je Akteur in Form eines Anwendungsfalldiagramms statt. In Kapitel 4 Stand der Forschung werden die EMS-Systeme GroupSystems ThinkTank und Cisco vorgestellt und deren Ansätze in Bezug auf die gemachten Anforderungen analysiert. In Kapitel 5 wird auf Basis des Anforderungskatalogs ein konkretes Lösungskonzept erarbeitet. Anschließend behandelt Kapitel 6 ausgewählte Implementierungsdetails. Hier werden neben der Softwarearchitektur von LA und SL eingesetzte Fremdbibliotheken und ein konkretes Implementierungsdetail aus SL vorgestellt. Das Fazit in Kapitel 7 fasst die wichtigsten Anforderungen und Erkenntnisse noch einmal zusammen und gibt einen Ausblick für mögliche zukünftige wissenschaftliche Arbeiten in diesem Bereich.

2 Grundlagen

ln diesem Kapitel werden die grundlegenden Begriffe erläutert und definiert, die für das Verständnis der vorliegenden Arbeit und den Anforderungen an die Applikation SL von Bedeutung sind. Im ersten Schritt erfolgt die Definition und Klassifikation des Begriffs Meeting. Anschließend wird das für CSCW-Anwendungen zentrale Konzept der Awareness ausführlich behandelt. Nach einer Auseinan­dersetzung mit dem Forschungsgebiet der elektronischen Meeting Systeme wird im letzten Abschnitt die iOS Architektur vorgestellt.

Um eine spätere Referenzierung im Text zu ermöglichen, werden Methoden, Werkzeuge und weite­re wichtige Elemente mit G und einer fortlaufenden Nummer versehen (z.B. [G10]).

2.1 Besprechung (Meeting)

2.1.1 Begriffserklärungen

Der englischsprachige Begriff „Meeting" wird im Oxford Dictionary[1] definiert als „an assembly of people, esp. the members of a society or committee, for discussion or entertainment" und kann als Sitzung, Besprechung oder Zusammenkunft in die deutsche Sprache übersetzt werden. In Unter­nehmen wird jedoch regelmäßig auf den englischsprachigen Ausdruck zurückgegriffen: „In der Ar­beitswelt wird der Begriff Meeting beinahe inflationär für jede Besprechung benutzt" (Duden 2001).

Nach (Motzel 2006) ist die Besprechung definiert als die „Zusammenkunft von mehreren projektbe­teiligten Personen oder Personengruppen mit dem Ziel der gegenseitigen Information, der gemein­samen Erörterung eines bestimmten Themas und/oderderlösung eines Problems."

Nach (Post, Huis in't Veld und van den Boogaard 2006) sind Meetings keine isolierten Vorhaben, sondern zyklischer Natur. Sie gehen für gewöhnlich individueller Arbeit wie z.B. Vorbereitungen für das nächste Meeting, Verteilung von Ergebnissen und die Ausführung von Aktionen, die zuvor abge­stimmt wurden, voraus und werden so lange wiederholt, bis das übergeordnete Ziel erreicht ist.

2.1.2 Meeting-Phasen

Meetings lassen sich prinzipiell in die Phasen Pre-Meeting, In-Meeting und Post-Meeting aufteilen. Ausgehend vom Pre-Meeting, also den vorbereitenden Maßnahmen, in denen Termine festgesetzt, Ressourcen geblockt und Termineinladungen versendet werden, folgt in der In-Meeting-Phase die eigentliche Meeting-Durchführung, die wieder in einzelne Phasen zerlegt werden kann (vgl. Tabelle 2-1). Abschließend folgt die Post-Meeting-Phase, in der die Nachbereitung stattfindet, also z.B. Be- richte angefertigt und verteilt werden. Die soeben vorgestellten Phasen werden nachfolgend detail­liert behandelt.

2.1.2.1 Pre-Meeting

Zur erfolgreichen Durchführung eines Meetings sind vorbereitende Maßnahmen erforderlich. Einen beispielhaften Ablauf stellt (Teufel, et al. 1995) dar:

- [G30] Bei der Terminfestsetzung muss ein für alle Teilnehmer passender Zeitpunkt gewählt werden. Hierfür eignen sich elektronische Kalender wie z.B. Microsoft Outlook, die eine effi­ziente Unterstützung bieten.
- [G31] Die Ressourcenreservierung behandelt das Buchen von Räumen, Projektoren oder an­deren für das Meeting erforderlichen Ressourcen.
- [G32] Die Sitzungseinladung umfasst im Regelfall alle erforderlichen Informationen zum Meeting wie Datum, Uhrzeit, Ort und Agenda. Auch hier unterstützt ein Personal Informati­on Manager wie Microsoft Outlook, über das Planungs- und Einladungswerkzeuge zur Ver­fügung gestellt werden.
- [G33] Unter Umständen werden in einer Vordiskussion einzelne Punkte der Tagesordnung vordiskutiert oder die Agenda abgestimmt und angepasst.
- [G34] Das Meeting ist die eigentliche Durchführung der Sitzung.

2.1.2.2 In-Meeting

(Prudix und Goemer 2010) stellen folgende Bedingungen an ein erfolgreiches Meeting : „Bei jeder Form einer Besprechung sollte der Leiter sich ganz genau darüber im Klaren sein, was der eigentli­che Anlass für das Meeting ist und welches Ziel sie haben, bzw. welches Ergebnis erreicht werden soll."Um diesen Anforderungen gerecht zu werden, ist neben einer gründlichen Vorbereitungsphase, wie sie in 2.1.2.1 beschrieben wird, auch eine klare Struktur der eigentlichen Meeting-Durchführung erforderlich. (Prudix und Goerner 2010) unterteilen zu diesem Zweck die In-Meeting-Phase in weite­re Abschnitte, um so ein gemeinsames Zielverständnis zu entwickeln und Ergebnisse durch eine konkrete Aufgabenverteilung zu sichern.

In der ersten Spalte findet sich der Name des Abschnitts gefolgt von der Fragestellung, in der letzten Spalte werden Aufgaben aufgelistet, die im Rahmen der Phase erörtert und beantwortet werden sollten. Abhängig vom jeweiligen Besprechungstyp (s.a. 2.1.3) sollte die Phasenplanung entspre­chend angepasst werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1 - Phasen der Gesprächsdurchführung

2.1.2.3 Post-Meeting

(Teufel, et al. 1995) sieht nach Abschluss der In-Meeting-Phase eine Nachbereitung des Meetings vor. Außerdem können vertagte oder noch nicht vollständig abgeschlossene Agendapunkte ermittelt und für Folgemeetings vorgesehen werden.

- [G35] Die Nachbearbeitung behandelt die Protokollerstellung und Verteilung, welche auto­ matisch erfolgt oder nachträglich erstellt wird.

2.1.3 Werkzeuge

In der Literatur, u.a. auch in (Schwabe, Streitz und Uland 2001) und (Hornung und Patzak 2009), finden sich eine Vielzahl an Techniken, die bei der Durchführung in der In-Meeting-Phase Anwen­dung finden können. Nachfolgend wird eine Auswahl an Werkzeugen aufgelistet:

- [G10] Die Agenda dient der Strukturierung eines Meetings, stellt die Tagesordnungspunkte dar und listet die jeweils benötigten Werkzeuge auf.
- [G11] Brainstorming ist eine Kreativitätstechnik und dient der Erzeugung von neuen, origi­nellen oder auch „verrückten" Ideen im Team.
- [G12] Bei der Kategorisierung oder auch Organisation werden die (zuvor im Brainstorming gesammelten) Beiträge durch die Teilnehmer zu (frei wählbaren) Kategorien gruppiert (Clustering).
- [G13] Bei der Abstimmung bewerten Teilnehmer eine Auswahl von Beiträgen und vergeben Punkte, legen eine Reihenfolge fest oder schließen aus.
- [G14] Die Alternativanalyse umfasst die Ausarbeitung und Bewertung eines alternativen Vorgehens.
- [G15] Berichte dienen der Sicherung des Besprechungsergebnisses und formulieren in schriftlicher Form Ergebnisse, kontroverse Diskussionen und Aufgabenverteilung.

2.1.4 Besprechungstypen

Eine Besprechung kann je nach Zweck, Teilnehmerkreis, Thema und Interessenslage spezifisch aufge­setzt werden. (Schümmer 2011) listet folgende Besprechungstypen auf, wobei diese auch kombiniert werden können:

- [G20] Bei einem Problemlösungs-Meeting (Problem Solving) trifft sich eine Gruppe von Menschen, um eine Lösung für ein spezifisches Problem zu erarbeiten.
- [G21] Das Ziel eines Entscheidungs-Meeting (Decision Making) ist das Erreichen einer finalen Entscheidung für zukünftige Aktivitäten.
- [G22] Bei einem Planungs-Meeting (Planning Meetings) erarbeitet die Gruppe Maßnahmen für die Lösung eines Problems in der Zukunft.
- [G23] Bei einem Berichts- und Präsentations-Meeting (Reporting's and Presenting) werden die Teilnehmer über ein spezifisches Thema informiert.
- [G24] Das Reaktions- und Evaluations-Meeting (Reacting and Evaluating) dient dem gegen­seitigen Austausch zwischen den Teilnehmern zu ihrer Arbeit oder ihren Aktivitäten.
- [G25] Führungslose Meetings (Leaderless Meetings) finden beispielsweise auf Cocktail Par­tys statt.

2.2 Gruppenwahrnehmung (Awareness)

2.2.1 Begriffserklärungen

Der Begriff Awareness wird meist im Zusammenhang mit Groupware erwähnt. Unter Groupware versteht (Teufel, et al. 1995) „Software, welche im Rahmen von CSCW entsteht. (...) CSCW- Applikationen sind aus Software und eventuell spezifischer Hardware bestehende Systeme, durch die Gruppenarbeit unterstützt oder ermöglicht wird." Groupware kann nach unterschiedlichen Kriterien klassifiziert werden, zwei mögliche Ansätze werden in Abschnitt 2.2.3 beschrieben.

Zu den zentralen Anforderungen von Groupware-Anwendungen gehört das Konzept der Awareness. Im Oxford Dictionary[2] wird der Begriff definiert als „knowledge or perception of a situation or fact", also der Kenntnis oder Wahrnehmung von einer Situation oder einer Tatsache. (Endsley 1995) stellt den Begriff ganz einfach und salopp dar als „knowing whatisgoing on".

Der englischsprachige Begriff Awareness wird von (PONS 2011) als „Bewusstsein" übersetzt. (Schwabe, Streitz und Uland 2001) sehen bei der Verwendung des Begriffs die Gefahr, dass er im Zusammenhang mit CSCW-Anwendungen missverstanden wird: „Es ist ja nicht das Ziel, ein Bewusst­sein zu erzielen, sondern eine Wahrnehmung des kooperativen Geschehenes und der Aktivitäten in der Gruppe. Man kann das Phänomen daher am ehesten mit den Begriffen Gruppenwahrnehmung oder Geschehenswahrnehmung bezeichnen."

Ein regelmäßig verwendetes Zitat zur Definition der Gruppenwahrnehmung findet sich in (Dourish und Bellotti 1992): "Awareness is an understanding of the activities of others, which provides a context for our own activity." Der Kontext der eigenen Aktivitäten wird also von den aktuellen und rückblickenden Aktivitäten der Kooperationspartner der Anderen ausgerichtet und „dient zur Re­duktion von Unsicherheit und zur spontanen Koordination" (Gross und Koch 2007). Hierdurch las­sen sich nach (Schwabe, Streitz und Uland 2001) Missverständnisse, Abstimmungs- und Synchronisa­tionsprobleme vermeiden. „Es ist also erforderlich, den Benutzern von Groupware auch die Aktivi­täten anderer an einem Prozess oder einer Aktivität beteiligten Partner zu vermitteln, um so eine Wahrnehmung dergesamtenAktivitäten zu erzielen."

Gruppenwahrnehmung scheint also ein wichtiger Faktor für die Effektivität von Groupware zu sein: „Sie ist zentraler Bestandteil für erfolgreiche und effiziente soziale Interaktion." (Gross und Koch 2007)

2.2.2 Arten der Awareness-Informationen

(Gutwin 1997) unterscheidet vier Arten der Gruppenwahrnehmung, die an dieser Stelle vorgestellt werden sollen:

- [G50] Die informelle Awareness gibt Aufschluss darüber, welche Teilnehmer verfügbar sind und wie diese im realen Leben und im elektronischen Raum erreicht werden können.
- [G51] Bei der sozialen Awareness werden die Informationen geliefert, die in sozialen Syste­men eine Rolle spielen und im persönlichen Gespräch über Gesichtsausdruck, Augenkontakt oder Körpersprache zwischen den Teilnehmer wahrgenommen werden.
- [G52] Die Awareness über die Gruppenstruktur gibt Aufschluss über Verantwortlichkeiten, Rollen, Status und Positionen der Teilnehmer in CSCW-Systemen.
- [G53] Die Awareness über den Arbeitsbereich repräsentiert die Interaktion der Teilnehmer innerhalb des gemeinsamen Arbeitskontextes. Hierunter fallen u.a. Präsenz, Ort, Aktivitäts­niveau, Aktionen, Absichten und Veränderungen.

Bei der synchronen Zusammenarbeit „sollten alle Ereignisse, die für die Kooperationspartner rele­vant sind, möglichst zeitgleich vermittelt werden, damit es nicht zu Zugriffskonflikten kommt" (Gutwin 1997).

2.2.3 Klassifikation von Groupware

Es existieren verschiedene Ansätze, Groupware-Anwendungen zu klassifizieren. Im folgenden Ab­schnitt werden zwei Klassifikationsschemata vorgestellt. Die Raum-Zeit-Matrix unterscheidet Syste­me aufgrund Zeit und Ort der Interaktion, wohingegen das 3-K-Modell aufgrund der Zielgrößen Kommunikation, Koordination und Kooperation eine Klassifizierung definiert.

2.2.3.1 Raum-Zeit-Matrix

Die Raum-Zeit-Matrix nach Johansen klassifiziert Groupware nach dem Aspekt, wo und wann die Gruppenmitglieder miteinander interagieren: „Die Unterscheidung erfolgt dabei bezüglich der geo­graphischen Verteilung der Beteiligten (benachbart oder entfernt) und der zeitlichen Verteilung derBeteiligten (synchron bzw. asynchron)."(Teufel, et al. 1995).

Die folgende Abbildung klassifiziert verschiedene Groupware-Anwendungen im Raum-Zeit-Gefüge.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1 - Raum-Zeit-Matrix nach Johansen (Teufel, et al. 1995)

2.2.3.2 3-K-Modell

Das 3-K-Modell oder auch das Klassifikationsschema nach Unterstützungsfunktionen untersucht Groupware Funktionalitäten nach den drei Bereichen Kommunikation, Koordination und Kooperati- on. (Gross und Koch 2007) beschreibt das Modell wie folgt: „Die Kommunikation bezieht sich pri­mär auf das gegenseitige Verstehen von Personen durch den Austausch von Informationen. Koor­dination zielt auf das Finden des besten Weges für das Arrangement von aufgabenorientierten Tätigkeiten und die Allokation von Ressourcen ab. Kooperation schließlich beinhaltet ein gemein­sames Ziel und normalerweise die Arbeit an gemeinsamen Artefakten.“

Die Unterstützungsfunktion lassen sich in folgende Systemklassen aufteilen:

- Kommunikation
- Gemeinsame Informationsräume
- Workflow Management
- Workgroupcomputing

Die folgende Abbildung stellt dar, wie die verschiedenen Applikationstypen in Bezug auf die drei Zielgrößen Kommunikation, Koordination und Kooperation positioniert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2 - Klassifikationsschema nach Unterstützungsfunktionen (Teufel, et al. 1995)

2.3 Elektronisches Meeting System (EMS)

Elektronische Meeting Systeme sind ein Teilgebiet der CSCW-Forschung (Schwabe, Streitz und Uland 2001) und als Oberbegriff für die in dieser Arbeit behandelten Softwareprodukte LA und SL zu ver­stehen. Die Begrifflichkeiten, Mechanismen und eingesetzten Techniken von EMS sollen in diesem Abschnitt intensiv diskutiert werden. Eine Auswahl von Systemen wird in Kapitel 4 vorgestellt.

2.3.1 Begriffserklärungen

In der Literatur findet sich bis zum heutigen Zeitpunkt kein einheitlicher Begriff für die computerun­terstützte Durchführung von Meetings. In der Forschung werden Begriffe wie (Group) Decision Sup­port System, Computer Aided Team oder auch Electronic Meeting Systems verwendet.

(Teufel, et al. 1995) klassifiziert CSCW-Anwendungen in die Systemklassen Kommunikation, gemein­same Informationsräume, Workflow Management und Workgroup Computing. Im Teilbereich Kom­munikation werden Konferenzsysteme vorgestellt. Sie „unterstützen eine genau adressierbare Men- gevon Kommunikationspartnern, die zurgleichenZeitmiteinander kommunizieren wollen."

Im Kontext des Workgroup Computing werden Entscheidungsunterstützungssysteme (Decision Sup­port Systems, DSS) vorgestellt. Es handelt sich dabei um Systeme „zur Unterstützung teilweise strukturierbarer Aufgaben.". (Morton 1978) erklärt DSS wie folgt: „Decision Support Systems (DSS) represent a point of view on the role of the computer in the management decision making process. Decision support implies the use of computers to: 1. assist managers in their decision processes in semi structured tasks, 2. support, rather than replace, managerial judgment. 3. Improve the effec­tiveness ofdecision making rather than its efficiency."

Eine Weiterentwicklung von DSS stellt das Group Decision Support System (GDSS) dar, welches Ent­scheidungsfindungen in Gruppen unterstützt, da viele Entscheidungen in Gruppen ablaufen (Kremar 193).

(Kremar 193) spricht in seinem Forschungsansatz von ComputerAided Team (CATeam) und sieht den Nutzen in „der Verbesserung der Teamproduktivität und Gruppen-Zusammenarbeit durch die Un­terstützung mitHilfe von Kommunikations- und Informationstechnologien".

Im Rahmen dieser Arbeit werden die Begriffe Elektronisches Meeting System (Electronic Meeting System) oder Sitzungsunterstützungssystem verwendet. Es besteht nach (Teufel, et al. 1995) aus „einer Sammlung von Einzelplatzapplikationen, welche Gruppenprozesse im Rahmen von Sitzun­gen unterstützen" und beschreibt am ehesten ein System zur Unterstützung von zeitgleicher Arbeit an einem Ort (Schwabe, Streitz und Uland 2001).

(Dennis, et al. 1988) sieht in EMS einen höheren Nutzen als in GDSS: „EMS are more than group decision support systems (GDSS): they support more tasks than just decision making: they focus on communication". Dies wird durch (Schwabe, Streitz und Uland 2001) unterstützt, demnach liegen die Stärken von EMS in der „Verstärkung von positiven Effekten" und zur „Vermeidung von negati­ven Effekten". Die verwendeten Werkzeuge sind Methoden aus der Kommunikationsunterstützung oder Prozessstrukturierung. Diese werden im anschließenden Abschnitt 2.3.2 vorgestellt.

Nach (Teufel, et al. 1995) kann im Bereich der Sitzungsunterstützungssysteme zwischen Systemen für die Ablaufplanung (vgl. 2.1.2) und Systemen für die eigentliche Durchführung / Unterstützung unterschieden werden. In der zweiten Kategorie wird zwischen „vor Ort" (im gleichen Raum) oder „verteilt,, (z.B. durch Videokonferenzen) unterschieden.

2.3.2 Sitzungsunterstützung durch EMS

Laut (Schwabe, Streitz und Uland 2001) verändert EMS „die Möglichkeiten der Teilnehmer, mitei­nander zu kommunizieren, den Sitzungsprozess zu strukturieren und Informationen in der Sitzung zu verarbeiten". Ähnlich betrachtet dies (Nunamaker, et al. 1991): „There are at least four theoreti­cal mechanisms by which the EMS can affect this balance of gains and losses: process support, pro- cessstructure, taskstructure, and tasksupport.".

Im folgenden Abschnitt sollen die Mechanismen von Sitzungsunterstützungssystemen vorgestellt werden. Deren Spezifikationen finden sich u.a. in (Schwabe, Streitz und Uland 2001) und (Nunamaker, et al. 1991):

- [G40] In der Kommunikationsunterstützung (Process Support) wird auf verschiedene Kom­munikationswerkzeuge zurückgegriffen, die die Kommunikation unter Gruppenmitgliedern erleichtert. Hierzu gehören z.B. der Einsatz paralleler oder anonym ablaufender Kommuni­kation oder die Unterstützung von Abstimmungen zur Entscheidungsfindung in (größeren) Gruppen.
- [G41] Bei der Prozessstrukturierung (Process Structure) unterstützt das EMS z.B. bei der Festlegung und Durchführung eines Meetings, in dem eine definierte Folge von Aktivitäten durchlaufen wird. Zum einen ermöglicht sie die Planung und Durchführung einer vorge­schriebenen Folge von Tagesordnungspunkten. Zum anderen offeriert sie verschiedene Werkzeuge (vgl. Abschnitt 2.1.3) je Phase, die ein strukturiertes Vorgehen der Teilnehmer erfordern. Einen weiteren Aspekt der Prozessstrukturierung findet sich in der automati­schen Dokumentation des Sitzungsprozesses.
- [G42] Die Informationsverarbeitung (Task Structure, Task Support) gehört zu den zentralen Leistungen von EMS. Beiträge können elektronisch erfasst und ausgewertet und so in ande­ren Phasen weiterverwendet werden. Hierzu gehört auch die Bereitstellung von Informatio­nen aus vorherigen Meetings, die für die Weiterarbeit nützlich sein könnten.

2.4 Technische Grundlagen

In den technischen Grundlagen wird das Schichtenmodell der iOS Architektur vorgestellt, weil der in der vorliegenden Abschlussarbeit zu entwickelnde Prototyp auf Basis von iOS realisiert werden muss. Anschließend erfolgt eine Einführung in die Entwicklungsumgebung Xcode und Präsentation wichti­ger Cocoa Design Patterns.

2.4.1 iOSArchitektur

In diesem Abschnitt wird das Schichtenmodell der iOS Softwarearchitektur vorgestellt.

Apple unterteilt die in iOS enthaltenen Technologien in die vier Schichten Core OS, Core Services, Media und Cocoa Touch (vgl. Abbildung 2-3). Auf den unteren Ebenen befinden sich die Low-Level- Dienste, die die Grundlage für alle Applikationen darstellen. Die höheren Ebenen auf dem Stapel, hierzu gehören Media und Cocoa Touch, stellen objektorientierte Abstraktionen für die unterliegen­den Schichten bereit und bieten die Möglichkeit, die von Apple entwickelten Komfortfunktionen zu nutzen: „Higher-level layers contain more sophisticated services and technologies.“ [3] . Die folgende Abbildung ist dem iOS Technology Overview[4] entnommen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3 - Apple iOS System Layer[5]

Im Folgenden werden ausgewählte Bausteine innerhalb der einzelnen Schichten vorgestellt, um den Aufbau und die Funktionalitäten der einzelnen Schichten etwas genauer darzustellen. Als Informati­onsquelle dient, sofern nicht anders erwähnt, (Koller 2011).

2.4.1.1 Cocoa Touch

Cocoa Touch stellt die Basis für einen Großteil an Funktionalität bereit, die für die Entwicklung von Anwendungen für die mobilen Endgeräte von Apple erforderlich ist. Zu den Bausteinen gehören u.a. AdressBook UI Framework, Notification Services (APN), Event Kit UI Framework, Map Kit Framework oder auch das Game Kit.

UIKit-Framework

Das UIKit Framework wurde für mobile Endgeräte komplett neu entwickelt und stellt das Gegenstück zum AppKit-Framework dar, welches in der Mac-Desktop-Entwicklung eingesetzt wird. Das UIKit- Framework verantwortet alle grafischen Aspekte der Applikation, hierzu gehören:

- UserInterface
- MultiTouch-Verhalten
- Screen Rotation
- View Controller
- Events
- Gesten
- Drucken

Den im UlKit enthaltenen Klassennamen wurde zur verbesserten Wiedererkennung der Präfix ui vorangestellt und steht als Akronym für User Interface.

2.4.1.2 Media

Der Media-Layer bietet Technologien für Grafik, Audio und Video.

Core Animation

Core Animation ist bereits in vielen Komponenten des UlKit-Frameworks enthalten und steuert die Animationen, die z.B. bei der Auswahl eines Elementes oder View-Wechsel ausgelöst werden. Der Entwickler kann an verschiedenen Stellen hierfür das Animated-Flag auf yes setzen oder eigene visuelle Effekte realisieren.

2.4.1.3 Core Services

Zu den Core Services zählt Apple alle Systemservices, die von allen Anwendungen direkt oder indi­rekt verwendet werden, hierunter fallen das Adressbuch, Core Location, Core Telephony oder das Event Kit.

Core Data

Bei Core Data handelt es sich um ein Persistenz-Framework, das genutzt werden kann, um Daten lokal zu speichern. Dabei werden auch die benötigten Datenobjekte zur Verfügung gestellt, die an­dernfalls als zusätzliche Klassen zur Verfügung gestellt werden müssen.

Foundation-Framework

Mit dem Foundation-Framework werden grundlegende Basisklassen bereitgestellt, die für die Mac- und iPhone/ iPad-Entwicklung notwendig sind. Hierunter fallen z.B. das Erstellen und Bearbeiten von Strings über die Klasse NSString oder die Arbeit mit Arrays durch die Klasse NSArray. Allen Klassen dieses Frameworks wurde das Präfix NS vorangestellt, welches für NextStep steht.

2.4.2 Xcode Entwicklungsumgebung

Die Entwicklung von Software für Apple Hardware wie z.B. iPhone, iPad und Mac Desktop Computer erfordert eine Mac OS X Betriebsumgebung, die wiederum auch den Besitz von Apple Desktop Hardware voraussetzt. Als integrierte Entwicklungs­umgebung (IDE) kommt die Entwicklungssuite Xcode zum Einsatz. Zu den Anwendungen, die für die iOS-Entwicklung notwendig ist, zählen neben Xcode noch die Applikationen Interface Builder und Instruments.

Mit Interface Builder stellt Apple eine Anwendung bereit, mit der die grafische Er­stellung einer Benutzerschnittstelle ermöglicht wird. Actions (Methoden in der Controller-Klasse) und Outlets (Objekte, die in der Controller-Klasse definiert wer­den) können in dieser Anwendung per Mausklick verbunden werden.

Instruments ist ein Werkzeug, mit dem Anwendungen im Detail analysiert werden können. So kann über diese Anwendungen z.B. der Speicherverbrauch und damit verbundene Leaks untersucht werden. Dies ist erforderlich, da der aus dem Java Umfeld bekannte Garbage Collector bei der IPhone und ¡Pad-Entwlcklung nicht existiert und diese Aufgabe in die Hände des Programmierers gegeben wird.

2.4.3 Cocoa Design Patterns

Cocoa ist nach (Koller 2011) „für die Verwendung im Sinne eigener Patterns konzipiert, sodass eine Entwicklung ohne diese praktisch nicht möglich (...) isť'. Einer entsprechenden Kenntnis über die verschiedenen Design Patterns vorausgesetzt, ermöglicht sie bei möglichen Problemen in der Ent­wicklung mit praktischen Lösungswegen zu begegnen: „Design Patterns describe high quality prac­tical solutions to recurring programming problems. Design patterns don't require amazing pro­gramming tricks. They're a toolbox of reusable solutions and best practices (...)". (Buck und Yacktman 2009)

Zu den Design Patterns, die bei der Implementierung von SL vornehmlich eingesetzt wurden, gehö­ren das MVC-Pattern, Delegation und Target Action, diese werden nachfolgend beschrieben.

2.4.3.1 Model View Controller

Das Model View Controller-Pattern (MVC) gehört zu den populärsten Mustern und ist in vielen Berei­chen der Softwareentwicklung integraler Bestandteil in der Umsetzung. Die Idee ist, dass der Code in seine verschiedenen funktionalen Bereiche unterteilt wird und so weniger fehler- und wartungsan­fällige Veränderungen im Programcode zulässt: „The primary purpose of MVC is to decouple the Model subsystem from the views so that each can change independently“ (Buck und Yacktman 2009).

Das MVC-Pattern gliedert sich in die folgenden drei Bereiche:

- Model: Repräsentation des zugrundeliegenden Datenmodells
- View: Visualisierung der Daten und Entgegennahme von Nutzereingaben über Buttons, Textfeldern usw.
- Controller: Verantwortung von Steuerung und Ablauf der Anwendung

In der folgenden Abbildung wird das Zusammenspiel der drei Bereiche deutlich. Sowohl die View als auch das Model kommunizieren nie direkt miteinander, sondern nutzen den Controller, um auf Ver­änderungen hinzuweisen oder auf Updates zu reagieren.

[...]


[1] http://www.oxforddictionaries.com/(Zugriff am 08.04.2011)

[2] http://www.oxforddictionaries.com/(Zugriff am 08.04.2011)

[3] http://developer.apple.com/library/ios/#DOCUMENTATION/Miscellaneous/Conceptual/iPhoneOSTechOverview/IPhoneO SOverview/IPhoneOSOverview.html (Zugriffam 10.06.2011)

[4] http://developer.apple.com/library/ios/#DOCUMENTATION/Miscellaneous/Conceptual/iPhoneOSTechOverview/IPhoneO SOverview/IPhoneOSOverview.html (Zugriffam 10.06.2011)

[5] http://developer.apple.com/library/ios/#DOCUMENTATION/Miscellaneous/Conceptual/iPhoneOSTechOverview/IPhoneO SOverview/IPhoneOSOverview.html (Zugriffam 10.06.2011)

Fin de l'extrait de 68 pages

Résumé des informations

Titre
Konzeption und Implementierung einer iPad Applikation für ein Meeting-Support-System
Université
University of Hagen  (Praktische Informatik)
Note
1,3
Auteur
Année
2011
Pages
68
N° de catalogue
V206918
ISBN (ebook)
9783656340560
ISBN (Livre)
9783656340645
Taille d'un fichier
2891 KB
Langue
allemand
Mots clés
Meeting Support System, CSCW, ipad, Meeting, Gruppenwahrnehmung, Awareness, Elektronisches Meeting System, EMS
Citation du texte
Timo Mueller (Auteur), 2011, Konzeption und Implementierung einer iPad Applikation für ein Meeting-Support-System, Munich, GRIN Verlag, https://www.grin.com/document/206918

Commentaires

  • Pas encore de commentaires.
Lire l'ebook
Titre: Konzeption und Implementierung einer iPad Applikation für ein Meeting-Support-System



Télécharger textes

Votre devoir / mémoire:

- Publication en tant qu'eBook et livre
- Honoraires élevés sur les ventes
- Pour vous complètement gratuit - avec ISBN
- Cela dure que 5 minutes
- Chaque œuvre trouve des lecteurs

Devenir un auteur