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.
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 Versenden 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 werden. 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ützungssysteme dar. Diese Systeme bieten einen vielversprechenden Ansatz, da mit ihrer Hilfe die bekannten Werkzeuge und Methoden programmatisch umgesetzt und erforderliche Workflows für die Prozessstrukturierung bereitgehalten werden. Diese können im Rahmen einer Besprechung gezielt eingesetzt 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 executive 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 Diskussionsforen 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ühren 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 bekannt 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 Wortmeldungen 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 Wortmeldungen 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 zugegriffen werden kann.
SL soll Werkzeuge und Techniken zur Verfügung stellen, die die Teilnehmer und den Moderator während 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önnen. 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 erarbeitet, 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 Auseinandersetzung 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 weitere 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 Unternehmen wird jedoch regelmäßig auf den englischsprachigen Ausdruck zurückgegriffen: „In der Arbeitswelt 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 projektbeteiligten Personen oder Personengruppen mit dem Ziel der gegenseitigen Information, der gemeinsamen 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 abgestimmt 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 detailliert 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 effiziente Unterstützung bieten.
- [G31] Die Ressourcenreservierung behandelt das Buchen von Räumen, Projektoren oder anderen 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 Information Manager wie Microsoft Outlook, über das Planungs- und Einladungswerkzeuge zur Verfü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 eigentliche 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 weitere 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 entsprechend 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 Anwendung 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, originellen 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 aufgesetzt 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 gegenseitigen Austausch zwischen den Teilnehmern zu ihrer Arbeit oder ihren Aktivitäten.
- [G25] Führungslose Meetings (Leaderless Meetings) finden beispielsweise auf Cocktail Partys 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 Bewusstsein 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 Reduktion von Unsicherheit und zur spontanen Koordination" (Gross und Koch 2007). Hierdurch lassen sich nach (Schwabe, Streitz und Uland 2001) Missverständnisse, Abstimmungs- und Synchronisationsprobleme vermeiden. „Es ist also erforderlich, den Benutzern von Groupware auch die Aktivitä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 Systemen 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ätsniveau, Aktionen, Absichten und Veränderungen.
Bei der synchronen Zusammenarbeit „sollten alle Ereignisse, die für die Kooperationspartner relevant 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 Abschnitt werden zwei Klassifikationsschemata vorgestellt. Die Raum-Zeit-Matrix unterscheidet Systeme 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 geographischen 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 primär auf das gegenseitige Verstehen von Personen durch den Austausch von Informationen. Koordination 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 gemeinsames 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 verstehen. 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 computerunterstützte Durchführung von Meetings. In der Forschung werden Begriffe wie (Group) Decision Support System, Computer Aided Team oder auch Electronic Meeting Systems verwendet.
(Teufel, et al. 1995) klassifiziert CSCW-Anwendungen in die Systemklassen Kommunikation, gemeinsame Informationsräume, Workflow Management und Workgroup Computing. Im Teilbereich Kommunikation 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 Support 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 effectiveness ofdecision making rather than its efficiency."
Eine Weiterentwicklung von DSS stellt das Group Decision Support System (GDSS) dar, welches Entscheidungsfindungen 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 Unterstü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 Sitzungen 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 negativen 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, miteinander 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 theoretical 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 Kommunikationswerkzeuge zurückgegriffen, die die Kommunikation unter Gruppenmitgliedern erleichtert. Hierzu gehören z.B. der Einsatz paralleler oder anonym ablaufender Kommunikation 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 vorgeschriebenen 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 automatischen 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 anderen Phasen weiterverwendet werden. Hierzu gehört auch die Bereitstellung von Informationen 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 wichtiger 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 unterliegenden 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 Informationsquelle 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 indirekt 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 andernfalls 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 Entwicklungsumgebung (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 Erstellung einer Benutzerschnittstelle ermöglicht wird. Actions (Methoden in der Controller-Klasse) und Outlets (Objekte, die in der Controller-Klasse definiert werden) 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 Entwicklung mit praktischen Lösungswegen zu begegnen: „Design Patterns describe high quality practical solutions to recurring programming problems. Design patterns don't require amazing programming 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 Bereichen 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 wartungsanfä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)
- Arbeit zitieren
- Timo Mueller (Autor:in), 2011, Konzeption und Implementierung einer iPad Applikation für ein Meeting-Support-System, München, GRIN Verlag, https://www.grin.com/document/206918
