36,99 €
Diplomarbeit aus dem Jahr 2002 im Fachbereich Informatik - Wirtschaftsinformatik, Note: 1,1, Duale Hochschule Baden-Württemberg, Lörrach, früher: Berufsakademie Lörrach (Ausbildender Betrieb, nicht Institut, da BA-Studium : Brain International AG), Sprache: Deutsch, Abstract: Dieses Buch beschäftigt sich mit dem Thema "Konzeption & Realisierung eines komponentenbasierten Projektinformationssystems mit Hilfe von Open Source-Software". Im Fokus steht dabei ein neu entwickeltes Projektinformationssystem für die Enterprise Modeling Group (EMG) der BRAIN International AG. Dieses System baut auf bereits vorhandene Open Source-Software auf. Da auf mehrere Open Source-Quellen zurückgegriffen werden musste und auch Eigenentwicklungen in die Realisierung mit einflossen, wurde von Anfang an eine komponentenorientierte Softwarearchitektur angestrebt. Es wird gezeigt, dass eine komponentenbasierte Architektur auf der Grundlage von Open Source eine stabile Basis zur Realisierung von Softwarelösungen darstellt. Außerdem liegt der Kernaspekt in der Begründung der Entwicklungsmethodik als eine sich in der Praxis bewährte Alternative.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Veröffentlichungsjahr: 2003
Page 1
Page 4
Vorwort
Die hier vorgelegte Diplomarbeit beschäftigt sich mit dem Thema „Konzeption & Realisierung eines komponentenbasierten Projektinformationssystems mit Hilfe von Open Source-Software“. Im Fokus steht ein neu entwickeltes Projektinformationssystem für die Enterprise Modeling Group (EMG) der BRAIN International AG. Dieses System baut auf bereits vor-handene Open Source-Software auf. Da auf mehrere Open Source-Quellen zurückgegriffen werden musste und auch Eigenentwicklungen in die Realisierung mit einflossen, wurde von Anfang an eine komponentenorientierte Softwarearchitektur angestrebt. Es wird gezeigt, dass eine komponentenbasierte Architektur auf der Grundlage von Open Source eine stabile Basis zur Realisierung von Softwarelösungen darstellt. Außerdem liegt der Kernaspekt in der Begründung der Entwicklungsmethodik als eine sich in der Praxis bewährte Alternative.
Die Ausarbeitung in dieser Diplomarbeit stellt die Konzeption in den Mittelpunkt. Dabei wird nicht nur im Hinblick auf das neue System argumentiert, sondern es werden auch die Randaspekte berücksichtigt, wie z. B. die nicht konkret formulierten Anforderungen. Auf die Realisierung des Systems wird nur insoweit eingegangen, wie deren Beschreibung der Begründung der Konzeption dient. Allerdings werden keine programmiertechnischen Grundlagen zum Verständnis verlangt, da von der technischen Seite her nicht sehr tief in die Thematik eingestiegen wird.
Für jedes große Theoriethema (Projektinformationssysteme, Open Source und Komponen-tenorientierte Softwareentwicklung) hätte vom Stoffumfang her eine eigene Diplomarbeit geschrieben werden können. Aufgrund der Vorgaben können einige Punkte nur kurz erläutert werden. Der interessierte Leser wird auf die weiterführenden Quellen verwiesen.
Ich danke allen Personen, die sich in irgendeiner Weise bei der Erstellung dieser Diplomarbeit beteiligt haben. Besonderer Dank geht an Herrn Prof. Uwe Busbach-Richard für seine vielfältigen Anregungen und an Thomas Neumann, der mir immer mit Rat und Tat zur Seite stand. Weiterhin sollen auch Heike Stegeman, Jochen Klumpp, Lucia Riesterer, Marcus Schauber, Tanja Bühler, Erwin Graf und last but not least Edna Böhler für ihre Unterstützung namentlich genannt werden.
Ihringen, den 26. August 2002
Thomas Bühler
Page 5
Seite 5 von 140 Abbildungsverzeichnis Abbildung 1 : Aufbau der Diplomarbeit....................................................................................14 Abbildung 2 : Informationssysteme nach dem Unterstützungsniveau....................................17 Abbildung 3 : Klassifizierung nach Raum und Zeit .................................................................19 Abbildung 4 : Das 3K - Modell .................................................................................................19 Abbildung 5 : Todesspirale ......................................................................................................21 Abbildung 6 : Veranschaulichung der Replikation ..................................................................23 Abbildung 7 : Einsatz von Open Source - Software in Unternehmen.....................................27 Abbildung 8 : Übersicht Softwarelizenzen...............................................................................33 Abbildung 9 : Erfolgsrate bei Software - Projekten .................................................................39 Abbildung 10 : Aufbau Wiederverwendung .............................................................................41 Abbildung 11 : Softwarekomponenten - Ein Baukasten..........................................................42 Abbildung 12 : Komponentenorientierte Softwareentwicklung ...............................................45 Abbildung 13 : Das Containermodell .......................................................................................49 Abbildung 14 : Auswertung der Evaluation .............................................................................57 Abbildung 15 : Die im Standard enthaltenen PHProjekt - Komponenten ...............................58 Abbildung 16 : PHProjekt im Originalzustand .........................................................................59 Abbildung 17 : Das Original Wiki .............................................................................................61 Abbildung 18 : The “4+1” View Model .....................................................................................63 Abbildung 19 : Physical View & Process View ........................................................................65Page 7
Abkürzungsverzeichnis
3K Kommunikation, Koordination, Kooperation AG Aktiengesellschaft AOL America Online API Application Programming Interface ASCII American Standard Code for Information Interchange ASCS Automotive Supply Chain Solutions AT&T American Telephone and Telegraph Company BASIC Beginners All purpose Symbolic Instruction Code BB Bulletin Board BSCW Basic Support for Cooperative Work BSD Berkeley Software Distribution CEO Chief Executive Officer CI Corporate Identity COM Component Object Model CORBA Common Object Request Broker Architecture CSCW Computer Supported Cooperative Work CSS Cascading Style Sheets CVS Concurrent Versioning System DCOM Distributed Component Object Model DIN Deutsches Institut für Normung / Deutsche Industrie-Norm DOC Document DMZ Demilitarized Zone / Demilitarisierte Zone EDV Elektronische Datenverarbeitung EMG Enterprise Modeling Group ERP Enterprise Ressource Planning ESIP Europäischen Software-Innovationspreises FA Funktionale Anforderung FSF Free Software Foundation FTP File Transfer Protocol FUD Fear, Uncertainty, Doubt GMD Gesellschaft für Mathematik und Datenverarbeitung GNU GNU is not UNIX GPL General Public License HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol
Page 8
IBM International Business Machines Corporation ID Identification IDL Interface Definition Language IP Internet Protocol ISM Informationssystem-Management ISO International Standardization Organisation IT Informationstechnik IuK Informations- und Kommunikationstechnologie J2EE Java 2 Plattform, Enterprise Edition JPEG Joint Photographic Experts Group KBSW Komponentenbasierte Softwareentwicklung KDE K Desktop-Environment LGPL Lesser General Public License MDA Model Driven Architecture MIT Massachusetts Institute of Technology NFA Nichtfunktionale Anforderung NSF Notes Storage Facility OMG Object Management Group OOP Objektorientierte Programmierung OSD Open Source-Definition OSS Open Source-Software OSI Open Source-Initiative OSI Open Systems Interconnection PDF Portable Document Format PHP PHP Hypertext Preprocessor PM Projektmanagement ProInfSys Projektinformationssystem SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung SCM Supply Chain Management SQL Structured Query Language SW Software TCO Total Cost of Ownership TCP Transmission Control Protocol UML Unified Modeling Language URL Uniform Resource Locator WWW World Wide Web
Page 11
In der heutigen Zeit haben sich zwei wesentliche Tendenzen in der operativen Geschäftswelt herauskristallisiert. Die erste besteht darin, dass es für jedes Unternehmen zunehmend erforderlich ist, ständig aktuelle Informationen über dessen Umfeld, in dem es sich bewegt, zur Verfügung zu haben. Nur wer „up-to-date“ ist, kann schnell am Markt agieren, flexibel reagieren und innovativ Erfolge erzielen. So hat sich die „Information“1mit zunehmendem Maße als erfolgsrelevante Ressource etabliert und wird sogar als „kritischer Faktor“ für den Unternehmenserfolg bewertet.2„Informationen gehören zum Input jedes Leistungserstellungsprozesses und prägen jedes wirtschaftliche Handeln und Entscheiden.“3Die „Information“ an sich wird als eigenständiger Produktionsfaktor betrachtet, der auch im Sinne eines wirtschaftlichen Gutes behandelt wird, und durch den Einsatz anderer Produktionsfaktoren4eigenständig erzeugt oder von außen bezogen werden kann.5
Die zweite Tendenz besteht darin, dass betriebliche Probleme immer häufiger in Form von Projekten gelöst werden. Diese haben sich besonders dann bewährt, wo die Lösung von Routineaufgaben im Unternehmen nicht im Vordergrund stand. Projektaufgaben sind daher immer „außerhalb der Linienarbeit“6anzusiedeln. Die Haltung der Unternehmen zur Lösung betrieblicher Probleme hat sich deutlich mit der Zeit gewandelt. Während früher das starre Verharren in der Linienorganisation dominierte, wird heute eher der dynamische Charakter eines Projektes präferiert.7Mittlerweile werden sogar unternehmensübergreifende Projekte auch in einem internationalen Umfeld erfolgreich geführt. Dabei schließen sich Mitarbeiter aus verschiedenen Firmen zu „virtuellen Teams“8zusammen.9
Diese beiden Thesen hängen stark miteinander zusammen: In jedem Projekt ist es für den Projekterfolg unerlässlich, dass jeder involvierte Mitarbeiter immer über den aktuellen Pro-jektstand, dessen Verlauf und Neuigkeiten informiert ist10. Gerade bei Projekten, bei denen
1Dabei spielt nun keine Rolle, welche Information gemeint ist, es wird im folgenden vom Begriff „Information“ ausgegangen
2Vgl. /1/, S.11; Vgl. /2/, S.1; Siehe /24/, S.61
3/3/, S.378;
4Üblicherweise Arbeit, Boden und Kapital (Realkapital im Sinne von Gebäude und Maschinen), Vgl. /11/, 1.Abschnitt
5Vgl. /3/, S.379; Vgl. /26/, S.1; In diesem Zusammenhang wird oft der Begriff „Wissen“ verwendet. Zur Abgrenzung zwischen Information und Wissen: Siehe Anlage 3
6/19/, S.5
7Die hängt auch damit zusammen, dass häufig mehrere Partner, z.B. Mitarbeiter aus mehreren Firmen an der Projektabwicklung beteiligt sind.; Vgl. /33/, S.245
8Siehe /4/, S.3+49Siehe /27/, S.188
10Z.B. Termine, etc., die sogenannten „Projektinformationen“, die bei der Arbeit mit mehreren Personen in einem Projekt anfallen und ausgetauscht werden müssen; Siehe Kap.1.2
Page 12
die Mitarbeiter auf der ganzen Welt verteilt sind11, ist es schwierig, die Zusammenarbeit aller Beteiligten zu organisieren. Es sind daher Werkzeuge notwendig, die diesen hohen Kommunikationsbedarf und den Informationsfluss zeitnah abdecken.
Auch bei der BRAIN International AG, einem weltweit tätigen Unternehmen, sind derartige Projektkonstellationen inklusive ihrer Problematiken an der Tagesordnung. In aktuellen Projekten der „Product Development Division“, der Entwicklungsbereich der BRAIN International AG, kommen beispielsweise die Projektbeteiligten häufig aus verschiedenen Ländern, hauptsächlich aus den USA und aus Deutschland. Dies ist beispielsweise in der Enterprise Modeling Group (EMG)12der Fall. Für das EMG-Team wurde eine Plattform gesucht, auf der sich die Beteiligten asynchron13, bedingt durch die Dezentralität, untereinander mit einfachen Mitteln austauschen können. Durch diese Plattform soll der Austausch von z.B. aktuellen Terminen und Dokumenten ermöglicht werden. Bevor eine konkrete Konzeption erfolgte, wurden a priori generelle, nicht-funktionale Anforderungen gestellt.
Es soll sich dabei um ein
-selbstentwickeltes, d.h. nicht vom Markt eingekauftes,
-kostengünstiges,
-skalierbares,
-und auch für andere Zwecke wiederverwendbares System handeln.
-Die Realisierung sollte möglichst zügig erfolgen, so dass schnellstmöglich ein fertiges und einsatzfähiges System zur Verfügung steht.
Aus den groben Anforderungen entstanden sehr schnell die ersten konzeptionellen Ideen, in welche Richtung sich die Realisierung bewegen könnte. Die Anforderung nach einer kostengünstigen und schnellen Realisierung deutete daraufhin, nach vorhandenen Open Source-Softwareprodukten Ausschau zu halten, die auch die funktionalen Anforderungen14erfüllen.15Auf der Basis des offenen Quellcodes sind diese erweiterbar und können weiterentwickelt werden. Außerdem ist der Quellcode frei verfügbar. Da zusätzlich die Forderung nach Skalierbarkeit und Wiederverwendbarkeit besteht, spricht vieles dafür eine objekt- bzw.
11Vgl. /33/, S.244
12Die EMG wird organisatorisch als eigene Abteilung in der Entwicklung betrachtet. Im Folgenden wird in dieser Arbeit um den Projektcharakter zu unterstreichen vom „EMG-Team“ gesprochen. Auf dieses wird im Kapitel 4.1 näher eingegangen. Die genauen Aufgaben und Hintergründe bzgl. des Teams sind zum Verständnis der Problemstellung nicht zwingend.
13Siehe Glossar14Siehe Glossar
15Wie später zu erkennen sein wird, muss Open Source nicht zwangsläufig kostenlos sein ! Siehe Kap.2.2
Page 13
komponentenorientierte Vorgehensweise für die Softwareentwicklung auszuwählen. D adurch kann eine zukunftssichere Architektur verwirklicht werden. Diese Ideen bildeten die Grundlage für das daraufhin gestartete neue Projekt mit dem Ziel der praktischen Umsetzung eines derartigen Systems.
Sinn und Zweck dieser Diplomarbeit ist es, die Konzeption und die Realisierung eines Pro-jektinformationssystems für das EMG-Team zu veranschaulichen. Im Mittelpunkt steht dabei nicht die Beschreibung der Umsetzung, d.h. der Implementierung und des kompletten Projektablaufs, sondern die Begründung der zu Grunde liegenden Technik und theoretischen Konzepte der Softwareentwicklung16. Es wird in dieser Arbeit gezeigt, dass sich das Zusammenspiel von Open Source-Software verbunden mit Eigenentwicklungen auf der Basis der komponentenorientierten Softwaretechnik in der Praxis bewährt hat. Damit wird eine Alternative zum herkömmlichen Ansatz „Make or buy“17aufgezeigt. In vielen Bereichen der Arbeit sind dazu Vergleiche und Abgrenzungen notwendig, um die getroffenen Entscheidungen zu begründen. So wird z.B. veranschaulicht, warum das schon seit Anfang 1998 im Hause eingesetzte Groupware-System Lotus Domino nicht als Plattform18für das System in Frage kam. Weiterhin ist es Ziel der Arbeit zu verdeutlichen, warum gezielt ein Projektinformationssystem entwickelt und welche Absichten mit diesem bezweckt wurden.
Aus dieser Zielsetzung ergaben sich für den Aufbau der Arbeit zwei größere Blöcke. Der erste Block der Arbeit umfasst die ersten drei Kapitel. In diesen wird auf theoretische Aspekte eingegangen, die noch unabhängig von der eigentlichen zu bewältigenden betrieblichen Aufgabe zu sehen und dementsprechend frei und unabhängig formuliert sind. Ziel des Blockes ist es eine theoretische Grundlage zum Verständnis des praktischen Blocks zu schaffen. In der Theorie wird auf allgemeiner Ebene eine erste Begründung der Konzepte gegeben. Im ersten Kapitel wird dazu zuerst der Begriff „Projektinformationssystem“ näher untersucht, d.h. wie dieser zu verstehen und einzuordnen ist und welche Aufgaben ein derartiges System hat. Im zweiten Kapitel wird auf die Open Source-Thematik eingegangen. Es wird gezeigt, wie sich Open Source-Software im Vergleich zu kommerzieller Software hinsichtlich Definition und Entwicklungsmethodik unterscheidet und welchen Nutzen Firmen daraus erzielen. Im dritten Kapitel steht die Komponententechnik, eine der aktuell fortschrittlichsten Softwareentwicklungsmethoden, im Fokus. Das vierte Kapitel bildet den Übergang zwischen dem theoretischen und dem praktischen Block der Arbeit. Es beschreibt mit Hilfe einer Eva-
16Projektinformationssysteme,Open Source und komponentenbasierte Softwareentwicklung
17Siehe Glossar18Siehe Glossar
Page 14
luation auf Basis der gewünschten funktionalen und nichtfunktionalen Anforderungen die Begründung für den Einsatz der theoretischen Konzepte für den praktischen Anwendungsfall. Die Kapitel fünf bis sieben bilden den zweiten größeren Block der Arbeit. Zunächst wird im fünften Kapitel die Lösung der umzusetzenden Funktionalität des Projektinformationssystems in den Vordergrund gestellt. Danach geht das sechste Kapitel auf die Verfahrensweisen und den daraus resultierenden Erfahrungen mit Open Source in der Praxis ein. Anschließend wird im siebten Kapitel das System hinsichtlich seiner komponentenorientierten Charakters veranschaulicht und wie es abschließend zu einer Einheit zusammengebaut wurde. Das Kapitel acht vollendet die Arbeit mit einem Fazit und einem Ausblick in die Zukunft, wobei auch auf Chancen und Risiken des Systems eingegangen wird.
Page 15
Die Begründung der in der Problemstellung angesprochenen Tendenzen liefert den allgemeinen Nachweis für den Einsatz von Projektinformationssystemen (im Folgenden „ProInf-Sys“ genannt). Es entsteht bzgl. der ersten Tendenz bei der Analyse der heute vorhandenen Informationen die Erkenntnis, dass einerseits die Menge der zur Verfügung stehenden I n-formationen ständig zunimmt19, bzw. die bereits vorhandenen Informationen erweitert, verändert und aktualisiert werden. Andererseits nimmt aber auch die Halbwertszeit dieser I n-formationen ab.20In vielen Literaturquellen wird davon gesprochen, dass wir momentan in einer „Informationsgesellschaft“21leben.
Die entscheidenden Gründe für das Zunehmen des Stellenwertes des Produktionsfaktors „Information“ liegen in der heutigen Gesellschaft:
Die zweite Tendenz im heutigen Geschäftsleben stellen die besonders in der IT-Branche zunehmend projektorientiert arbeitenden Organisationen dar.26Die zur Begründung diskutierten Kriterien hängen deutlich mit den oben genannten zusammen :
19Man spricht dabei gerne von einer „Informationsflut“
20Dies gilt auch für das „Wissen“. Zum Verhältnis zwischen „Information“ und „Wissen“: Siehe Anlage 3
21Vgl. /1/, S.11; Siehe /7/, S.6ff. + 10ff.; Oft ist auch bereits die Rede vom Übergang zur „Wissensgesellschaft“; Siehe /6/, Kap. Einführung; Siehe Anlage 1
22Vgl. /5/, S.16; Vgl. /4/, S.3; Vgl. /2/, S.123/29/, S.724Vgl. /26/, S.2
25/6/, Kap. Einführung; Vgl. /7/, S.2126Vgl. /10/, 1. Abschnitt; Siehe Anlage 4
Page 16
Wenn beide genannten Tendenzen miteinander verschmolzen werden, entsteht der Begriff der Projektinformation. Dies ist durchaus gängig, da auch in einem Projekt viele Informationen anfallen. Im Gegensatz zu früheren Zeiten, als die benötigte Information gesucht werden musste, liegt heute die Problematik eher im Herausfiltern der relevanten Information aus der „Informationsflut“.30Um stets den Überblick zu bewahren, bedarf es eines Werkzeuges zur Verwaltung und Verarbeitung der Informationsfülle in Projekten. Die IT hat dabei das Potential, dies durch geeignete Softwarelösungen in Form eines ProInfSys abzudecken.
Die in Projekten anfallenden Informationen sind konsequenterweise als „Projektinformationen“31zu bezeichnen. Sie dienen nach DIN 69901 in erster Instanz als „Daten für Planung, Steuerung und Überwachung eines Projektes“32und umfassen sämtliche relevante Daten und Dokumente, z. B. Adressdaten oder Besprechungsprotokolle. Aufgrund der verschiedenen Rollen in Projekten sind die relevanten Projektinformationen von der Bezugsperson abhängig. Der Umgang mit diesen Informationen und deren Fluss zwischen den einzelnen Individuen ist für den Erfolg des Projekts entscheidend. Dazu werden in der Praxis i mmer häufiger rechnergestützte Informationssysteme eingesetzt.
Ein Informationssystem stellt ein System zum Zwecke der „Beschaffung, Verarbeitung, Speicherung, Übertragung und Bereitstellung von Informationen“33dar. Diese sollen stets
27Diese können auf der ganzen Welt verteilt sein und unterschiedliche Fähigkeiten aufweisen.
28Vgl. /9/, S.26
29Vgl. /8/, Kap.1.4, weitere Gründe : Siehe /8/, Kap.1.430Siehe /33/, S.27; Zum Begriff der Informationsflut: Siehe /32/, S.100
31Zur allgemeinen Definitionen von „Projekt“: Siehe Anlage 2; Zur allgemeinen Definition und Abgrenzung von Information: Siehe Anlage 3
32/14/, Stichwort: Projektinformation; Im Zuge des Wissensmanagements kann dies noch weiter gefasst werden.33/3/, S.147; Zum Systembegriff : Siehe /3/, S.146
Page 17
aktuell, vollständig und fehlerfrei sein, sowie immer zum richtigen Zeitpunkt am richtigen Ort zur Verfügung stehen.34Informationssystem werden anhand mehrerer Ebenen bzgl. des Unterstützungsniveaus zwischen System und Benutzer unterschieden :
Grenzt man die Menge der relevanten Informationen eines Informationssystems auf ein bestimmtes Projekt ein, wird von einem ProInfSys gesprochen. Ein ProInfSys ist im Sinne der DIN 69901 die „Gesamtheit der Einrichtungen und Hilfsmittel und deren Zusammenwirken bei der Erfassung, Weiterleitung, Be- und Verarbeitung, Auswertung und Speicherung der Projektinformationen.“36Diese Definition lässt für die Umsetzung eines derartigen Systems viele Freiräume. Es gilt aber, wie auch für alle Informationssysteme, ein ausgeglichenes Verhältnis zwischen Informationsangebot, -bedarf und -nachfrage zu schaffen.37Dies wird jedoch auf die relevanten Informationen im Projekt eingeschränkt. In der Praxis sind bzgl. der Begriffe „Projekt“ und „System“ das „Projektmanagementsystem“ oder allgemein „Projektmanagement“ geläufiger.38
Bei der Diskussion über Software, die für ein Team geschaffen wurde, wird man automatisch mit den Begriffen CSCW und Groupware konfrontiert. Unter CSCW39(Computer Sup-ported Cooperative Work) wird „die Bezeichnung eines Forschungsgebietes, welches auf in-
34Vgl./11/, Ziele des ISM
35Vgl. /3/, S.157
36/14/, Stichwort: Projektinformationssystem37Vgl. /18/, Folie 14; Siehe Anlage 5
38Eine Definition dieser Begriffe und die Abgrenzung zum Projektinformationssystem : Siehe Anlage 639Es existieren zahlreiche Interpretationen von CSCW.; Siehe /37/, Folie 9ff.; Siehe /35/, S.32+33; Siehe /40/, S.15+16; Am Häufigsten anzutreffen ist eine Interpretation der einzelnen Buchstaben des Akronyms, wobei
dies vorwärts angewandt wird (von C nach W), häufiger findet man jedoch eine Rückwärtsanalyse. Dies soll hier nicht näher vertieft werden.; Siehe /37/, Folie 11; Siehe /35/, S.33ff.; Siehe Folie /39/, 11+12
Page 18
terdisziplinärer Basis untersucht, wie Individuen in Arbeitsgruppen oder Teams40zusammenarbeiten und wie sie dabei durch Informations- und Kommunikationstechnologie unterstützt werden können, um die Effektivität und Effizienz der Gruppenarbeit zu erhöhen.“41verstanden. Geprägt wurde der Begriff 1984 durch Irene Greif und Paul Cashman.42
Eng mit CSCW verknüpft ist der Begriff der Groupware. Darin handelt es sich um ein „Kunstwort aus Group und Software, wörtlich: Software für Gruppen“43, „zur Unterstützung kooperativer Arbeitsformen“44, also Gruppenarbeitsformen, die unabhängig von Zeit und Ort tätig sind.45Groupware setzt die theoretischen Grundlagen von CSCW um.46Zum ersten Mal in der EDV-Welt steht der Mensch als Benutzer mit seiner Arbeitsweise im Vordergrund der Betrachtung und nicht eine technische- oder systemspezifische Begründung.47Für die Notwendigkeit des Einsatzes von Groupware sprechen die gleichen Punkte wie für die Motivation für den Faktor Information und den Einsatz von Projekten.48
Eine Klassifizierung von Groupware kann aus verschiedenen Sichtweisen erfolgen. Die zwei Bekanntesten sind die Klassifizierung nach Raum und Zeit49, und das 3K-Modell50. Die Klassifizierung nach Raum und Zeit beschreibt die verschiedenen Szenarien für Groupware, die aus den unterschiedlichen Raum/Zeitkonstellationen möglich sind. Dabei wird der Standort der Anwender mit der Zeit der Anwendung in Bezug gebracht und in einer Matrix abgebildet.
40Zum Unterschied zwischen einer Gruppe und einem Team; Siehe Anlage 7
41/100/, S.17; /1/, S.122; Vgl. /102/, S.2; Vgl. /32/, S.93; Vgl. /4/, S.4; Vgl. /35/, S.29+31ff.; Vgl. /39/, Folie 9; Vgl. /40/, S.15; Vgl. /38/, Kap.6.1; Vgl. /37/, Folie 3ff.; Zum Thema Gruppenarbeit : Siehe /37/, Folie 6; Siehe /38/, Kap.6.2; Vgl. /136/, S.7
42Vgl. /136/, S.5 ; Definition nach GREIF: CSCW is an „identifiable research field focused on the role of the computer in group work.“; /105/; Vgl. /102/, S.3
43/33/, S.23; Vgl. /126/, S.5
44/1/, S.124; Vgl. /126/, S.5
45Vgl. /33/, S.22; Vgl. /103/, S.98ff.;Vgl. /40/, S.4; Vgl. /39/, Folie 9; Vgl. /34/, Kap.1.146Vgl. /103/, S.98; Vgl. /35/, S.2947Vgl. /33/, S.2448Siehe Kap.1.1; Siehe /33/, S.27
49Siehe /35/, S.4250Siehe /35/, S.43