Systemplanung. Planung und Realisierung von Informatik-Projekten: Band 2: Der Prozeß der Grobprojektierung, der Feinprojektierung und der Installierung [5., vollständig überarbeitete Auflage. Reprint 2018] 9783486787429, 9783486231335

Citation preview

Systemplanung Planung und Realisierung von Informatik-Projekten Band 2 Der Prozeß der Grobprojektierung, der Feinprojektierung und der Installierung

Von

Dr. Lutz J. Heinrich o. Univ.-Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Linz

5., vollständig überarbeitete und ergänzte Auflage mit 132 Abbildungen

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CLP-Einheitsaufnahme Systemplanung : Planung und Realisierung von InformatikProjekten / von Lutz J. Heinrich. - München ; Wien : Oldenbourg. (Wirtschaftsinformatik) Teilw. verf. von Lutz J. Heinrich und Peter BurghoLzer. Literaturangaben NE: Heinrich, Lutz J.; Burgholzer, Peter Bd. 2. Der Prozess der Grobprojektierung, der Feinprojektierimg und der Installierung. - 5., vollst. Überarb. und erg. Aufl. - 1994 ISBN 3-486-23133-2

© 1994 R. Oldenbourg Verlag GmbH, München Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Uriieberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München ISBN 3 - 4 8 6 - 2 3 1 3 3 - 2

Vorwort zur fünften Auflage Mit der nun vorliegenden 5. Auflage des zweiten Bandes dieses Lehrbuchs ist inhaltlich und formal das Niveau erreicht, auf dem sich die anderen Bände der Lehrbuchreihe Wirtschaftsinformatik des Autors und seiner Ko-Autoren im Oldenbourg Verlag teilweise schon seit Jahren befinden. Der Lernstoff ist vollständiger geworden, ohne daß der Buchumfang über Gebühr ausgeweitet werden mußte, und die Lesbarkeit wurde drastisch verbessert. In die 5. Auflage "Systemplanung 2" neu aufgenommen wurden die Lerneinheiten ERMOD (Entity-Relationship-Modell), NORMA (Normalisierung), OPMOD (Optimierungsmodelle), SOBOP (Objektorientierte Programmiersprachen) und SWISS (Kl-Sprachen und Wissensverarbeitungssprachen). Mit ERMOD und NORMA wurde der Methodenteil zur Datenmodellierung ergänzt. Der bis zur 4. Auflage dazu vermittelte Lernstoff (in den Lerneinheiten WDASY und DAMOD) erwies sich als zu wenig detailliert, um von den Lesern nachvollzogen werden zu können. Mit Lerneinheit OPMOD soll der mathematischen Modellierung beim Entwerfen des Methodensystems der ihr gebührende Stellenwert eingeräumt werden; sie wurde bis zur 4. Auflage "unter Wert" behandelt. Mit Lerneinheit SOBOP wird die in Band 1 dargestellte Objektorientierung der Systemplanung (vgl. Lerneinheit OBOSP) bezüglich der Software-Entwicklung vertieft. Mit Lerneinheit SWISS wird die zunehmende Bedeutung wissensbasierter Ansätze bei der Implementierung des Methodensystems berücksichtigt. Aus Band 2 wurden die Lerneinheiten AUSAN (Durchführen der Ausschreibung), VERTA (Abschließen von Verträgen), BEWER (Bewertungsmethoden) und BENCH (Benchmarking) entfernt. Sie wurden mit der 4. Auflage des Lehrbuchs "Informationsmanagement" nach dort übernommen, weil sich der Lernstoff in die unternehmensweite Betrachtung der Informationsinfrastruktur besser einfügt als in die projektbezogene Betrachtung der Systemplanung. Verweise auf das Lehrbuch "Informationsmanagement" beziehen sich auf die 4. Auflage 1992. Daß Systemplanung ein kreativer, kooperativer Prozeß ist, wurde nicht nur in einschlägigen Lerneinheiten deutlich gemacht (insbes. in Lerneinheit PROSP), diese Feststellung läuft wie ein roter Faden durch beide Bände "Systemplanung". Genauer gesagt ist Systemplanung ein Meta-Prozeß, also ein "Prozeß über Prozesse". Dabei sind zwei Prozeßarten hervorzuheben, nämlich der eher sozialwissenschaftlich erklärbare Arbeitsprozeß und der eher ingenieurwissenschaftlich erklärbare Produktionsprozeß. Primäres Anliegen des Autors ist es, den ersten dieser Prozesse darzustellen. Deshalb nehmen beispielsweise die Ausführungen zum Entwurfsprozeß, insbesondere zum Entwerfen der Arbeitsorganisation, breiten Raum ein. Auf der anderen Seite wird beispielsweise der Prozeß der Software-Entwicklung eher oberflächlich behandelt. Dies ist auch deshalb angebracht, weil in Lehrkonzepten des Wirtschaftsinformatik-Studiums die SoftwareEntwicklung in speziellen, einschlägigen Lehrveranstaltungen (z.B. unter der Bezeichnung "Software Engineering") abgedeckt wird.

4

Vorwort

Herrn Prof. Dr. J. Picht (Universität Halle-Wittenberg) danke ich für die kritische Durchsicht des Manuskripts und die vorgeschlagenen Änderungen, die nur soweit berücksichtigt werden konnten, als sie sich im Rahmen der in beiden Bänden verwendeten Konzeption bewegen. Dazu gehört weder eine stärkere Objektorientierung, noch eine deutlichere Hinwendung zur Darstellung von Werkzeugen (vgl. dazu das Vorwort zur 6. Auflage von Band 1). Den Herren Dr. H. Missbauer und Dr. W. Schneider (Universität Linz) danke ich für die kritische Durchsicht der Lerneinheit OPMOD. Dank gebührt auch den Lektoren des Instituts für Wirtschaftsinformatik/Information Engineering der Universität Linz für die Durchsicht der Lerneinheiten ERMOD und NORMA sowie die inhaltliche Abstimmung mit den von ihnen gehaltenen Übungen. An der Bearbeitung der Manuskripte für die Lerneinheiten SPROM und SVIER war Herr K. Ablinger maßgeblich beteiligt. Frau Dr. E. Heinrich hat mehrmals Korrektur gelesen und zur Verbesserung der Verständlichkeit des Textes wesentlich beigetragen. Frau R. Hintersteininger nahm die Portierung der Textdateien von einem veralteten Textverarbeitungssystem auf Mikrosoft Word vor und schuf damit die Voraussetzung für eine zeitgemäße Bearbeitung des Manuskripts durch den Autor; sie verbesserte zahlreiche Abbildungen und fertigte zusätzliche Abbildungen an. Herrn P. Burgholzer, Mitautor während dreier Auflagen, danke ich bei dieser Gelegenheit für die mehrjährige Zusammenarbeit; wegen einer Überlast an hauptberuflichen Verpflichtungen mußte er aus dem Autorenteam ausscheiden. Der Autor verwendet das herkömmliche Maskulinum und verzichtet auf umständliche Konstruktionen für eine geschlechtsneutrale Formulierung. Wo immer möglich wurde eine Formulierung verwendet, die auf einen Geschlechterbezug verzichtet. L. J. H.

Aus dem Vorwort zur vierten Auflage In der vierten Auflage von Band 1 wurde die Prozeßorientierung der Systemplanung besonders betont, indem sie sowohl textlich umfangreicher, als auch grafisch besser dargestellt wurde. Mit der Prozeßorientierung wurden auch die Inputs und die Outputs der Planungsphasen und damit die Zwischenprodukte und Produkte der Systemplanung präziser herausgearbeitet. Manche Benutzer dieses Buches haben die ausdrückliche Betonung der Produktorientierung vermißt. Obwohl sie sich in der Prozeßorientierung findet, soll sie mit der fünften Auflage von Band 1 noch besser verdeutlicht werden. Mit der Prozeßorientierung bzw. Produktorientierung der Systemplanung in engem Zusammenhang steht die Frage der konkreten Ausgestaltung des Planungsprozesses und seiner Zwischenprodukte und Produkte in Abhängigkeit von bestimmten Planungsvorgaben oder Planungsentscheidungen. Alle Varianten in einem Grundlagen-Lehrbuch darzustellen, ist nicht möglich. Der damit angesprochene Grundgedanke kann aber besser verdeutlicht werden, und er kann auch beispielhaft in verschiedenen Lerneinheiten erläutert werden.

Inhaltsverzeichnis Verzeichnis aller Lerneinheiten in Band 1 und Band 2

7

Der Prozeß der Grobprojektierung

9

Aufgaben der Grobprojektierung

10

ZAMGP WDASY WMESY WAORG WTRAN WSICH WINTE BTECH PFLIC

11 16 28 44 57 68 75 83 92

-

Ziel, Aufgaben und Methodik der Grobprojektierung Entwerfen des Datensystems Entwerfen des Methodensystems Entwerfen der Arbeitsorganisation Entwerfen des Transportsystems Entwerfen des Sicherungssystems Integration der Systementwürfe Bestimmen des Technikbedarfs Erstellen des Pflichtenhefts

Methoden und Techniken der Grobprojektierung

100

VGROB OBTYP ERMOD NORMA NUMSY OPMOD PAORG PINTE

100 109 119 127 136 146 153 162

-

Vorgehensweise bei der Grobprojektierung Objekttypenmethode Entity-Relationship-Modell Normalformenlehre Nummernsysteme Optimierungsmodelle Prinzipien der Arbeitsorganisation Integrationsprinzipien

Der Prozeß der Feinprojektierung

171

Aufgaben der Feinprojektierung

172

ZAMFP EDASY EMESY EAORG ETRAN ESICH EINTE

173 177 188 200 218 232 243

-

Ziel, Aufgaben und Methodik der Feinprojektierung Entwickeln des Datensystems Entwickeln des Methodensystems Entwickeln der Arbeitsorganisation Entwickeln des Transportsystems Entwickeln des Sicherungssystems Integration der Systementwicklung

6

Inhaltsverzeichnis

Methoden und Techniken der Feinprojektierung

252

PSOFT SPROM SOBOP SVIER SWISS SMEBA SPLAN PAPER PKOER KRYPT

252 262 270 280 287 298 307 319 330 341

-

Prinzipien der Software-Entwicklung Höhere prozedurale Programmiersprachen Objektorientierte Programmiersprachen Programmiersprachen der vierten Generation Kl-Sprachen und Wissensverarbeitungssprachen Methodenbanksysteme Planungssprachen Prinzipien der Arbeitsplatzergonomie Prinzipien der Kommunikationsergonomie Kryptographische Verschlüsselungsmethoden

Der Prozeß der Installierung

349

Aufgaben der Installierung

350

ZAMIN VORIN

- Ziel, Aufgaben und Methodik der Installierung - Vorbereiten der Installierung

351 359

DURIN

- Durchführen der Installierung

366

Methoden und Techniken der Installierung

372

VINST bei der Installierung DAKON -- Vorgehensweise Methoden der Datenkonvertierung

372 379

PRADA

386

- Methoden der Programmadaption

Literaturverzeichnis

393

Schlagwortverzeichnis

403

Alphabetisches Verzeichnis der Lerneinheiten Das Verzeichnis bezieht sich auf die 6. Auflage von Band 1 und die 5. Auflage von Band 2.

AFEIN ANFOA ANIST AUTER BTECH DAFLU DAKON DARST DOKUM DURIN EAORG EDASY EINSP EINTE EMESY ENTAB ERIST ERMOD ESICH ETRAN FORMZ GRUND HIPO ISTAN ISTER KOMAN KONSA KREAT KRYPT MATRX NETZP NORMA NUMSY NUTZW OBOSP OBTYP OPMOD PAORG PAPER PENET PFLIC PINTE PKOER PRADA

-

Auswerten der Feinstudie Anforderungsanalyse Analysieren des Istzustands Aufgabenträger der Systemplanung Bestimmen des Technikbedarfs Datenflußdiagramme Methoden der Datenkonvertierung Darstellungstechniken Dokumentationsmethoden Durchführen der Installierung Entwickeln der Arbeitsorganisation Entwickeln des Datensystems Einführung in die Systemplanung Integration der Systementwicklung Entwickeln des Methodensystems Entscheidungstabellen-Technik Erfassen des Istzustands Entity-Relationship-Modell Entwickeln des Sicherungssystems Entwickeln des Transportsystems Festlegen der Formalziele Entwerfen der Grundkonzeption Hierarchy plus Input-Process-Output Methoden der Istzustandsanalyse Methoden der Istzustandserfassung Methoden der Kommunikationsanalyse Konsequenzanalyse Kreativitätstechniken Kryptographische Verschlüsselungssysteme Matrixanalyse Netzplantechnik Normalformenlehre Nummernsysteme Nutzwertanalyse Objektorientierte Systemplanung Objekttypenmethode Optimierungsmodelle Prinzipien der Arbeitsorganisation Prinzipien der Arbeitsplatzergonomie Petri-Netze Erstellen des Pflichtenhefts Integrationsprinzipien Prinzipien der Kommunikationsergonomie Methoden der Programmadaption

1 1 1 1 2 1 2 1 1 2 2 2 1 2 2 1 1 2 2 2 1 1 1 1 1 1 1 1 2 1 1 2 2 1 1 2 2 2 2 1 22 2 2 -

354 283 345 80 83 116 379 192 227 366 200 177 11 243 188 91 338 119 232 218 257 268 99 380 366 387 314 305 341 138 205 127 136 162 47 109 146 153 319 127 92 162 330 386

8

Alphabetisches Verzeichnis der Lerneinheiten

PRAET PROME PROPL PROSP PROTY PSOFT SACHZ SADT SIMUL SMEBA SOBOP SPLAN SPROM SVIER SWISS SYSTE TECHA TESTM VFEIN VGROB VINST VORIN WAORG WDASY WERSP WERTA WINTE WIRTA WMESY WTRAN WSICH ZAMFP ZAMFS ZAMGP ZAMIN ZAMSP ZAMVS ZERFA

-

Präsentationstechniken Methoden des Projektmanagements Durchführen der Projektplanung Prozeß der Systemplanung Prototyporientierte Systemplanung Prinzipien der Software-Entwicklung Festlegen der Sachziele Structured Analysis and Design Technique Simulation Methodenbanksysteme Objektorientierte Programmiersprachen Planungssprachen Höhere prozedurale Programmiersprachen Programmiersprachen der vierten Generation Kl-Sprachen und Wissensverarbeitungssprachen Systemtechnik und Systemplanung Technikanalyse Testmethoden Vorgehensweise bei der Feinstudie Vorgehensweise bei der Grobprojektierung Vorgehensweise bei der Installierung Vorbereiten der Installierung Entwerfen der Arbeitsorganisation Entwerfen des Datensystems Werkzeugunterstützung der Systemplanung Wertanalyse Integration der Systementwürfe Wirtschaftlichkeitsanalyse Entwerfen des Methodensystems Entwerfen des Transportsystems Entwerfen des Sicherungssystems Ziel, Aufgaben und Methodik der Feinprojektierung Ziel, Aufgaben und Methodik der Feinstudie Ziel, Aufgaben und Methodik der Grobprojektierung Ziel, Aufgaben und Methodik der Installierung Ziel, Aufgaben und Methodik der Systemplanung Ziel, Aufgaben und Methodik der Vorstudie Methoden der Zeiterfassung

1 1 1 1 1 2 1 1 1 2 2 2 2 2 2 1 1 1 1 2 2 2 2 2 1 1 2 1 2 2 2 2 1 221 1 1 -

185 322 275 39 57 252 248 107 174 298 270 307 262 280 287 32 296 215 359 100 372 359 44 16 68 144 75 152 28 57 68 173 331 11 351 21 241 374

Der Prozeß der Grobprojektierung Strategische Infonnationssystem-Planung '//;;///;//////;//////»

Planungsziele |

M

Der Prozeß der Vorstudie ^Gmndkonzeptionj^

••3

Der Prozeß der Feinstudie r77rT77777777^7T77T777TT777T7^

•a

Q

Angepaßte % Grundkonzeption m

Der Prozeß der Grobprojektierung ; Logisches Modell i Sollzustand m

,so

iä :3 C 03 £

Der Prozeß der Feinprojektierung : Physisches Modell w : Sojjzustand ^ Der Prozeß der Installierung i Produktives $ i Informationssystemi

10

Der Prozeß der Grobprojektierung

Gegenstand des folgenden Kapitels ist der Teil des kooperativen und kreativen Arbeitsprozesses Systemplanung, der nach dem in diesem Lehrbuch verwendeten Phasenmodell als Grobprojektierung bezeichnet wird. Ausgehend vom Ziel der Grobprojektierung, werden im ersten Teil des Kapitels ihre Aufgaben entwickelt und die zur Unterstützung der Aufgabendurchführung verwendeten Methoden und Techniken charakterisiert. Anschließend werden die Aufgaben der Grobprojektierung im Detail erläutert. Im zweiten Teil des Kapitels werden die Methoden und Techniken der Grobprojektierung dargestellt. Die Zusammenhänge zwischen den Aufgaben der Grobprojektierung einerseits und ihren Methoden und Techniken andererseits werden durch Methodenverweise bzw. Aufgabenverweise verdeutlicht. Ergebnis der Grobprojektierung ist das logische Modell des zu schaffenden Informationssystems; es ist die Schnittstelle zur Feinprojektierung. Aufgaben der Grobprojektierung ZAMGP WDASY WMESY WAORG WTRAN WSICH WINTE BTECH PFLIC

-

Ziel, Aufgaben und Methodik der Grobprojektierung Entwerfen des Datensystems Entwerfen des Methodensystems Entwerfen der Arbeitsorganisation Entwerfen des Transportsystems Entwerfen des Sicherungssystems Integration der Systementwürfe Bestimmen des Technikbedarfs Erstellen des Pflichtenhefts

11 16 27 43 56 68 75 83 92

Methoden und Techniken der Grobprojektierung VGROB OBTYP ERMOD NORMA NUMSY OPMOD PAORG PINTE

-

Vorgehensweise bei der Grobprojektierung Objekttypenmethode Entity-Relationship-Modell Normalformenlehre Nummernsysteme Optimierungsmodelle Prinzipien der Arbeitsorganisation Integrationsprinzipien

100 109 119 126 135 145 152 161

ZAMGP - Ziel, Aufgaben und Methodik der Grobprojektierung Lernziele Sie können die Zweckmäßigkeit der Grobprojektierung als eine Phase der Systemplanung begründen. Sie können das Ziel der Grobprojektierung mit eigenen Worten wiedergeben. Sie können die Struktur der Grobprojektierung erläutern, indem Sie ihre Aufgaben nennen. Sie können über die verfügbaren Methoden und Werkzeuge der Grobprojektierung generelle Aussagen machen. Definitionen und Abkürzungen Anwender (user) = eine Organisation oder ein Teil einer Organisation (z.B. eine Fachabteilung), die ein Informations- und Kommunikationssystem zur Unterstützung ihrer Aufgaben einsetzt oder einzusetzen beabsichtigt. Formalziel (quality goal) = ein Ziel, dessen Inhalt die Qualität oder die Güte der Systemplanung bzw. des Informationssystems als Produkt der Systemplanung beschreibt. Implementierung (implementation) = die Überführung eines logischen Modells in ein physisches Modell, logisches Modell (logical model) = die Abbildung eines Systems, die frei von physischen Attributen ist, also unabhängig von einer bestimmten Form der Implementierung. Methode (method) = ein auf einem System von Regeln aufbauendes Problemlösungsverfahren (z.B. ein Algorithmus). Pflichtenheft (requirements documentation) = ein Dokument, das die Ergebnisse der Grobprojektierung und den Bedarf an Techniksystemen beschreibt, physisches Modell (physical model) = die Abbildung eines Systems, die eine bestimmte Form der Implementierung zum Gegenstand hat, also mit physischen Attributen versehen ist. Qualitätssicherung (quality assurance) = alle planmäßigen Maßnahmen der Systemplanung, die sicherstellen, daß definierte Systemeigenschaften durch die Planungsergebnisse erreicht werden (z.B. durch Entwurfsinspektion). Sachziel (goal) = eine normative Aussage, deren Inhalt (Zielinhalt) auf die Beschreibung des Zwecks der Systemplanung bzw. des Informationssystems als Produkt der Systemplanung ausgerichtet ist. Systementwicklung (systems development) = die zusammenfassende Bezeichnung für die Phasen Grobprojektierung und Feinprojektierung. Systementwurf (systems design) = das Entwerfen des Systems in den durch die Systemgliederung gebildeten Teilprojekten. Systemgliederung (systems structure) = das Zerlegen des in der Grundkonzeption abgebildeten Gesamtsystems in Teilprojekte. Systemtechnik (systems technology) = die Gesamtheit der für die Implementierung des Systementwurfs erforderlichen Betriebsmittel. Teilprojekt (subproject) = eine Menge gleichartiger Entwurfsaufgaben unterschiedlicher Teilsysteme. Teilsystem (subsystem) = eine Menge von Aufgaben gleichen Sachcharakters, die nach den Funktionen des Aufgabensystems gebildet wird.

12

Aufgaben der Grobprojektierung

Ziel der Grobprojektierung Das generelle Sachziel der Systemplanung besteht darin, dem Anwender ein produktives Informationssystem zur Verfügung zu stellen. Entsprechend der Gliederung der Systemplanung in Phasen (vgl. Lerneinheit ZAMSP) sind aus dem Sachziel die Ziele der Phasen abzuleiten, hier also das Ziel der Grobprojektierung. Aus dem Ziel der Grobprojektierung sind deren Aufgaben abzuleiten sowie die zur Durchführung der Aufgaben einzusetzenden Methoden und Techniken zu bestimmen. Die Grobprojektierung ist - neben der Feinprojektierung - ein Teil der Systementwicklung (so wie die Vorstudie - neben der Feinstudie - ein Teil der Systemanalyse ist). Es ist daher zunächst zu begründen, warum eine Gliederung der Systementwicklung in einen Prozeß der Grobprojektierung und in einen Prozeß der Feinprojektierung zweckmäßig oder sogar notwendig ist. Folgende Argumente sprechen für diese Gliederung: • Die Feinprojektierung setzt Entscheidungen voraus, ohne die ihre Durchführung nicht zweckmäßig oder sogar nicht möglich ist (z.B. die Entscheidung, ob Standard-Anwendungssoftware eingesetzt oder ob Anwendungssoftware als Individualsoftware selbst oder durch Dritte entwickelt werden soll). • Rational begründbare Entscheidungen dieser Art können nicht gefällt werden, wenn die Systementwicklung nicht so weit vorangetrieben worden ist, daß ihre Ergebnisse als Entscheidungsgrundlage verwendet werden können. • Die in der Vorstudie entworfene und in der Feinstudie angepaßte Grundkonzeption reicht in ihrem Detaillierungsgrad nicht aus, um als Entscheidungsgrundlage verwendbar zu sein. • Das vielfältige und für den Systemplaner in der Regel unübersichtliche Angebot an Informations- und Kommunikationstechniken sowie an anderen Leistungen Dritter (z.B. von Software- und System-Häusern) muß vor dem Hintergrund der konkreten Anforderungen einer Systementwicklung erhoben und bewertet werden. Diese Anforderungen liegen mit der Grundkonzeption aus der Vorstudie noch nicht vor. • Schließlich führen grundsätzliche, methodische Überlegungen bezüglich der Vorgehensweise der Systementwicklung zu dem Ergebnis, daß es zweckmäßig ist, zunächst das logische Modell eines Systems zu entwerfen, das Entwurfsergebnis zu überprüfen und dann mit der Entwicklung des physischen Modells fortzufahren. Vor dem Hintergrund dieser Argumente kann das Sachziel der Grobprojektierung wie folgt beschrieben werden: Ausgehend von der (angepaßten) Grundkonzeption ist das logische Modell des Informationssystems mit dem Detaillierungsgrad zu erarbeiten, der eine rationale Entscheidung über die einzusetzenden Techniksysteme ermöglicht und der damit die Grundlagen für die Feinprojektierung (also für das Entwickeln des physischen Modells) bis zur Installierungsreife des Informationssystems schafft. Die Grobprojektierung folgt also primär einer Methodik, die in der konsequenten Orientierung auf den Entwurf eines logischen Modells besteht. Bezüglich der Formalziele der Grobprojektierung gelten die für die Prozeßqualität der Systemplanung erarbeiteten Vorgaben (vgl. Lerneinheit FORMZ).

ZAMGP - Ziel, Aufgaben und Methodik der Grobprojektierung

13

Aufgaben der Grobprojektierung Von dem genannten Sachziel ausgehend und unter Berücksichtigung des erläuterten methodischen Ansatzes, können die Aufgaben der Grobprojektierung wie folgt beschrieben werden: • Erste Aufgabe der Grobprojektierung: Systemgliederung. Zerlegen des in der Grundkonzeption abgebildeten Gesamtsystems so in Teilprojekte, daß ein Vorgehen nach einem geeigneten methodischen Ansatz, welcher das Erreichen des Ziels der Grobprojektierung unterstützt, möglich ist. • Zweite Aufgabe der Grobprojektierung: Systementwurf. Entwerfen des Informations- und Kommunikationssystems innerhalb der Teilprojekte unter Beachtung anerkannter Entwurfsprinzipien und durch Anwendung brauchbarer Entwurfsmethoden und Werkzeuge. • Dritte Aufgabe der Grobprojektierung: Systemtechnik. Bestimmen des Technikbedarfs, also des quantitativen und qualitativen Bedarfs an Informations- und Kommunikationstechnik (Hardware, Software, Werkzeuge und sonstige Betriebsmittel) für den Systementwurf. • Vierte Aufgabe der Grobprojektierung: Systemauswahl. Dokumentieren der Ergebnisse zur Systemgliederung, zum Systementwurf und zur Systemtechnik im Pflichtenheft. Die nachfolgende Darstellung der Aufgaben der Grobprojektierung folgt nicht ganz dieser Struktur. Die erste Aufgabe wird nicht inhaltlich dargestellt, sondern als systematische Vorgehensweise erläutert (vgl. Lerneinheit VGROB). Die zweite Aufgabe wird unter Verwendung dieser systematischen Vorgehensweise in Teilaufgaben gegliedert, die vom Entwerfen des Datensystems bis zum Entwerfen des Sicherungssystems reichen (vgl. Lerneinheiten WDASY, WMESY, WAORG, WTRAN und WSICH). Die Entwurfsergebnisse zu den Teilaufgaben müssen untereinander und mit dem vorhandenen Bestand abgestimmt werden (vgl. Lerneinheit WINTE). Die dritte und die vierte Aufgabe werden in je einer Lerneinheit geschlossen behandelt (vgl. Lerneinheiten BTECH und PFLIC). An die Erstellung des Pflichtenhefts schließen sich folgende Aufgaben an: • das Bestimmen des Technikbedarfs, der zu beschaffen ist, unter Berücksichtigung des verfügbaren Technikbestands; • das Durchführen von Ausschreibungen zur Deckung des Technikbedarfs, der nicht aus dem verfügbaren Bestand gedeckt werden kann; • das Durchführen von Angebotsanalysen und Angebotsbewertungen; • das Abschließen von Verträgen mit Lieferanten. Bei diesen Aufgaben handelt es sich offensichtlich um solche, die nicht aus der Sicht eines einzelnen IuK-Projekts bearbeitet werden können, weil ihre Bearbeitung der Berücksichtigung unternehmensweiter Gesichtspunkte bedarf (insbes. des Bestimmens des durch Beschaffungsmaßnahmen zu deckenden Technikbedarfs) und/oder weil die Planungsgruppe nicht über die zur Durchführung dieser Aufgaben erforderliche Qualifikation und Kompetenz verfügt (insbes. für das Abschließen von Verträgen mit Lieferanten). Diese Aufgaben werden daher von anderen Unternehmensinstanzen wahrgenommen (vgl. Lerneinheit TECHM im Band "Informationsmanagement"). Abbildung ZAMGP-1 zeigt die Aufgaben der

14

Aufgaben der Grobprojektierung

Grobprojektierung als groben Arbeitsablauf und gibt die Lerneinheiten an, in denen die Aufgaben erläutert werden. Das Testen und das Dokumentieren der Entwurfsergebnisse sowie die Qualitätssicherung sind Querschnittsaufgaben, die in die vier Aufgaben der Grobprojektierung eingebunden sind (vgl. Lerneinheiten TESTM und DOKUM sowie Lerneinheit QUALM im Band "Informationsmanagement"); sie werden daher nicht ausdrücklich genannt.

Abb. ZAMGP-1: Der Prozeß der Grobprojektierung

Methoden der Grobprojektierung Methoden und Techniken zur Unterstützung der Grobprojektierung stehen in erheblicher Anzahl, sich teilweise ergänzend, teilweise miteinander konkurrierend, zur Verfügung. Einige sind im Kapitel "Methoden und Techniken der Systemplanung" in Band 1 behandelt worden. Kennzeichnend für den Bestand an Methoden und Techniken der Systemplanung ist, daß die meisten von ihnen - und damit auch die auf ihnen aufbauenden Werkzeuge - weder eine klare Ausrichtung auf eine bestimmte Aufgabe der Systemplanung haben, noch insgesamt - geschweige denn einzelne oder mehrere von ihnen - in der Lage sind, alle Aufgaben der Systemplanung wirkungsvoll zu unterstützen. In vielen Fällen handelt es sich um eher allgemein verwendbare Instrumente. Es bestehen also einerseits Überschneidungen zwischen den verfügbaren Methoden, Techniken und Werkzeugen, andererseits bestehen erhebliche Lücken. Mit anderen Worten: Es gibt trotz eines "Methodenbergs" einen "Methodenmangel". Bei der Darstellung der einzelnen Entwurfsaufgaben wird angegeben und teilweise im Demonstrationsbeispiel deutlich gemacht, welche der Methoden für welche Aufgaben wie verwendet werden. Darüber hinaus werden einige für die Grobprojektierung spezifische Methoden, aber auch Grundsätze und Prinzipien, im Kapitel "Methoden und Techniken der Grobprojektierung" behandelt.

ZAMGP - Ziel, Aufgaben und Methodik der Grobprojektierung

15

Forschungsbefunde Heinrich/Hoffellner haben durch Vergleich der in einschlägigen Lehrbüchern angebotenen Methoden und Techniken der Informationssystem-Planung und den in der Praxis angewendeten Methoden und Techniken (Fragebogenerhebung in 195 österreichischen Unternehmen, Erhebungszeitraum November 1988) unter anderem festgestellt, daß zahlreiche in der Wirtschaftsinformatik-Ausbildung vermittelte Methoden und Techniken in der Praxis nicht angewendet werden. Mit Hilfe einer Korrelationsanalyse wurden die Zusammenhänge zwischen der Nichtverwendung und verschiedenen Parametern (wie Beschäftigtenanzahl der Unternehmen, Mitarbeiteranzahl der IKS-Abteilungen, Funktion und Ausbildung der Befragten) untersucht. Zusammenfassend wird festgestellt, daß die Methoden und Techniken umso weniger verwendet werden, je kleiner die Unternehmen (gemessen an der Mitarbeiteranzahl) sind und je geringer die Mitarbeiteranzahl in der IKS-Abteilung ist. Kontrollfragen 1. Worin besteht das Sachziel der Grobprojektierung? 2. Trifft die Aussage zu, daß die Methodik der Grobprojektierung primär in einer konsequenten Orientierung auf den Entwurf logischer Modelle besteht? 3. Warum ist es notwendig, zumindest aber zweckmäßig, die Systementwicklung in Grobprojektierung und Feinprojektierung zu gliedern? 4. In welche Aufgaben kann die Grobprojektierung zerlegt werden? 5. Welche Situation besteht bezüglich der Verfügbarkeit von Methoden und Techniken für die Grobprojektierung? Quellenliteratur Heinrich, L. J.: Zur Methodik der Systemplanung in der Wirtschaftsinformatik. In: Schult, E. und Siegel, Th. (Hrsg.): Betriebswirtschaftslehre und Unternehmenspraxis. Schmidt Verlag, Berlin 1986, 83 - 99 Heinrich, L. J. und Hoffellner, N.: Methoden und Techniken der Anwendungssystem-Planung eine empirische Studie. In: Information Management 4/1989,42 - 46

WDASY - Entwerfen des Datensystems Lernziele Sie erkennen, daß verschiedene Sichtweisen auf Daten notwendig sind. Sie können das Entwerfen des Datensystems in diese Sichtweisen richtig einordnen. Sie wissen, welche Bedeutung Datenmodelle als Beschreibungsmittel fiir Datenstrukturen haben. Sie lernen eine Vorgehensweise kennen, die zum logischen Datenmodell führt und können diese auf einfache Entwurfsaufgaben anwenden. Definitionen und Abkürzungen ANSI/SPARC = Akronym für American National Standard Institute/Standards Flanning and Requirements Committee. Attribut (attribute) = die Bezeichnung einer Eigenschaft eines Entitätstyps; die Menge der Werte, die ein Attribut annehmen kann, wird als Wertebereich bezeichnet. Baum (tree) = eine Struktur, in der es einen Knoten ohne Vorgänger gibt (Wurzelknoten), jeder andere Knoten einen Vorgänger hat und in der es für jeden vom Wurzelknoten verschiedenen Knoten eine Folge von Knoten gibt. Datendefinitionssprache (data definition language) = ein Werkzeug zur Transformation des konzeptionellen Schemas in das interne Schema einer Datenbank. Synonym: Datenbeschreibungssprache. Datenkonsistenz (data consistency) = die logische Widerspruchsfreiheit und Vollständigkeit der Daten im konzeptionellen Schema im Vergleich zur Wirklichkeit. Datenmodell (data model) = ein Abbild der von einer Anwendungsaufgabe benötigten Daten einschließlich der zwischen ihnen bestehenden Beziehungen. Datenredundanz (data redundancy) = das Vorhandensein eines bestimmten Attributs in mehreren Relationen. Entität (entity) = ein individuelles Exemplar der realen Welt oder der Vorstellungswelt des Menschen oder eine Beziehung zwischen zwei Exemplaren, wenn diese eine Bedeutung hat. Synonym: Datenobjekt. Entitätstyp (entity type) = eine Menge von Entitäten mit gleichen Attributen, die sich mindestens durch den Wert eines Attributs ("Schlüsselattribut") unterscheiden. Synonyme: Entitätsklasse, Entitätsmenge, Datenobjekttyp. Identifikationsschlüssel (identification key) = ein Attribut oder eine Attributekombination, dessen bzw. deren Wert jede Entität eines Entitätstyps eindeutig bezeichnet. Synonym: Schlüsselattribut. Relation (relation) = eine Menge von Entitäten (Tupeln), für die gilt, daß jede Entität (jedes Tupel) aus der gleichen Menge von Attributen besteht. Spezifizierung (specification) = die formale Modellierung oder die Abbildung der Anforderungen in einem formalen Modell, transitiv (transitive) = die Eigenschaft einer Relation, auf jeden Fall zwischen x und z zu bestehen, wenn sie zwischen x und y sowie zwischen y und z besteht. Tupel (tuple) = eine Abkürzung von n-Tupel, die Verallgemeinerung von Paar, Tripel, Quadrupel usw.; jede Zeile einer Relation bildet ein Tupel und repräsentiert eine Entität, die gesamte Relation repräsentiert einen Entitätstyp.

WDASY - Entwerfen des Datensystems

17

Schnittstellen beim Entwerfen des Datensystems Die Schnittstellen beim Entwerfen des Datensystems sind durch die nachfolgend beschriebenen Inputs und Outputs gekennzeichnet. Inputs zum Entwerfen des Datensystems sind: • die angepaßte Grundkonzeption (vgl. Lerneinheit AFEIN) als Ergebnis der Feinstudie; • die Systementwürfe in den Teilprojekten Methodensystem (vgl. Lerneinheit WMESY), Arbeitsorganisation (vgl. Lerneinheit WAORG) und Transportsystem (vgl. Lerneinheit WTRAN). Outputs des Entwerfens des Datensystems sind: • der Systementwurf im Teilprojekt Datensystem, durch den Entwurfsarbeiten in den anderen Teilprojekten beeinflußt werden; • das logische Datenmodell als Ergebnis des Entwerfens des Datensystems. Die angepaßte Grundkonzeption als Input zum Entwerfen des Datensystems beinhaltet die als Informationsnachfrage bezeichneten Anforderungen an das zu schaffende Informationssystem (vgl. Lerneinheit ANFOA); dabei handelt es sich primär um Sachziele (vgl. Lerneinheit SACHZ). Der Weg von den Inputs zum Ergebnis des Entwerfens des Datensystems als logisches Datenmodell umfaßt insbesondere die Spezifizierung dieser Anforderungen und das Ableiten des Datenbedarfs aus der Informationsnachfrage. Abbildung WDASY-1 zeigt die Einbettung des Entwerfens des Datensystems in die genannten Inputs und Outputs. Die seitliche Anordnung des Inputs "Systementwürfe anderer Teilprojekte" deutet auf den interaktiven Zusammenhang der Entwurfsarbeiten in allen Teilprojekten hin.

mmmmmmm,

Angepaßte w». %% Grundkonzeption Entwerfen des Datensystems WDASY

Abb. WDASY-1: Inputs und Outputs beim Entwerfen des Datensystems

Beim Entwerfen des Datensystems ist nicht nur der interaktive Zusammenhang der Entwurfsarbeiten in allen Teilprojekten des zu schaffenden Informationssystems zu beachten, sondern auch die Tatsache, daß der Datenentwurf zum planmäßigen Aufbau eines unternehmensweiten Datensystems - und seiner Abbildung als unternehmensweites Datenmodell (abgekürzt: UDM) - beitragen soll. Deshalb ist beim Entwerfen des Datensystems für ein Informationssystem der im

18

Aufgaben der Grobprojektierung

Unternehmen vorhandene Datenbestand (vgl. Lerneinheit DATEM im Band "Informationsmanagement") daraufhin zu überprüfen, ob der Datenbedarf für das zu schaffende Informationssystem ganz oder teilweise durch den vorhandenen Datenbestand gedeckt werden kann. Dadurch soll das Entstehen von Datenredundanz vermieden und Datenkonsistenz erreicht werden. Dies schließt nicht aus, daß einzelne Datenobjekte später mehrfach (z.B. in mehreren lokalen Datenbanken) implementiert werden, wenn die Datenredundanzen und daraus möglicherweise entstehende Dateninkonsistenzen wirkungsvoll kontrolliert werden können. Werkzeuge zur Unterstützung dieser Aufgabe sind für die projektbezogenen Entwurfsergebnisse die Enzyklopädie des verwendeten CASE-Systems (vgl. Lerneinheit WERSP) bzw. ein Datenkatalog-System, in dem die Entitäten eines unternehmensweiten Datenmodells abgebildet sind (vgl. Lerneinheit DAKAT im Band "Informationsmanagement"). Datensichten Aus der Sicht der betrieblichen Aufgabe sind Daten Abbildungen von Elementen der Wirklichkeit oder der Vorstellungswelt des Menschen als Aufgabenträger. Aus der Sicht des Aufgabenträgers interessiert ihre Eigenschaft als Information. Den Informatiker interessiert die Sicht auf physische Datensätze. Aus der Sicht des Techniksystems interessieren die physischen Speichermedien. Für den Wirtschaftsinformatiker ist vor allem der Bereich von Interesse, in dem sich die Sicht des Aufgabenträgers und die Sicht des Informatikers treffen; das ist die logische Ebene der Datensichten. Datenbasen sollten auf der logischen Ebene definiert werden; dies wird hier als der Entwurf des Datensystems verstanden. Datenadministrator

Abb. WDASY-2: Drei-Schema-Konzept des Datensystems (Quelle: Zehnder)

Auf Grund dieser allgemeinen Überlegungen wurde vom ANSI-SPARC-Committee das Drei-Schema-Konzept entwickelt, das aus folgenden Schemata besteht (vgl. Abbildung WDASY-2; statt "Schema" wird auch "Ebene" verwendet): • Das konzeptionelle Schema beschreibt die Datenstruktur auf der logischen Ebene; es gibt die Namen der Datenobjekte und ihre Attribute an und spezifiziert die Beziehungen zwischen den Datenobjekten (auch als logisches Schema bezeichnet). Das konzeptionelle Schema ist Grundlage für den Entwurf der übrigen Schemata. • Im externen Schema erfolgt die Beschreibung der Datenstruktur aus der Sicht der Benutzer ("Benutzersicht", auch als View oder Subschema bezeichnet). Benutzersichten werden aus dem konzeptionellen Schema abgeleitet. Da

WDASY - Entwerfen des Datensystems

19

eine Benutzersicht immer ein Ausschnitt des konzeptionellen Schemas (ein Subschema) ist, weisen beide das gleiche Abstraktionsniveau auf. Weder Schema noch Subschema machen Aussagen über die physische Datenspeicherung. • Im internen Schema wird die Struktur der physischen Datenspeicherung abgebildet; es beinhaltet daher eine formale Beschreibung darüber, wie die Daten gespeichert werden (z.B. wie sie zu Datensätzen angeordnet werden). Das interne Schema enthält auch Angaben darüber, wie auf Datensätze zugegriffen wird (z.B. Zugriffspfade). Der Zusammenhang zwischen den Ebenen wird durch Transformationsregeln hergestellt. Sie legen fest, wie ein bestimmtes Objekt einer Ebene aus einem Objekt (oder mehreren Objekten) einer tieferen Ebene gebildet werden soll. Die Transformationsregeln sind im Datenverwaltungssystem eines Datenbanksystems implementiert. Unterstützt ein Datenbanksystem das Drei-Schema-Konzept, dann sind die logischen Datenstrukturen und die physische Datenorganisation streng voneinander getrennt. Dies ermöglicht sowohl die physische Datenunabhängigkeit (d.h. die Datenorganisation kann verändert werden, ohne daß die logische Datenstruktur verändert werden muß) als auch die logische Datenunabhängigkeit (d.h. die Unabhängigkeit zwischen der logischen Datenstruktur und den Anwendungsprogrammen).

Abb. WDASY-3: Entwurfsprozeß für Datenbanken

Im folgenden wird auf das konzeptionelle Schema eingegangen; externe Schemata und interne Schemata sowie die Transformation zwischen den Schemata werden in der Feinprojektierung behandelt (vgl. Lerneinheit EDASY). Für den Entwurfsprozeß (der mit dem physischen Entwurf abgeschlossen wird) wird dabei die Unterscheidung in konzeptueller Entwurf (auch als sachlogischer Entwurf bezeichnet) und logischer Entwurf vorgenommen. Abbildung WDASY-3 zeigt den Entwurfsprozeß für Datenbanken in dieser Struktur sowie die mit seman-

20

Aufgaben der Grobprojektierung

tisches Datenmodell (in Form eines Entity-Relationship-Diagramms) und mit logisches Datenmodell (in Form einer Hierarchie, eines Netzes oder als Relationenschema) bezeichneten Entwurfsergebnisse. Entwerfen von sachlogischen Datenstrukturen Gegenstand des konzeptuellen Entwurfs ist die Rekonstruktion der Anforderungen, die an das Datensystem auf Grund der fachlichen Aufgaben der potentiellen Benutzer und ihrer persönlichen Arbeitssituation (z.B. Arbeitsstil, Entscheidungsverhalten, Kooperationsfähigkeit) gestellt werden, und ihre präzise, daher auch möglichst formale Beschreibung als semantisches Datenmodell. Die beiden Ansätze zur Bearbeitung dieser Aufgabe sind Konstruktionsansatz und Modellansatz. • Der Konstruktionsansatz geht von der Überlegung aus, daß dem Bilden von empirisch wahren Sätzen eine Normierung der verwendeten sprachlichen Mittel vorausgehen muß. Von einfachen Fachbegriffen des untersuchten Ausschnitts der Wirklichkeit ausgehend, werden mit Hilfe von Konstruktoperatoren Objekttypen und Strukturen von Objekttypen konstruiert; daher wird für den Konstruktionsansatz auch die Bezeichnung Objekttypenmethode verwendet (vgl. Lerneinheit OBTYP). • Der Modellansatz geht von der Annahme aus, daß die für die Anwendungsaufgabe wesentlichen betrieblichen Sachverhalte auch ohne sprachliche Ordnung bereits durch die verwendete Terminologie gegeben sind. Mit Hilfe von Datenmodellen werden diese Sachverhalte und ihre Beziehungen erfaßt und in einer formalen Sprache so abgebildet, daß sie einer Verarbeitung zugänglich sind. Ein typischer Vertreter des Modellansatzes ist die Normalformenlehre (vgl. Lerneinheit NORMA). Die für die Anwendungsaufgabe wesentlichen betrieblichen Sachverhalte werden als gegeben angesehen; sie brauchen "nur noch" durch Normalisierung geordnet und bereinigt zu werden. Der Hinweis auf eine ausführliche Behandlung der Objekttypenmethode und der Normalformenlehre zeigt, daß im folgenden davon ausgegangen wird, diese und weitere Ansätze nicht alternativ zu sehen, sondern in gegenseitiger Abstimmung zu verwenden. Daraus ergibt sich auch, daß die folgenden Erläuterungen knapp gehalten werden können; die methodischen Vertiefungen können als darin "eingehängt" betrachtet werden. Trotzdem ist es zweckmäßig, diese Lerneinheit einmal durchzuarbeiten und dann auf die methodischen Vertiefungen zurück zu kommen. Beschreibungsmittel für Datenstrukturen Für die Abbildung von Datenstrukturen sind formale Beschreibungsmittel erforderlich, mit denen dokumentiert werden kann, in welcher Form die Informationen über die Datenobjekte und ihre Beziehungen gesehen werden sollen. Für logische Datenmodelle werden drei Beschreibungsmittel unterschieden: das hierarchische Datenmodell (wegen der Verbreitung von IMS von IBM heute nur noch von praktischem Interesse), das Netz(werk)modell und das relationale Datenmodell (auch: Relationenmodell). Hierarchisches Datenmodell und Netz(werk)modell sind Graphenmodelle; die Datenstruktur wird als Graph beschrie-

WDASY - Entwerfen des Datensystems

21

ben, dessen Knoten Datenobjekte und dessen Kanten Beziehungen zwischen Datenobjekten sind. Das konzeptionelle Schema konkreter Datenbanksysteme orientiert sich an einem dieser Modelle (z.B. UDS von Siemens/Nixdorf: Netzwerk; DB2 von IBM, ORACLE, INGRES und INFORMIX: relational). Im folgenden werden das hierarchische Datenmodell und das Netz(werk)modell nur kurz charakterisiert, da sie nur noch von untergeordneter Bedeutung sind. Moderne Datenbanksysteme verwenden ein relationales Datenmodell; es wird daher ausführlicher erläutert. * Im hierarchischen Datenmodell wird das Datensystem als Baum (als "Hierarchie") abgebildet; mehrere einfache Hierarchien werden zu mehrstufigen Hierarchien zusammengefügt. Jeder Entitätstyp hat genau einen Vorgänger; er kann mehrere Nachfolger haben. Auf der obersten Hierarchie-Ebene gibt es genau einen Entitätstyp. Entitätstyp, Entität und Attribut werden gleich behandelt. Das hierarchische Modell hat, verglichen mit den anderen Datenmodellen, verarbeitungstechnische Vorteile. Voraussetzung für seine Verwendung ist, daß das Datensystem mit einer Hierarchie ausreichend genau abgebildet werden kann, was im allgemeinen nicht der Wirklichkeit entspricht. 1:1und 1 :n-Beziehungen sind abbildbar, die m:n-Beziehung ist nicht direkt darstellbar; sie muß in mehrere 1:1- und 1 :n-Beziehungen mit der Folge aufgelöst werden, daß Datenredundanz entsteht. • Im Unterschied zum hierarchischen Datenmodell kann im Netz(werk)modell ein Entitätstyp mehrere Vorgänger haben, und es kann mehrere Entitätstypen geben, die keinen Vorgänger haben. Wie im hierarchischen Datenmodell kann jeder Entitätstyp mehrere Nachfolger haben. Entitätstyp, Entität und Attribut werden gleich behandelt. Damit können Datensysteme mit größerer Realitätsnähe abgebildet werden als im hierarchischen Datenmodell; es lassen sich alle Beziehungen zwischen Entitätstypen darstellen. Zur Abbildung der m:n-Beziehung wird ein sogenannter Verbindungstyp oder Verkettungstyp eingeführt, der wie jeder andere Entitätstyp behandelt wird. Die Einfachheit des hierarchischen Modells geht beim Netz(werk)modell verloren, was insbesondere zu einer komplizierten Datenorganisation führt. Wesentliches Merkmal der drei Datenmodelle ist, daß sie sich - wenn auch in unterschiedlicher Weise - an der Anwendungsaufgabe orientieren, also an der Wirklichkeit, die in ein Datensystem abgebildet werden soll. Da sie die semantischen Eigenschaften der Wirklichkeit nur unvollkommen abbilden können, hat sich für die Beschreibung des Ergebnisses des konzeptuellen Entwurfs die Verwendung eines abstrakteren formalen Beschreibungsmittels durchgesetzt, das Entity-Relationship-Diagramm (vgl. Lerneinheit ERMOD). Das Entwerfen des konzeptuellen Datenmodells wird durch die Objekttypenmethode unterstützt und erfolgt in enger Verbindung mit dem Entwerfen des logischen Datenmodells und durch Anwendung der Normalformenlehre. Das konzeptuelle Datenmodell als Entity-Relationship-Diagramm wird mit Hilfe der Datendefinitionssprache des verwendeten Datenbanksystems als logisches Schema dieses Datenbanksystems (heute vornehmlich ein Relationenschema) abgebildet und dann in das interne Schema transformiert (vgl. Lerneinheit EDASY).

22

Aufgaben der Grobprojektierung

Grundsätzlich denkbar ist auch der umgekehrte Weg. Er besteht darin, technischkonstruktiv von den physischen Formen der vorhandenen Datenorganisation auszugehen und daraus das logische und das konzeptuelle Datenmodell zu entwickeln. (Ein Beispiel für diesen Ansatz ist ADABAS, ein relational orientiertes Datenbanksystem.) Im folgenden wird ausschließlich anwendungsorientiert, das heißt von der Anwendungsaufgabe ausgehend, vorgegangen. Relationales Datenmodell Das relationale Datenmodell (auch: Relationenmodell, Relationenschema) beruht auf der Relationentheorie. Als Strukturelement verwendet es lediglich die Relation als eine Menge von Tupeln, die in einer zweidimensionalen Tabelle dargestellt wird (vgl. die Beispiele in Lerneinheit NORMA). Ein Tupel entspricht im Entity-Relationship-Diagramm einer Entität. Jedes Tupel besitzt einen Schlüssel, mit dem es identifiziert werden kann ("Primärschlüssel"). Die Tupel einer Relation werden in den Zeilen der Tabelle, die Attribute in den Spalten der Tabelle dargestellt. Für jedes Attribut einer Relation gibt es einen Wertebereich ("Domäne"). Aus dieser Beschreibung der Relation lassen sich ihre wesentlichen Eigenschaften wie folgt ableiten: • Es gibt keine zwei Tupel einer Relation, die identisch sind. • Die Tupel einer Relation haben keine Ordnung; Vertauschung von Zeilen verändert die Relation nicht. • Die Attribute einer Relation haben keine Ordnung; Vertauschung von Spalten verändert die Relation nicht. • In jedem Feld einer Tabelle gibt es nur einen Wert (unter der Annahme, daß die Relation normalisiert ist). • Alle Werte einer Spalte sind vom gleichen Datentyp. Da es im Relationenmodell nur Relationen gibt, müssen sowohl Entitäten als auch Beziehungen zwischen Entitäten als Relationen modelliert werden. Zur Datenmanipulation werden mengenorientierte und relationale Operationen verwendet, die ganze Relationen ansprechen. Eine mengenorientierte Operation verknüpft zwei Relationen und erzeugt eine neue Relation. Die aus der Mengenlehre bekannten Operationen Vereinigung, Durchschnitt und Differenz können angewendet werden (weil eine Relation der mathematischen Definition der Menge entspricht). Eine relationale Operation ist entweder eine Selektion, eine Projektion oder eine Verbindung. Mit einer Projektion werden aus einer Relation bestimmte Spalten (Attribute mit Attributewerten) angegeben. Mit einer Selektion werden aus einer Relation bestimmte Zeilen (also Tupeln) ausgewählt. Mit einer Verbindung wird eine neue Relation erzeugt, in der alle Attribute der Ausgangsrelationen, die einer angegebenen Bedingung genügen, enthalten sind. In einer anderen Darstellungsform wird eine Relation auf der Typ-Ebene durch ihren Namen sowie die Aufzählung ihrer Attribute, mit Unterstreichen des Primärschlüssel-Attributs, dargestellt. Die Attribute werden durch "," getrennt; "R." wird zur Kennzeichnung des Ausdrucks als Relation verwendet: R. KUNDE (Kunden#. Firmenbezeichnung, Lieferort, ...)

WDASY - Entwerfen des Datensystems

23

Aufgaben beim Entwerfen des Datensystems Ausgehend von diesen grundsätzlichen Überlegungen und der Annahme, daß eine konkrete Anwendungsaufgabe gegeben ist, kann das Entwerfen des Datensystems in fünf Aufgaben gegliedert werden. Abbildung WDASY-4 zeigt die Anordnung der Aufgaben als Arbeitsschritte einer Vorgehensweise, die den Weg von der Anwendungsaufgabe, wie sie in der Grundkonzeption dokumentiert ist, zum logischen Datenmodell beschreibt. Das Rekonstruieren der Fachbegriffe ist mit dem Entwerfen des konzeptuellen Modells identisch.

Bilden von Entitätsmengen Festlegen der Beziehungen zwischen den Entitätsmengen

I

Festlegen der Identifikationsschlüssel Durchführen der Normalisierung Darstellung weiterer Konsistenzbedingungen

mmmmmmm| Logisches

Datenmodell •////////////////////SS////////;/,

Abb. WDASY-4: Vorgehen beim Entwerfen des Datensystems

Erster Arbeitsschritt: Rekonstruieren der Fachbegriffe. Jeder Ausschnitt der Wirklichkeit ist in irgendeiner Weise organisiert. Diese Organisiertheit ist auch Folge eines eingeführten Systems von Fachbegriffen. Einzelnen Objekten der Wirklichkeit sind bestimmte Begriffe des Begriffssystems, einzelnen Vorgängen, Ereignissen und Sachverhalten sind ganze Ausschnitte des Begriffssystems zugeordnet. Das Begriffssystem ist Ausdruck der fachlichen Theorie des betrachteten Ausschnitts der Wirklichkeit. Alle für die betrachtete Aufgabe notwendigen Fachbegriffe werden eindeutig festgelegt, von Störungen und Ungenauigkeiten ihrer Semantik und ihres Aufbaus (insbes. der ihnen zugeordneten Attribute) befreit und durch Entitäten ersetzt. Die Wörter "konstruieren" und "rekonstruieren" werden synonym verwendet, weil "neue" Begriffe in der Regel aus bereits vorhandenen Begriffen entwickelt werden (daher die Ausdrucksweise "rekonstruiert"). Rekonstruierte Fachbegriffe werden als Datenobjekttypen verwendet. (Zur weiteren Erläuterung vgl. Lerneinheit OBTYP.)

24

Aufgaben der Grobprojektierung

Zweiter Arbeitsschritt: Entwerfen der Datenstruktur. Aus den rekonstruierten Fachbegriffen werden die Entitäten herausgearbeitet. Sofern eine Beziehung zwischen zwei Entitäten eine Bedeutung hat, kann auch eine solche Beziehung als Entität definiert werden. Eine Entität wird durch ihre Attribute beschrieben, und es werden die Wertebereiche der Attribute angegeben. Entitäten mit gleichen Attributen werden zu Entitätstypen gruppiert. Die Entitätstypen sind disjunkt, wenn keine Entität in mehr als einem Entitätstyp vorkommt; sonst sind sie überlappend. Wenn sie überlappend sind, ist es immer möglich, einen Entitätstyp als Obermenge zu definieren (z.B. sind die Entitätstypen STUDENT und WISSENSCHAFTLICHES PERSONAL dann überlappend, wenn es Studenten gibt, die als wissenschaftliche Hilfskräfte arbeiten, oder wenn wissenschaftliche Assistenten als Studenten im Doktoratsstudium eingeschrieben sind; der Entitätstyp als Obermenge heißt dann UNTVERSITÄTSANGEHDRIGER). Die Beziehungen werden herausgearbeitet. Zur Beschreibung einer Beziehung zwischen zwei Entitätstypen X und Y wird von gerichteten Beziehungstypen ausgegangen. Ein Beziehungstyp ergibt sich durch Kombination der Assoziation (X,Y) mit der dazu gehörenden Gegenassoziation (Y,X). Vier Beziehungstypen sind von größter Bedeutung (vgl. Abbildung WDASY-5; zur Erläuterung vgl. das Demonstrationsbeispiel). Zur grafischen Darstellung der Beziehungen zwischen zwei Entitätstypen X und Y werden diese durch Linien verbunden, und die Beziehungstypen (auch als Kardinalität der Beziehungen bezeichnet) werden an die Enden der Linien geschrieben. Alle nicht selbstverständlichen Beziehungen werden angeschrieben, wenn erforderlich in beiden Richtungen (vgl. Lerneinheit ERMOD).

Beziehungstyp (X, Y) 1 c m mc

: (einfache Beziehung) : (konditioneile Beziehung) : (multiple Beziehung) : (multipel-konditionelle Beziehung)

Entitäten aus der Menge Y, die jeder Entität aus der Menge X zugeordnet sind genau eine keine oder eine (c = 0/1) mindestens eine (m >= 1) keine, eine oder mehrere (mc >= 0)

Abb. WDASY-5: Typen von Beziehungen (Quelle: nach Zehnder)

Dritter Arbeitsschritt: Festlegen der Identifikationsschlüssel. FUr jeden Entitätstyp wird ein Identifikationsschlüssel festgelegt. Bevorzugt wird ein "natürliches Attribut" als Identifikationsschlüssel, wenn möglich ein mnemotechnisches Attribut. Ist kein geeignetes Attribut vorhanden, wird ein "künstliches" Attribut als Identifikationsschlüssel geschaffen. Dabei sollte auf die im betrieblichen Aufgabensystem bestehenden und daher den Benutzern geläufigen Nummernsysteme zurückgegriffen werden. (Zur weiteren Erläuterung vgl. Lerneinheiten ERMOD und NUMSY.) Vierter Arbeitsschritt: Durchführen der Normalisierung. Ziel der Normalisierung ist es, die Attribute so zu Entitätstypen (und damit zu Relationen) zu ordnen, daß innerhalb einer Relation keine Datenredundanz besteht. Dies erfolgt durch Anwendung der Normalformenlehre. (Zur weiteren Erläuterung vgl. Lerneinheit NORMA.)

WDASY - Entwerfen des Datensystems

25

Fünfter Arbeitsschritt: Festlegen weiterer Konsistenzbedingungen. Der Entwurf wird daraufhin überprüft, ob die bisher modellintern im konzeptionellen Schema formulierten Konsistenzbedingungen ausreichend sind. Im Zusammenhang mit dem Entwerfen des Datensystems geht es um die Sicherung der semantischen Integrität. Konsistenzbedingungen zur Sicherung der semantischen Integrität sind bereits durch den Entwurf der Datenstruktur gegeben, ohne daß sie explizit als solche definiert werden müssen. Konsistenzbedingungen dieser Art beschreiben für einzelne Entitäten, welche Beziehungen zwischen den Entitäten erlaubt und welche Attributewerte zulässig sind. Sie ermöglichen es dem Datenbanksystem zu prüfen, ob Dateneingaben und Datenänderungen korrekt sind. Bei der Entscheidung darüber, welche Integritätsbedingungen in das konzeptionelle Schema zusätzlich aufgenommen werden sollen, ist insbesondere zwischen dem durch die Vermeidung von Fehlern erreichten Nutzen und dem Aufwand für längere Antwortzeiten für die Auswertung der Integritätsbedingungen abzuwägen. Weitere Integritätsbedingungen werden explizit in das konzeptionelle Schema aufgenommen. Zu ihrer Realisierung sind zusätzliche sprachliche Mittel erforderlich (z.B. können in SQL Integritätsbedingungen mit SQL-Befehlen formuliert werden). Ansonsten müssen sie modellextern durch die Anwendungssoftware realisiert werden. Der Entwurfsprozeß kann praktisch nicht manuell erfolgen; er muß durch Werkzeuge unterstützt werden (z.B. Gambit für das Relationenmodell). Die Aufgaben, die von Werkzeugen unterstützt werden, reichen von der Darstellungs- und Zeichenhilfe über das Erkennen rekursiver Beziehungen und das Überwachen der Datenkonsistenz bis zur Dokumentation des Datenmodells. Demonstrationsbeispiel Die an Abbildung WDASY-5 gezeigten Beziehungstypen werden an dem in Abbildung WDASY-6 dargestellten Beispiel näher erläutert. Angenommen, X sei STUDENT und Y sei PRÜFER; dann bedeuten die Beziehungstypen von X auf Y folgendes: • Beziehungstyp 1: Jeder Student hat genau einen Prüfer. • Beziehungstyp c: Jeder Student hat höchstens einen, möglicherweise keinen Prüfer. • Beziehungstyp m: Jeder Student hat mindestens einen Prüfer. • Beziehungstyp mc: Jeder Student hat keinen, einen oder mehrere Prüfer. Da nicht nur die Beziehung von X auf Y, sondern auch die dazu inverse Beziehung von Y auf X interessiert, ergeben sich 16 Beziehungstypen, und zwar: 1:1, l:c, l:m, l:mc; c:l, c:c, c:m, c:mc; m:l, m:c, m:m, m:mc; mc:l, mc:c, mc:m, mc:mc. Da X und Y vertauscht werden können, sind folgende Beziehungstypen symmetrisch: l:c und c:l, l:m und m:l, l:mc und mc:l, c:m und m:c, c:mc und mc:c, m:mc und mc:m. Es verbleiben also zehn Beziehungstypen, von denen 1:1, l:n und m:n die größte praktische Bedeutung haben.

26

Aufgaben der Grobprojektierung X

•

Y

X

•

Y

X

•

Y

X

•

Y

X, y = Entitätstypen

Die Transformation der Datenstruktur im Entity-Relationship-Diagramm in das Relationenschema wird anhand des in Abbildung WDASY-7 dargestellten Beispiels auf der Typ-Ebene gezeigt (zur Darstellung auf der Tabellen- oder Ausprägungsebene vgl. die Abbildungen in Lerneinheit NORMA). Da das Relationenmodell die Unterscheidung zwischen Entität und Beziehung nicht kennt, wird auch die Beziehung LIEFERN als Relation dargestellt. Eine n:m-Beziehung erfordert eine eigene Relation, während eine l:n-Beziehung durch Aufnahme des Schlüsselattributs des "übergeordneten" Entitätstyps in die Relation des untergeordneten Entitätstyps ausgedrückt wird. Der ursprüngliche Schlüssel der untergeordneten Relation braucht dann nur noch innerhalb des übergeordneten Schlüssels zu identifizieren (z.B. wird innerhalb einer Rechnungs# die Positions# fortlaufend vergeben).

Abb. WDASY-7: Datenstruktur als Entity-Relationship-Diagramm

Das dem Entity-Relationship-Diagramm 1 in Abbildung WDASY-6 entsprechende Relationenschema sieht wie folgt aus: R. LIEFERANT (Lieferanten#. Lieferantenname, Umsatz, Liefertreue, ...) R. ARTIKEL (Artikel#, Artikelbezeichnung, Lagerbestand, ...) R. LIEFERN (Lieferanten#. Artikel#. Umsatz, Lieferdatum, ...)

WDASY - Entwerfen des Datensystems

27

Methodenverweise Vorgehensweise bei der Grobprojektierung (Lerneinheit VGROB); Objekttypenmethode (Lerneinheit OBTYP); Entity-Relationship-Modell (Lerneinheit ERMOD); Normalformenlehre (Lerneinheit NORMA); Nummemsysteme (Lerneinheit NUMSY). Kontrollfragen 1. 2. 3. 4. 5.

Welche Sichtweisen auf Daten werden unterschieden? Welches Schema ist Gegenstand des Entwerfens des Datensystems? Welche Beschreibungsmittel stehen zur Dokumentation von Datenstrukturen zur Verfügung? Wie kann das Entwerfen des Datensystems in Arbeitsschritte gegliedert werden? Welcher Unterschied besteht zwischen dem konzeptuellen Modell und dem logischen Modell des Datensystems?

Quellenliteratur Date, C. J.: An Introduction to Database Systems. Vol. I. 5. Ed., Addison-Wesley, Reading/ Mass. 1990 Gabriel, R. und Röhrs, H.-P.: Datenbanksysteme. Konzeptionelle Datenmodellierung und Datenbankarchitekturen. Springer Verlag, Berlin et al. 1994 Schlageter, G. und Stucky, W.: Datenbanksysteme: Konzepte und Modelle. 2. A., Verlag Teubner, Stuttgart 1983 Schrefl, M.: Grundlagen von Datenbanksystemen. Vorlesungsunterlagen WS 1993/94, Institut für Wirtschaftsinformatik/Data & Knowledge Engineering, Linz 1993 Zehnder, C. A.: Informationssysteme und Datenbanken. 5. A., Verlag Teubner, Stuttgart 1989 Vertiefungsliteratur Lusti, M.: Daten und Datenbanken - Eine anwendungsorientierte Einführung. Springer Verlag, Berlin et al. 1989 Niedereichholz, J. und Kaucky, G.: Datenbanksysteme. Konzepte und Management. 4. A., Physica Verlag, Heidelberg 1992 Scheer, A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. 4. A., Springer Verlag, Berlin et al. 1994 Vetter, M.: Aufbau betrieblicher Informationssysteme mittels konzeptioneller Datenmodellierung. 6. A„ Verlag Teubner, Stuttgart 1990

WMESY - Entwerfen des Methodensystems Lernziele Sie kennen die Aufgaben beim Entwerfen des Methodensystems. Sie erkennen, daß verschiedene Sichtweisen auf Methoden notwendig sind und können das Entwerfen des Methodensystems in diese Sichtweisen einordnen. Sie kennen eine Systematik der Methoden ("Methodenklassen") und können die charakteristischen Merkmale dieser Klassen mit eigenen Worten wiedergeben. Sie können den Weg von der Aufgabe zum logischen Methodenmodell in Arbeitsschritte gliedern. Definitionen und Abkürzungen Algorithmus (algorithm) = ein Lösungsverfahren für eine Klasse gleichartiger Aufgaben, bestehend aus einer eindeutig definierten, endlichen Folge von Operationen. Aufgabenstrukturierbarkeit (task structuring ability) = die Eigenschaft einer Aufgabe, in eine Menge elementarer Tätigkeiten zerlegt werden zu können. Synonym: Formalisierbarkeit. Aufgabenstrukturierung (task structuring) = die Abbildung einer Aufgabe durch eine geordnete Menge von elementaren Tätigkeiten. Expertensystem (expert system) = ein wissensbasiertes System zur Lösung nicht oder nur schlecht strukturierbarer Aufgaben. F I F O = Akronym für First-In-First-Out. Heuristik (heuristics) = eine Methode, die bei der Bearbeitung komplexer Probleme mit Hoffnung auf, aber ohne Garantie von Erfolg eingesetzt wird. L I F O = Akronym für Last-In-First-Out. Methode (method) = ein auf einem System von Regeln aufbauendes Problemlösungsverfahren, dessen Zweck es ist, die als Ausgabe geforderten Datenstrukturen aus den als Eingabe verfügbaren Datenstrukturen zu erzeugen. Methodenbasis (method base) = eine Menge von Methoden, die für eine gegebene Aufgabe aus gegebenen Funktionsanforderungen abgeleitet wird. Methodenkonsistenz (method consistency) = die logische Widerspruchsfreiheit der Methoden, die im Methodenmodell abgebildet sind. Methodenmodell (method model) = ein Beschreibungsmittel zur Darstellung des Methodensystems auf der logischen Ebene (des konzeptionellen Schemas). Synonyme: logisches Methodenmodell, Funktionenmodell, Prozeßmodell. Methodenredundanz (method redundancy) = das mehrmalige Vorhandensein der gleichen Methoden in einer Methodenbasis. Modell (model) = 1) die vereinfachende Abbildung eines Ausschnitts der Wirklichkeit mit einem bestimmten Beschreibungsmittel; 2) eine geordnete Menge von Methoden zur Lösung einer Aufgabe. Optimierungsmodell (operations research model) = ein mathematisches Modell zum Problemlösen, insbesondere für Entscheidungsaufgaben. OR = Akronym für Operations Research. Simulation (Simulation) = das zielgerichtete Experimentieren an Modellen. Wissensmodell (knowledge model) = die Abbildung von Wissen in einem logischen Modell als Ergebnis der Wissensakquisition.

WMESY - Entwerfen des Methodensystems

29

Schnittstellen beim Entwerfen des Methodensystems Die Schnittstellen beim Entwerfen des Methodensystems sind durch die nachfolgend beschriebenen Inputs und Outputs gekennzeichnet. Inputs zum Entwerfen des Methodensystems sind: • die angepaßte Grundkonzeption (vgl. Lerneinheit AFEIN) als Ergebnis der Feinstudie; • die Systementwürfe in den Teilprojekten Datensystem (vgl. Lerneinheit WDASY), Arbeitsorganisation (vgl. Lerneinheit WAORG) und Transportsystem (vgl. Lerneinheit WTRAN). Outputs des Entwerfens des Methodensystems sind: • der Systementwurf im Teilprojekt Methodensystem, durch den Entwurfsentscheidungen in anderen Teilprojekten beeinflußt werden; • das logische Methodenmodell (bzw. das logische Wissensmodell) als Ergebnis des Entwerfens des Methodensystems. Die "angepaßte Grundkonzeption" als Input zum Entwerfen des Methodensystems beinhaltet nur globale Vorstellungen über die Anforderungen an die Gestaltung der Methoden im zu schaffenden Informationssystem (vgl. Lerneinheit ANFOA); dabei handelt es sich in erster Linie um Sachziele (vgl. Lerneinheit SACHZ). Der Weg von den Inputs zum Ergebnis des Entwerfens des Methodensystems als logisches Methodenmodell umfaßt insbesondere die Spezifizierung dieser Anforderungen, das Ableiten der Methodenbedarfe aus der Informationsnachfrage und das Entwerfen der Methoden aus der Datensicht. Abbildung WMESY-1 zeigt die Einbettung des Entwerfens des Methodensystems in die genannten Inputs und Outputs. Die seitliche Anordnung des Inputs "Systementwürfe anderer Teilprojekte" deutet auf den interaktiven Zusammenhang der Entwurfsarbeiten in allen Teilprojekten hin.

Entwerfen des Methodensystems WMESY Logisches Methodenmodell

M l %-gra

tmi

S i l

fij

^¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿S'

Abb. WMESY-1: Inputs und Outputs beim Entwerfen des Methodensystems

Beim Entwerfen des Methodensystems ist nicht nur der interaktive Zusammenhang der Entwurfsarbeiten in allen Teilprojekten (insbesondere der Entwurfsarbeiten im Datensystem) des zu schaffenden Informationssystems zu beachten, sondern auch die Tatsache, daß der Methodenentwurf zum planmäßigen Aufbau

30

Aufgaben der Grobprojektierung

eines organisationsweiten Methodensystems beitragen soll. Deshalb ist beim Entwerfen des Methodensystems für ein Informationssystem der im Unternehmen vorhandene Methodenbestand (vgl. Lerneinheit ANWEN im Band "Informationsmanagement") daraufhin zu überprüfen, ob der Methodenbedarf für das zu schaffende Informationssystem ganz oder teilweise durch den vorhandenen Methodenbestand gedeckt werden kann. Dadurch soll das Entstehen von Methodenredundanz vermieden und Methodenkonsistenz erreicht werden. Dies schließt nicht aus, daß einzelne Methoden später mehrfach (z.B. in mehreren Anwendungsprogrammen) implementiert werden, wenn die Redundanzen und daraus entstehende Inkonsistenzen wirkungsvoll kontrolliert werden können. Werkzeuge zur Unterstützung dieser Aufgabe sind für die projektbezogenen Entwurfsergebnisse die Enzyklopädie des verwendeten CASE-Systems (vgl. Lerneinheit WERSP) bzw. ein Datenkatalog-System für den im Unternehmen vorhandenen Methodenbestand (vgl. Lerneinheit DAKAT im Band "Informationsmanagement"). Methodensichten Aus der Sicht der betrieblichen Aufgabe ist eine Methode ein auf einem System von Regeln aufbauendes Problemlösungsverfahren. Aus der Sicht des Benutzers interessiert die Eigenschaft der Methode, eine gewünschte Information aus einer gegebenen Menge von Daten zu produzieren. Den Informatiker interessiert die Methode aus der Sicht der Anwendungssoftware-Entwicklung für Datenverarbeitungssysteme oder für wissensbasierte Systeme. Aus der Sicht der Techniksysteme interessieren die physischen Speichermedien für Methoden (also für Anwendungssoftware). Für den Systemplaner von Interesse ist der Bereich, in dem sich die Sicht des Benutzers und die Sicht des Informatikers treffen; das ist die logische Ebene der Sicht auf Methoden. Methodenbasen sollten zunächst auf der logischen Ebene definiert und erst daran anschließend implementiert werden. Das Definieren von Methodenbasen auf der logischen Ebene wird als Entwerfen des Methodensystems bezeichnet. Auf Grund dieser allgemeinen Überlegungen, wird in Analogie zum Drei-Schema-Konzept für Daten (vgl. Lerneinheit WDASY) ein Drei-Schema-Konzept für Methoden definiert: • Das konzeptionelle Schema ist der Entwurf des Methodensystems auf der logischen Ebene; es gibt einen Überblick und ist Grundlage für den Entwurf der übrigen Schemata. • Das Methodensystem wird verschiedenen Benutzern zugänglich gemacht; jede Benutzersicht entspricht einem externen Schema (vgl. Lerneinheit EMESY). • Das interne Schema bildet die Strukturen der physischen Methodenspeicherung ab. Abbildung WMESY-2 zeigt das Drei-Schema-Konzept des Methodensystems. In Analogie zum Datenadministrator beim Drei-Schema-Konzept des Datensystems wird der für das Methodensystem Verantwortliche als Methodenadministrator bezeichnet. Die Einführung dieser Rolle ist auch aus der Sicht der Praxis von großer Bedeutung, da in den meisten Unternehmen erfahrungsgemäß keine klaren Zuständigkeiten für die betriebswirtschaftlichen und technischen Methoden

WMESY - Entwerfen des Methodensystems

31

bestehen. (Ist z.B. die Instanz "Organisation" - wenn überhaupt vorhanden - oder die "DV-Organisation" zuständig, oder sind die Linienabteilungen, in denen die Methodenanwendung erfolgt, für die Methodenadministration verantwortlich? Kann z.B. das Controlling für die Methodenadministration zuständig sein, zumindest für die betriebswirtschaftlichen Methoden, und welche Instanz ist dann für die primär technischen Methoden zuständig?) Methodenadministrator

Abb. WMESY-2: Drei-Schema-Konzept des Methodensystems

Die Analogie zwischen Datensystem und Methodensystem deutet auf die enge Verbindung beider hin, die wie folgt erläutert werden kann: • Jede Methode braucht Daten, um angewendet werden zu können; sie braucht nicht irgendwelche Daten, sondern die Daten müssen zur Methode passen (Methodenadäquanz der Daten). • Daten brauchen Methoden, um zu Information verarbeitet werden zu können; sie brauchen nicht irgendwelche Methoden, sondern die Methoden müssen zu den Daten passen (Datenadäquanz der Methoden). Beim Verfolgen des datenorientierten Ansatzes (vgl. Lerneinheit WDASY) muß offensichtlich der zweite Gesichtspunkt im Vordergrund stehen, das heißt die Methoden müssen so entworfen werden, daß sie der Forderung nach Datenadäquanz genügen. Für die Beschreibung von Datensystemen stehen verschiedene Beschreibungsmittel ("Datenmodelle") zur Verfügung. Vergleichbare Hilfsmittel für die Beschreibung von Methodensystemen gibt es nicht. Der Weg zum logischen Methodenmodell ist daher - verglichen mit dem Weg zum logischen Datenmodell - verhältnismäßig unstrukturiert. Die Forderung, das logische Methodenmodell für jede Anwendung und letztlich unternehmensweit zu entwerfen, besteht unabhängig davon, welcher Bereitstellungsweg für die Implementierung gewählt wird: selbsterstellte oder fremderstellte Anwendungssoftware oder Standard-Anwendungssoftware. Bei einem Wechsel der Implementierungsform (z.B. beim Ersatz selbsterstellter Anwendungssoftware durch Standard-Anwendungssoftware) kann das logische Methodenmodell die Erhaltung des Methodenwissens sichern, und es kann als Referenzmodell verwendet werden.

32

Aufgaben der Grobprojektierung

Aufgaben beim Entwerfen des Methodensystems Gegenstand des Entwerfens des Methodensystems ist das logische Modell des Methodensystems, also die Entscheidung darüber, welche Methode(n) für welche betriebliche(n) Aufgabe(n) als Problemlösungsverfahren verwendet werden soll(en), unabhängig davon, ob es sich um systemunterstützte betriebliche Aufgaben oder um nicht systemunterstützte betriebliche Aufgaben handelt (vgl. Abbildung WAORG-3). Bezüglich der systemunterstützten Aufgaben ist nur die jeweilige Sachaufgabe (und nicht die Interaktionsaufgabe) für das Methodensystem von Bedeutung. Mit dem Entwerfen von Arbeitsabläufen (vgl. Lerneinheit WAORG) werden Problemlösungsverfahren für größere Aufgabenkomplexe geschaffen (z.B. für die Auftragsbearbeitung im Vertrieb); diese werden jedoch nicht als Methoden im Sinn des Methodensystems verstanden. Das Entwickeln der Arbeitsabläufe (vgl. Lerneinheit EAORG) läßt die Antwort nach den Methoden offen. So sagt zum Beispiel die Verrichtungsfolge der Objekt/Verrichtungs-Kombination "Materialbedarf ermitteln" und dann "Material bestellen" nichts über die zur Bedarfsermittlung anzuwendende Methode oder alternative Methoden aus. Gefragt sind Problemlösungsverfahren für eng abgegrenzte und präzise beschreibbare betriebliche Aufgaben (wie z.B. für die Aufgabe "Bedarfsermittlung"). Die Entscheidung über die zu verwendenden Methoden und ihre Zuordnung auf betriebliche Aufgaben erfordert ein grundlegendes Verständnis für die Art der betrieblichen Aufgabe einerseits und für die Problemlösungsfahigkeit der verfügbaren Methoden andererseits. Bezüglich der Art der betrieblichen Aufgabe sind deren Strukturiertheit bzw. Strukturierbarkeit ("Aufgabenstrukturierbarkeit") und Veränderlichkeit von primärem Interesse. Davon ausgehend, ist über die Aufgabenstrukturierung zu entscheiden, das heißt darüber, ob schwach strukturierte Aufgaben mit geringer Veränderlichkeit formalisiert werden sollen. In Abhängigkeit von der Aufgabenstrukturierung ist insbesondere die grundlegende Vorgehensweise beim Zuordnen von Problemlösungswissen (allgemeines Problemlösungswissen und Faktenwissen) auf Aufgabenträger und Sachmittel zu klären. Hierbei sind die grundsätzlichen Alternativen "klassische Datenverarbeitung" und "Wissensverarbeitung" zu berücksichtigen sowie die Alternative, Problemlösungswissen nur "im Kopf des menschlichen Aufgabenträgers" zu halten, also nicht in die Methodenbasis abzubilden. Strukturiertheit und Veränderlichkeit Eine betriebliche Aufgabe ist jede aus dem Leistungsprogramm einer Organisation abgeleitete Teilleistung ihrer Struktureinheiten bzw. der in diesen tätigen Aufgabenträger im Sinn von Aufforderungen, an bestimmten materiellen oder immateriellen Objekten ("Aktionsobjekte") bestimmte körperliche oder geistige Verrichtungen ("Aktionsarten") durchzuführen. Die betriebliche Aufgabe hat den Charakter eines organisatorischen Basiselements; sie läßt sich nach zwei Merkmalen systematisieren: nach der Strukturiertheit und nach der Veränderlichkeit (vgl. Abbildung WMESY-3).

WMESY - Entwerfen des Methodensystems

33

• Strukturiertheit: Eine Aufgabe ist strukturiert (oder geschlossen), wenn die Art ihrer Durchführung dem Aufgabenträger vollständig vorgegeben ist; sonst ist sie unstrukturiert (oder offen). • Veränderlichkeit: Eine Aufgabe ist umso veränderlicher, j e häufiger und j e weniger vorhersehbar Änderungen bei Qualität, Terminen, Mengen und Preisen bei der Durchführung der Aufgabe auftreten.

I

Typ A

TypB

TypC

TypD

3

% o -o

>u

60 G

•c

stark

schwach

Strukturiertheit Abb. WMESY-3: Arten betrieblicher Aufgaben (Quelle: nach Picot/Franck)

Die Frage, welche Methoden Elemente eines Methodensystems sind, hängt erstens von den zu unterstützenden betrieblichen Aufgaben ab, also davon, welche Aufgaben Teil des Aufgabensystems sind, für das ein Informationssystem geschaffen werden soll (vgl. Lerneinheit SZIEL), und zweitens von der Art der Aufgaben bezüglich Strukturiertheit und Veränderlichkeit. Aufgaben vom Typ A und vom Typ C sind stark strukturiert; sie eignen sich grundsätzlich gut zur Verwendung von Methoden der Methodenklasse Algorithmus. Aufgaben vom Typ B und vom Typ D sind schwach strukturiert; sie eignen sich daher grundsätzlich nur zur Verwendung von Methoden der Methodenklasse Heuristik. Wegen der großen Veränderlichkeit der Aufgaben vom Typ A und vom Typ B kann es zweckmäßig sein, auf die Verwendung von Algorithmen (Typ A) zu verzichten und (nur) Heuristiken zu verwenden bzw. auf eine Systemunterstützung (Typ B) zu verzichten und das Problemlösungsverfahren dem Menschen als Aufgabenträger zu überlassen. Aufgaben vom Typ D können ganz oder in Teilen stärker strukturiert werden; diese Eigenschaft der Aufgaben ist gemeint, wenn von Formalisierbarkeit oder Aufgabenstrukturierbarkeit gesprochen wird. Das ist so zu verstehen, daß alternativ zu Heuristiken auch Algorithmen als Problemlösungsverfahren verwendet werden können, wenn eine stärkere Formalisierung oder Strukturierung beabsichtigt ist oder zumindest billigend in Kauf genommen wird. In diesem Fall ist die Aufgabe als Realproblem schwach strukturiert, als modelliertes Formalproblem aber stärker strukturiert. Umgekehrt können für Aufgaben vom Typ A alternativ zu Algorithmen auch Heuristiken als Problemlösungsverfahren ver-

34

Aufgaben der Grobprojektierung

wendet werden, wenn eine geringere Formalisierung oder Strukturierung beabsichtigt ist oder zumindest billigend in Kauf genommen wird. In diesem Fall ist die Aufgabe als Realproblem stark strukturiert, als modelliertes Formalproblem aber schwächer strukturiert. Diese Überlegungen lassen erkennen, daß es im Entscheidungsspielraum des Systemplaners liegt, ob betriebliche Aufgaben durch das Methodensystem stark oder schwach strukturiert werden. Es darf jedoch nicht verkannt werden, daß ein allgemeiner Trend zu mehr Aufgabenstrukturierung besteht, der auf verschiedene Ursachen zurückzuführen ist (z.B. auf die zunehmende Formalisierung von Aufgaben, vgl. Lerneinheit WAORG, und auf die zunehmende Verwendung von Standard-Anwendungssoftware). Die Entscheidung über die Aufgabenstrukturierung und damit über die anzuwendenden Methoden hängt von dem erwähnten Zwillingscharakter von Methodensystem und Datensystem ab (z.B. wird eine mögliche Aufgabenstrukturierung deshalb nicht gewählt, weil die daraus resultierende Methode Daten erfordert, die nicht oder nicht wirtschaftlich vertretbar zur Verfügung gestellt werden können). Sie ist außerdem von der gewollten Arbeitsorganisation abhängig (z.B. wird eine mögliche Aufgabenstrukturierung deshalb nicht gewählt, weil sie dem menschlichen Aufgabenträger keine kognitiven Elemente des Arbeitsinhalts ermöglichen würde). Methoden und Methodenklassen Im vorangegangenen Abschnitt wurden Algorithmus und Heuristik als Bezeichnungen für Methoden benutzt, deren Verwendung für bestimmte Aufgabentypen angemessen bzw. nicht angemesen ist. Methoden für betriebliche Aufgaben können grundsätzlich in die beiden Methodenklassen "Algorithmen" und "Heuristiken" eingeordnet werden; die Übergänge zwischen beiden sind allerdings fließend. Eine Methode, die nicht eindeutig der einen oder der anderen Methodenklasse zugeordnet werden kann, läßt sich durch Zerlegung der Aufgabe, auf die sie angewendet wird, präziser fassen. Zum Beispiel enthält die Methode, die zur Bearbeitung der betrieblichen Aufgabe "Angebotserstellung" verwendet wird, sowohl algorithmische als auch heuristische Methodenteile (weil z.B. die Aufgabe sowohl aus stark als auch aus schwach strukturierten Aufgabenteilen besteht). Neben den in den Definitionen genannten Merkmalen, können Algorithmus und Heuristik wie folgt näher erläutert werden. • Ein Algorithmus ist ein Problemlösungsverfahren für eine Klasse gleichartiger Aufgaben, bestehend aus einer eindeutig definierten, endlichen Folge von Operationen, die in endlicher Zeit ausgeführt werden können ("endlicher Algorithmus"). Algorithmisches Problemlösen ist daher ein linearer Prozeß. Die Bezeichnung wurde nach dem Namen des arabischen Mathematikers AI Chwarismi gebildet. Eigenschaften eines Algorithmus sind Determiniertheit, Allgemeinheit und Endlichkeit. • Eine Heuristik ist ein Problemlösungsverfahren, das auf eine Förderung der Interaktion zwischen den an der Problemlösung Beteiligten ausgerichtet ist; sie kann nicht die Problemlösung liefern, sondern nur den Problemlösungsprozeß unterstützen. Heuristisches Problemlösen ist daher immer ein nicht-linearer Prozeß. Die Bezeichnung ist vom griechischen Wort heurein (= finden) abgeleitet. Je nachdem, ob primär stochastische Methoden oder primär determini-

WMESY - Entwerfen des

Methodensystems

35

stische Methoden verwendet werden, wird von stochastischer Heuristik bzw. von deterministischer Heuristik gesprochen. Zwei weitere Begriffe bezeichnen Methodenklassen und sind daher für das Entwerfen des Methodensystems von Bedeutung: Optimierungsmodell (oder kurz: Optimierung) und Simulationsmodell (oder kurz: Simulation). • Ein Optimierungsmodell ist ein mathematisches Modell. Die Konstruktion und Verwendung eines Optimierungsmodells setzt voraus, daß das zu lösende Problem ("Realproblem") in ein mathematisches Problem ("Formalproblem") übertragen werden kann. Auf dieses Formalproblem lassen sich verschiedene mathematische Methoden zur Problemlösung anwenden, das heißt, es läßt sich ein mathematisches Modell entwickeln. Da jede mathematische Methode ein Algorithmus ist, ist das Optimierungsmodell der Methodenklasse "Algorithmus" zuzuordnen bzw. stellt es in dieser Methodenklasse einen besonderen Methodentyp dar, nämlich den des mathematischen Algorithmus (vgl. Lerneinheit OPMOD). • Ein Simulationsmodell wird vor allem dann eingesetzt, wenn analytische und numerische Methoden (also: Algorithmen) versagen, weil die Wirklichkeit zu komplex und/oder zu kompliziert ist, um als ein geschlossen lösbares Formalproblem abgebildet werden zu können. Kennzeichnend für die Simulation ist die Problembezogenheit, das heißt an einem konkreten System wird ein konkretes Problem mit dem Ziel untersucht, eine Problemlösung zu finden oder zumindest ein besseres Verständnis für das Problem zu gewinnen, um es dann lösen zu können. Simulationsmodelle sind daher zumeist stochastische Modelle; sie stellen ebenfalls keine besondere Methodenklasse dar, sondern verwenden sowohl Algorithmen als auch Heuristiken zum Problemlösen (vgl. Lerneinheit SIMUL). Methodenklassen und Systemkonzepte Das Methodensystem für betriebliche Aufgaben ist durch zwei Methodenklassen gekennzeichnet: Algorithmus und Heuristik. Zur Realisierung der Methodenklassen können drei Systemkonzepte unterschieden werden: Datenverarbeitungssystem, Datenbanksystem und wissensbasiertes System. Algorithmen werden in einem Datenverarbeitungssystem verwendet. Mit Hilfe einer prozeduralen Programmiersprache werden sie als Anwendungsprogramm implementiert. Allgemeines Problemlösungswissen und Faktenwissen werden als Algorithmus abgebildet. Das Datenverarbeitungssystem erwartet die Vorgabe einer speziellen Aufgabe aus der durch den Algorithmus abgebildeten Aufgabenklasse ("Dateneingabe"), löst die Aufgabe durch Ausführen der Anweisungen des Algorithmus und liefert nach endlich vielen Operationen das Ergebnis ("Datenausgabe"). Das modellierte Formalproblem ist in einem Datenverarbeitungssystem immer stark strukturiert. Dementsprechend muß auch die Aufgabe stark strukturiert sein. Heuristiken werden in einem Datenbanksystem verwendet, wenn einfache Operationen auf einer Datenbasis ausgeführt werden, die mit Hilfe einer Datenmanipulationssprache formuliert wurden. Das Datenbanksystem verwaltet Fak-

36

Aufgaben der Grobprojektierung

tenwissen, auf das mit Retrieval-Mechanismen zugegriffen wird. Im Grenzfall werden Daten nur abgefragt ("Abfragesprache") und unverändert ausgegeben; die Problemlösung selbst wird vom Benutzer ohne Systemunterstützung bewerkstelligt. Die Aufgabe ist nicht oder nur schwach strukturiert. Auch ein Datenverarbeitungssystem kann Benutzer eines Datenbanksystems sein. Eine spezielle Form des Datenbanksystems ist das Entscheidungsunterstützungssystem (abgekürzt: EUS). Damit ist ein Informationssystem gemeint, dessen primärer Zweck es ist, Benutzer in ihrer Rolle als Entscheider zu unterstützen, indem es die Daten zur Verfügung stellt, die für die Informationsgewinnung zur Abwicklung von Entscheidungsprozessen benötigt werden. Die Entscheidungsunterstützung kann sich grundsätzlich auf jede Phase des Entscheidungsprozesses und auf jede Art von Entscheidungsaufgabe beziehen. In erster Linie ist mit EUS ein Informationssystem zur Unterstützung von Entscheidungen gemeint, und zwar sowohl für stark strukturierte und meist wenig veränderliche Aufgaben ("Routineentscheidungen"), als auch für schwach strukturierte und meist stark veränderliche Aufgaben ("Führungsentscheidungen"). Um Entscheidungsunterstützung bieten zu können, muß auf bestimmte Eigenschaften von EUS besonderer Wert gelegt werden (z.B. auf die Verfügbarkeit von Methoden, mit denen mögliche Konsequenzen von Entscheidungen "durchgespielt" werden können). Daher sind für EUS sowohl Optimierungsmodelle als auch Simulationsmodelle von methodischer Bedeutung. Spezielle Formen von EUS, deren Eigenschaften sich teilweise überlappen, sind Multi Criteria Decision Support System (MCDSS), Group Decision Support System (GDSS), Mathematical Planning System (MPS) und Executive Support System (ESS) bzw. Executive Information System (EIS); deutschsprachige Bezeichnungen haben sich noch nicht eingebürgert. • MCDSS bieten dem Benutzer Entscheidungsmodelle, die bei der Optimumbestimmung von einer Menge von Entscheidungskriterien ausgehen (z.B. Nutzwertmodelle, vgl. Lerneinheit NUTZW). • GDSS unterstützen die Entscheidungsfindung in Gruppen (mehrpersonale Entscheidungsprozesse); sie sind in der Regel auch multikriteriell. Im Unterschied zu anderen EUS muß ein GDSS - wegen der Beteiligung mehrerer Personen - Ressourcen für die Gruppenarbeit zur Verfügung stellen (insbes. zur Unterstützung von Kooperation). • MPS stellen dem Entscheider Programme zur Verfügung, die (auch) mathematische Modelle und Suchalgorithmen abbilden. • ESS bzw. EIS stellen sehr leichte Benutzbarkeit und starke Orientierung auf Grafik-Anwendungen in den Vordergrund, sodaß jede Führungskraft in der Lage ist, die Informationsnachfrage aus vorhandenen Datenbasen - ohne Hinzuziehung von Unterstützungspersonal - zu decken. Ein wissensbasiertes System zielt auf den Typ von Aufgaben ab, der durch schwache Strukturiertheit und geringe Veränderlichkeit gekennzeichnet ist (Typ D). Es steht gewissermaßen "zwischen" Datenverarbeitungssystem und Datenbanksystem. Es soll komplexeres prozedurales Wissen als in Anwendungsprogrammen verwendet werden können; dieses Wissen soll - wie in Datenbanken für unterschiedliche Aufgaben verwendbar sein. Allgemeines Problemlösungs-

WMESY - Entwerfen des Methodensystems

37

wissen wird - unabhängig vom Faktenwissen - als "Inferenzmechanismus", Faktenwissen wird als "Wissensbasis mit Repräsentationsschema" in die Methodenbasis abgebildet (vgl. Abbildung SWISS-3 sowie die Erläuterungen dazu). In einem wissensbasierten System ist die Aufgabe als modelliertes Formalproblem immer schwach strukturiert; deshalb bietet sich dieses Systemkonzept für schwach strukturierte Realprobleme an. Ein wissensbasiertes System soll dem Aufgabenträger "lediglich" Hilfestellung zur Beurteilung von Handlungsalternativen geben, sodaß er in der Lage ist, unter Berücksichtigung weiterer Daten (meist qualitativer Art) und der menschlichen Urteilsfähigkeit, eine optimale Handlungsalternative zu ermitteln. Diese Aufgaben können als "halbstrukturiert" bezeichnet werden; es handelt sich vornehmlich um Entscheidungsaufgaben. Auch ein wissensbasiertes System kann Benutzer eines Datenbanksystems sein. Aufgaben, für die sich Expertensysteme nach heute verbreiteter Auffassung eignen, sind Planungsaufgaben mit globalen Randbedingungen, Überwachungs- und Steuerungsaufgaben sowie Aufgaben, für die eine Wissensbasis mit "flachem Wissen" ausreicht. • Planungsaufgaben mit globalen Randbedingungen sind Optimierungsaufgaben etwa der folgenden Art: Vernetze alle Arbeitsplätze so, daß jeder Mitarbeiter mit jedem kommunizieren kann, halte aber die Kosten der Vernetzung auf einem Minimum. • Überwachungs- und Steuerungsaufgaben sind durch Daten gekennzeichnet, die sich in der Zeit verändern, und dadurch, daß Daten miteinander verglichen werden (z.B. Daten der Periode n mit Daten der Periode n+1). Heutige Expertensysteme können den Faktor Zeit nicht berücksichtigen, sodaß nur solche Überwachungs- und Steuerungsaufgaben unterstützt werden, die durch eine Momentaufnahme ihrer Daten beschrieben werden können. • Flaches Wissen bedeutet, daß nur Korrelationen, Heuristiken, Definitionen oder Kausalbeziehungen in einer Wissensbasis beschrieben werden können, aber nicht detaillierte fachgebietsspezifische Theorien. Dies ist auf die Verwendung von Regeln zurückzuführen. Daher wird versucht, Regeln mit anderen Formalismen der Wissensrepräsentation zu ergänzen bzw. durch andere zu ersetzen. Die damit erreichbare Verbesserung der Wissenstiefe ist von einer Verringerung der Einfachheit der Wissensrepräsentation begleitet. Für den Entwurf wissensbasierter Systeme ist das bei Datenverarbeitungssystemen und Datenbanksystemen bewährte Prototyping (vgl. Lerneinheit PROTY) nicht geeignet, weil die Erfassung und Interpretation von Expertenwissen ("Wissensakquisition") und die adäquate Modellierung von Wissen im Vordergrund stehen. Die Unterschiedlichkeit der Entwurfsmethodik kommt auch in den verwendeten Bezeichnungen - nämlich Knowledge Engineering im Unterschied zu Software Engineering - zum Ausdruck. Die Methodik des Knowledge Engineering ist allerdings noch wenig entwickelt, weshalb beispielsweise bereits bei der Wissensakquisition eine (zu) enge Bindung an das Implementierungswerkzeug erfolgt, insbesondere bezüglich der Form der Wissensdarstellung. Es wird versucht, Entwurf und Implementierung durch den Entwurf des logischen Wissensmodell zu entkoppeln; dieses spielt dann eine ähnliche Rolle wie das logische Methodenmodell (und das logische Datenmodell) beim klassischen Entwurfsansatz des Software Engineering.

38

Aufgaben der Grobprojektierung

Größere Aufgabensysteme sind häufig dadurch gekennzeichnet, daß ein Teil der Aufgaben eine starke Strukturiertheit besitzt, die auch den Planungszielen entspricht und daher nicht verändert werden soll; ein anderer Teil besitzt dagegen nur eine schwache Strukturiertheit oder soll auf Grund der Planungsziele nur schwach strukturiert sein. In diesem Fall sind die Systemkonzepte keine Alternativen, sondern sie ergänzen sich. Die Verwendung mehrerer Systemkonzepte in einem Methodensystem erfordert Abstimmungen zwischen ihnen, die bereits beim Systementwurf zu beachten und bei der Implementierung zu realisieren sind (vgl. Lerneinheit EINTE). Auf Grund der bestehenden Durchdringung der Betriebswirtschaften mit den traditionellen Informationssystemen der Datenverarbeitung, steht der Systemplaner heute häufig vor dem Problem, wissensbasierte Systeme für bisher nicht unterstützte Aufgaben entwerfen und in eine bestehende Anwendungsumgebung einfügen zu müssen. Das Einfügen ist auch dann erforderlich, wenn vorhandene Informationssysteme der Datenverarbeitung durch wissensbasierte Systeme ersetzt werden sollen, weil die von ihnen verwendeten Algorithmen mit der Aufgabenstrukturiertheit nicht übereinstimmen (und damit in der Regel ziemlich realitätsfern sind). Entwerfen des Methodensystems und Methodenentwurf Beide Aufgaben sind klar auseinanderzuhalten. Während das Entwerfen des Methodensystems Gegenstand der Wirtschaftsinformatik und Aufgabe des Systemplaners ist, sollten die Methoden von den Wissenschaften zur Verfügung gestellt werden, zu deren Gegenstand die Aufgaben gehören. Bei betrieblichen Informationssystemen geht es um betriebswirtschaftliche und technische Aufgaben. Die Methoden zur Lösung dieser Aufgaben sollten von der Betriebswirtschaftslehre bzw. den zuständigen Ingenieurwissenschaften bereitgestellt werden; der Systemplaner sollte also auf eine betriebswirtschaftliche/technische Methodenbasis zurückgreifen können. Diese Idealvorstellung kann in der Praxis nicht verwirklicht werden, weil der Bestand an brauchbaren betriebswirtschaftlichen und technischen Methoden aus verschiedenen Gründen unzureichend ist, beispielsweise bezüglich der betriebswirtschaftlichen Methoden aus folgenden Gründen: • Die Methoden sind realitätsfern; sie setzen einen Grad an Aufgabenstrukturiertheit voraus, der nicht vorhanden ist (typisch für viele OR-Methoden). • Die Entwicklung der Informations- und Kommunikationstechnologien hat wesentlich veränderte und neue Methoden möglich gemacht; die Betriebswirtschaftslehre hat sich mit diesen Möglichkeiten aber noch nicht ausreichend vertraut gemacht. In Anbetracht dieser Situation wird vom Systemplaner nicht nur die Methodenkenntnis, sondern vielfach auch der Methodenentwurf erwartet. Daraus kann auf die große Bedeutung von betriebswirtschaftlichem und ingenieurwissenschaftlichem Wissen, das primär Methodenwissen ist, für Wirtschaftsinformatik-Praktiker geschlossen werden.

WMESY - Entwerfen des

Methodensystems

39

Vorgehensweise beim Entwerfen des Methodensystems Für das praktische Vorgehen beim Umsetzen einer verbal formulierten Aufgabe in die Definition eines logischen Methodenmodells kann ein rezeptartiges Vorgehen nicht angegeben werden. Auch liegen - im Unterschied zum Entwerfen des Datenmodells - keine brauchbaren Strukturregeln vor, die den Entwurfsprozeß unterstützen können. Aus den zuvor entwickelten Grundlagen zum Entwerfen des Methodensystems können jedoch Arbeitsschritte formuliert werden. Diese gehen von den betrieblichen Aufgaben aus, die Gegenstand der Systemplanung sind (vgl. Lerneinheit SACHZ), insbesondere von den daraus abgeleiteten Funktionsanforderungen. Sie sind in der angepaßten Grundkonzeption dokumentiert. Abbildung WMESY-4 zeigt die Arbeits schritte im Überblick; auf die Besonderheiten beim Entwerfen von wissensbasierten Systemen wird nicht eingegangen.

» , logisches Methodenmodell

g|||| MM

A b b W MESY-4: Arbeitsschritte beim Entwerfen des Methodensystems

Erster Arbeitsschritt: Ermitteln der Methodenbasis. Dabei werden alle verfügbaren Methoden, die den Funktionsanforderungen genügen, zur Methodenbasis zusammengefaßt. Dies erfolgt sowohl angebotsorientiert als auch bedarfsorientiert. Bei der angebotsorientierten Vorgehensweise werden alle im Istzustand verwendeten Methoden daraufhin überprüft, ob sie den Funktionsanforderungen entsprechen. Wenn ja, werden sie in die Methodenbasis übernommen. Bei der bedarfsorientierten Vorgehensweise wird von den Funktionsanforderungen ausgegangen, und es wird nach Methoden gesucht, welche den Funktionsanforderungen entsprechen; diese werden ebenfalls in die Methodenbasis aufgenommen. Es empfiehlt sich, zunächst angebotsorientiert und dann bedarfsorientiert vorzugehen, insbesondere deshalb, um alle Möglichkeiten der Methoden-Wieder-

40

Aufgaben der Grobprojektierung

Verwendung (und damit der Software-Wiederverwendung) voll auszuschöpfen. Die Methodenbasis wird durch eine Reihe von Attributen ("Methodenattribute") näher beschrieben. Beispiele für Methodenattribute sind: • • • • •

Welche Welche Welche Welche Welche

Daten braucht die Methode? Genauigkeit liefert die Methode? Verarbeitungsformen ermöglicht die Methode? Aufgabenstrukturierung braucht die Methode? Systemkonzepte sind der Methode angemessen?

Für die Methodenattribute lassen sich methodenabhängige Attributewerte angeben; damit erfolgt eine systematische Beschreibung der wichtigsten Eigenschaften der Methoden. Zweiter Arbeitsschritt: Zuordnen von Aufgaben und Methoden. Die Menge der Aufgaben kann zur Methodenbasis in folgenden Beziehungen stehen: •

l:l-Beziehung, das heißt, daß es für eine Aufgabe in der Methodenbasis genau eine Methode gibt; • 1 :n-Beziehung, das heißt, daß es für eine Aufgabe in der Methodenbasis n Methoden gibt; • m:l-Beziehung, das heißt, daß es für m Aufgaben in der Methodenbasis eine Methode gibt; • m:n-Beziehung, das heißt, daß es für eine Aufgabe in der Methodenbasis n Methoden gibt und daß eine Methode für m Aufgaben verwendet werden kann. Das Vorhandensein von l:n- und m:n-Beziehungen zwischen Aufgaben und Methoden weist auch auf mögliche Beziehungen zwischen den Methoden hin. Diese sind zum Beispiel von der Art, daß zur Lösung einer Aufgabe mehrere Methoden in einer bestimmten Abfolge erforderlich sind. Damit werden Methoden zu Modellen zusammengezogen. Durch die Zuordnung von Aufgaben auf Methoden sind bereits Konsistenzbedingungen formuliert worden. Diese können erweitert werden, beispielsweise durch explizite Methodenverbote für bestimmte Aufgaben. Weitere Konsistenzbedingungen, wie Methodenverbote bei Vorliegen bestimmter, nicht ausreichend genauer Daten, sind festzulegen und später durch die Anwendungssoftware zu realisieren (vgl. Lerneinheit SMEBA). Dritter Arbeitsschritt: Überprüfen der Methodenbasis. Beim Überprüfen der Methodenbasis werden zwei Zwecke verfolgt, erstens das Feststellen von Methodenredundanz und zweitens das Erkennen von Methodenlücken. Methodenredundanz ist vorhanden, wenn es eine Methode gibt, der keine Aufgabe zugeordnet ist, die also weggelassen werden kann, ohne daß damit die Leistungsfähigkeit des Methodensystems für das gegenständliche Aufgabensystem beeinträchtigt wird. Dagegen kann Methodenredundanz erwünscht sein, die durch eine l:n-Beziehung beschrieben ist. Der Aufgabe stehen dann alternative Methoden zur Verfügung, unter denen der Benutzer situationsabhängig eine passende auswählen kann. Hier kommt es in der Regel zu Konflikten zwischen den Zielen Wirtschaftlichkeit und Flexibilität des Methodensystems: Je mehr alternative Methoden vorhanden sind, desto flexibler ist das Methodensystem; dies kann zu Lasten der Wirtschaftlichkeit gehen. Eine Methodenlücke besteht dann, wenn es minde-

WMESY - Entwerfen des Methodensystems

41

stens eine Aufgabe gibt, der keine Methode zugeordnet werden kann. Eine Methodenlücke kann auch dann vorliegen, wenn einer bestimmten Aufgabe m Methoden zugeordnet werden, aus unterschiedlichen Gründen (z.B. zur Verbesserung der Flexibilität) jedoch m + n Methoden (also Methodenredundanz bzw. mehr Methodenredundanz) gefordert sind. Vierter Arbeitsschritt: Entwerfen von Methoden. Dabei wird von den im dritten Arbeitsschritt festgestellten Methodenlücken ausgegangen; sie erfordern den Methodenentwurf beim Entwerfen des Methodensystems (vgl. dazu weiter oben). Die Aufgabe des Methodenentwurfs ist umso umfangreicher, je unternehmensspezifischer die Funktionsanforderungen sind (was häufiger bei technischen als bei betriebswirtschaftlichen Aufgaben der Fall ist). Daraus folgt in der Regel ein hoher Aufwand für den Methodenentwurf und insbesondere für die nachfolgende Implementierung der Methoden in der Feinprojektierung. Fünfter Arbeitsschritt: Zuordnen von Methoden auf Aufgabenträger. In Abhängigkeit von der Zuordnung der Aufgaben auf Aufgabenträger (Mensch und/oder Techniksystem) als Gegenstand des Gestaltens der Arbeitsorganisation (vgl. Lerneinheit WAORG) werden die den Aufgaben zugeordneten Methoden oder Methodenteile auf Aufgabenträger zugeordnet. Im allgemeinen folgt die Zuordnung der Methoden der Zuordnung der Aufgaben. Auf Grund der vertieften Methodenkenntnis, die der Systemplaner im Zusammenhang mit dem Entwerfen des Methodensystems erwirbt, kann aus der Sicht des Methodensystems eine Änderung dieser Zuordnung zweckmäßig sein (z.B. vom Techniksystem auf den Menschen als Aufgabenträger, wenn als Methode nur eine Heuristik möglich ist). Demonstrationsbeispiel Aus dem Bereich Beschaffung und Lagerhaltung werden für die Aufgabe Materialbewertung einige Aussagen zum ersten bis vierten Arbeitsschritt der Vorgehensweise beim Entwerfen des Methodensystems gemacht. Damit kann auch die enge Verflechtung, die zwischen dem Entwerfen des Methodensystems und dem Entwerfen des Datensystems besteht, gezeigt werden. Aus der Aufgabe Materialbewertung werden zunächst folgende Methoden ("Bewertungsverfahren"), die den Funktionsanforderungen entsprechen, nach der bedarfsorientierten Vorgehensweise abgeleitet: • Materialbewertung mit Lieferpreisen, die vom Benutzer eingegeben werden; • Materialbewertung mit Bestellpreisen, die in der Datenbasis geführt werden; • Materialbewertung mit festen Verrechnungspreisen, die in der Datenbasis geführt werden; • Materialbewertung mit variablen Verrechnungspreisen, die in Abhängigkeit von den aktuellen Werten (z.B. den Herstellkosten bei eigengefertigten Teilen) ständig nachgeführt werden; • Materialbewertung mit gleitenden oder geglätteten Durchschnittspreisen, die bei jedem Lagerzugang neu ermittelt werden; • Materialbewertung nach der FIFO-Regel, bei der der Wert des jeweils zuerst eingelagerten, ältesten Lagerzugangs zur Bewertung verwendet wird; • Materialbewertung nach der LIFO-Regel, bei der der Wert des jeweils zuletzt eingelagerten, jüngsten Lagerzugangs zur Bewertung verwendet wird;

42

Aufgaben der Grobprojektierung

• Materialbewertung mit den aktuellen Kosten (z.B. den Herstellkosten) aus der Nachkalkulation, wenn es sich um eigengefertigte Teile handelt. Für die Aufgabe Materialbewertung stehen also acht Materialbewertungsmethoden zur Verfügung. Zwischen den Methoden bestehen keine Beziehungen; die Methoden werden alternativ verwendet. Zwischen der Aufgabe Materialbewertung und den Methoden zur Materialbewertung besteht eine l:n-Beziehung, da es für die Aufgabe mehrere Methoden gibt. Wenn nicht alle möglichen Methoden in die Methodenbasis aufgenommen werden sollen, ist eine Bewertung der Methoden vor dem Hintergrund der Planungsziele erforderlich. Die Bewertung setzt Kenntnisse über die Werte zu wichtigen Attributen der Methoden voraus. Beispielsweise erfordern LIFO und FIFO mehr Betriebsmittel als andere Methoden, weil alle Lagerzugänge mit den Attributen Menge, Wert und Datum in der Datenbasis geführt werden müssen. Es ist auch denkbar, den Methoden Prioritäten zuzuordnen, mit denen ihre Verwendung gesteuert werden kann (z.B. "Wenn die Lagerzugangsmeldung Daten über den Lieferpreis enthält, wird dieser zur Bewertung verwendet. Ist dies nicht der Fall, wird in der Datenbasis nach einem Bestellpreis gesucht, der - wenn er vorhanden ist - zur Bewertung verwendet wird. Ist kein Bestellpreis vorhanden, wird der in der Datenbasis geführte Verrechnungspreis zur Bewertung verwendet."). Forschungsbefunde Geis et al. haben anhand zweier Aufgaben ("Subventionsanalyse" und "Eingangspost-Klassifikation") versucht, die Systemkonzepte Datenverarbeitungssystem und wissensbasiertes System empirisch zu vergleichen. Im Ergebnis wird festgestellt, daß sich beide Aufgaben sowohl als Datenverarbeitungssystem als auch als Expertensystem realisieren lassen. Eine Aussage darüber, welches der beiden Systemkonzepte "besser geeignet" ist, konnte nicht getroffen werden. Die Autoren kommen zu dem Schluß, daß es "sinnvoll erscheint", bei der Bearbeitung ähnlicher Aufgaben die beiden Systemkonzepte in der Weise zu kombinieren, daß zunächst ein Expertensystem realisiert und dann, aufbauend auf den mit dem Expertensystem gewonnenen Erkenntnissen, eine wirtschaftlich akzeptable Problemlösung als Datenverarbeitungssystem geschaffen wird. Dies wird insbesondere mit dem relativ schlechten Laufzeitverhalten des Expertensystems einerseits und seiner leichten Änderbarkeit andererseits begründet. F. N. Ford legt das Ergebnis eines systematischen Vergleichs von Entscheidungsunterstützungssystemen mit Expertensystemen bezüglich (1) objectives and intents, (2) operational differences, (3) users of the system, and (4) development methodology vor. Er kommt zu dem Schluß, daß beiden Systemkonzepten auf Grund ihrer Verschiedenartigkeit große Bedeutung für die Unterstützung von Entscheidungsprozessen zukommt. Bezüglich der Entwicklungsmethodik wird für beide Systemkonzepte Prototyping als zweckmäßig bezeichnet, auch wenn es wegen der Unterschiedlichkeit der Systemkonzepte unterschiedliche Forderungen erfüllt. G. Fitzgerald vergleicht anhand von empirischen Untersuchungen anderer Autoren und einer eigenen empirischen Untersuchung (halb-strukturierte Interviews mit 16 Entwicklern in 12 Unternehmen und schriftliche Befragung von 75 Ma-

WMESY - Entwerfen des Methodensystems

43

nagern, Untersuchungszeitraum 1989/1990) den Prozeß der Entwicklung von EIS mit "traditioneller Systementwicklung" und kommt zu dem Schluß, daß die Entwicklungsprozesse bezüglich des Benutzereinflusses ("end-user influence"), der Mitwirkung der IKS-Abteilung ("IT/IS department involvement"), der Rolle von Fach- und Machtpromotoren ("the role of sponsors and champions") und der verwendeten Methoden und Techniken signifikant voneinander abweichen. Die EIS-Entwicklung wird von den Befragten als erfolgreich angesehen, während die "traditionelle Systementwicklung" häufig als inadäquat und ungeeignet empfunden wird, was insbesondere auf extensives Überschreiten der Kostenziele und der Terminziele zurückzuführen ist. Methodenverweise Vorgehens weise bei der Grobprojektierung (Lerneinheit VGROB); Prinzipien der Arbeitsorganisation (Lerneinheit PAORG); Optimierungsmodelle (Lerneinheit OPMOD); Simulation (Lerneinheit SIMUL); Integrationsprinzipien (Lerneinheit PINTE). Kontrollfragen 1. Welche Sichtweisen haben Benutzer, Systemplaner und Techniksysteme auf Methoden? 2. Was folgt aus dem datenorientierten Ansatz flir das Entwerfen des Methodensystems? 3. Welcher Unterschied besteht zwischen Datenverarbeitungssystem und wissensbasiertem System bezüglich der Strukturiertheit von Aufgaben? 4. In welche Arbeitsschritte wird das Entwerfen des logischen Methodenmodells gegliedert? 5. Warum wird zwischen "Entwerfen des Methodensystems" und "Methodenentwurf' unterschieden? Quellenliteratur Heinrich, L. J. et al.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 4. A., Oldenbourg Verlag, München/Wien 1994, insbes. Kapitel "Verarbeitungstechnik" Kurbel, K.: Entwicklung und Einsatz von Expertensystemen - Eine anwendungsorientierte Einführung in wissensbasierte Systeme. 2. A., Springer Verlag, Berlin et al. 1992 Mertens, P.: Integrierte Informationsverarbeitung 1 - Administrations- und Dispositionssysteme in der Industrie. 8. A., Gabler Verlag, Wiesbaden 1991 Picot, A. und Franck, E.: Informationsmanagement. In: Frese, E. et al. (Hrsg.): Handwörterbuch der Organisation. 3. A., Poeschel Verlag, Stuttgart 1992, 886 - 900 Scheer, A.-W.: EDV-orientierte Betriebswirtschaftslehre. 4. A., Springer Verlag, Berlin et al. 1990 Vertiefungsliteratur Fitzgerald, G.: Approaches to the Development of Executive Information Systems and the Contrast with Traditional Systems Development. In: Avison, D. et al. (Ed.): Human, Organizational, and Social Dimensions of Information Systems Development. Elsevier Science Publishers, North-Holland et al. 1993, 339 - 351 Ford, F. N.: Decision Support Systems and Expert Systems: A Comparison. In: Information & Management 8/1985,21 - 26 Geis, W. et al.: Vergleich von regelbasierten Expertensystemen mit Entscheidungstabellen anhand ausgewählter Beispiele. Arbeitsbericht des Instituts für Informatik der Universität Erlangen/ Nürnberg Bd. 21, Erlangen 1988 Geis, W. and Schumann, M.: Comparison of Rule Based Expert Systems with Traditional Technology - Selected Examples. In: Pau, L. F. et al. (Hrsg.): Expert Systems in Economics, Banking and Management. Elsevier Science Publishers, North-Holland et al. 1989, 437 - 446 Mertens, P. et al.: Betriebliche Expertensystem-Anwendungen. 3. A., Springer Verlag, Berlin et al. 1993

WAORG - Entwerfen der Arbeitsorganisation Lernziele Sie können die Aufgaben beim Entwerfen der Arbeitsorganisation unter Berücksichtigung technologischer und psycho-sozialer Faktoren beschreiben. Sie kennen die Ordnungskomponenten der Arbeitsorganisation und eine daraus abgeleitete Vorgehensweise beim Entwerfen der Arbeitsorganisation. Sie können die Strukturierbarkeit von betrieblichen Aufgaben einschätzen und Entscheidungen zur Gestaltung der Interaktionsaufgabe fällen. Definitionen und Abkürzungen Ablauforganisation (process Organization) = eine Menge von Arbeitsabläufen. Arbeitsablauf (sequence of Operations) = die Anordnung der zur Aufgabenerfüllung erforderlichen Verrichtungen in räumlicher, zeitlicher, logischer und mengenmäßiger Hinsicht. Arbeitsgang (step operation) = eine geordnete Menge von Tätigkeiten, die einem Aufgabenträger zugeordnet ist. Arbeitsorganisation (working process) = die Kombination von Produktionsfaktoren unter ökonomischen und sozialen Zielen. Arbeitsteilung (job partitioning) = die Zerlegung einer Aufgabe in gleichartige oder ähnliche Teilaufgaben und deren Zuordnung auf Aufgabenträger. Arbeitszufriedenheit (job satisfaction) = ein emotional erlebter Zustand des Bewußtseins, der mit der Erfüllung von Erwartungen bzw. der Hoffnung auf deren Erfüllung zusammenhängt. Aufbauorganisation (organizational structure) = die Gliederung der Organisation in aufgabenteilige, funktionsfähige Teilsysteme ("Stellen") und deren Koordination. Synonym: Strukturorganisation. Dialog (dialogue) = der direkte Austausch von Fragen und Antworten zwischen Benutzer und Techniksystem zur Lösung einer Aufgabe. Dialogflexibilität (dialogue flexibility) = die Eigenschaft eines Dialogs, auf Änderungen des Kommunikationsverhaltens des Benutzers zu reagieren. Einzelzuordnung (assignment to individuals) = die eindeutige Zuordnung von Aufgaben auf Aufgabenträger. Gruppenzuordnung (assignment to groups) = die Zuordnung von Aufgaben auf soziale Einheiten, die aus mehreren Aufgabenträgern bestehen. Metapher (metaphor) = die Projektion der Bedeutung von Wörtern und Bildern der Umgangssprache auf Eigenschaften eines abstrakten, künstlichen Systems. Sachmittel (means) = ein organisatorisches oder technisches Hilfsmittel, das den Aufgabenträger bei der Aufgabenerfüllung unterstützt oder das selbständig Aufgaben ausführt. Stelle (position) = die durch Aufgabenanalyse und nachfolgende Aufgabensynthese entstehende Struktureinheit. Tätigkeit (activity) = die aus einer zweckmäßigen Gliederung einer Aufgabe resultierende Teilaufgabe, die bei einem gegebenen Untersuchungszweck nicht weiter zerlegt werden kann oder soll bzw. eine Verrichtung an einem materiellen oder immateriellen Objekt ("Aktionsobjekt").

WAORG - Entwerfen der Arbeitsorganisation

45

Schnittstellen beim Entwerfen der Arbeitsorganisation Die Schnittstellen beim Entwerfen der Arbeitsorganisation sind durch die nachfolgend beschriebenen Inputs und Outputs gekennzeichnet: Inputs zum Entwerfen der Arbeitsorganisation sind: • die angepaßte Grundkonzeption (vgl. Lerneinheit AFEIN) als Ergebnis der Feinstudie; • die Systementwürfe in den anderen Teilprojekten, also im Datensystem (vgl. Lerneinheit WDASY), im Methodensystem (vgl. Lerneinheit WMESY), im Transportsystem (vgl. Lerneinheit WTRAN) und im Sicherungssystem (vgl. Lerneinheit WSICH). Outputs des Entwerfens der Arbeitsorganisation sind: • der Systementwurf im Teilprojekt Arbeitsorganisation, durch den Entwurfsentscheidungen in den anderen Teilprojekten beeinflußt werden; • das Ergebnis des Entwerfens der Arbeitsorganisation, also das logische Modell der Arbeitsorganisation. Die angepaßte Grundkonzeption als Input zum Entwerfen der Arbeitsorganisation enthält nur globale Vorstellungen über die Anforderungen an die Stellenbildung und an die Gestaltung der Arbeitsabläufe für das zu schaffende Informationssystem (vgl. Lerneinheit ANFOA). Dabei handelt es sich in erster Linie um Formalziele (vgl. Lerneinheit FORMZ), wie Arbeitszufriedenheit, Produktivität und Wirtschaftlichkeit. Der Weg von den Inputs zum Ergebnis des Entwerfens der Arbeitsorganisation als "logisches Modell der Arbeitsorganisation" beinhaltet insbesondere die Spezifizierung dieser Anforderungen und das Ableiten von Entwurfsentscheidungen zur Stellenbildung und zur Gestaltung der Arbeitsabläufe. Abbildung WAORG-1 zeigt die Einbettung des Entwerfens der Arbeitsorganisation in die genannten Inputs und Outputs. Die seitliche Anordnung des Inputs "Systementwürfe anderer Teilprojekte" deutet auf den interaktiven Zusammenhang der Entwurfsarbeiten in allen Teilprojekten hin.

Abb. WAORG-1: Inputs und Outputs beim Entwerfen der Arbeitsorganisation

Beim Entwerfen der Arbeitsorganisation ist nicht nur der interaktive Zusammenhang der Entwurfsarbeiten in allen Teilprojekten des zu schaffenden Informa-

46

Aufgaben der Grobprojektierung

tionssystems zu beachten, sondern auch die Tatsache, daß der Entwurf der Arbeitsorganisation zum planmäßigen Aufbau einer organisationsweiten Arbeitsorganisation beitragen soll. Deshalb ist beim Entwerfen der Arbeitsorganisation für ein Informationssystem die im Unternehmen vorhandene Arbeitsorganisation daraufhin zu überprüfen, ob der Bedarf an Stellen und Arbeitsabläufen für das zu schaffende Informationssystem durch den vorhandenen Bestand an Stellen und Arbeitsabläufen gedeckt werden kann. Dadurch soll das Entstehen von Redundanz vermieden und Konsistenz erreicht werden. Dies schließt nicht aus, daß einzelne Stellen und Arbeitsabläufe später mehrfach implementiert werden (z.B. mehrere parallele Arbeitsabläufe für das gleiche Objekt, aber mit verschiedenen Verrichtungen oder Verrichtungsfolgen), wenn die Redundanzen und daraus entstehende Inkonsistenzen wirkungsvoll kontrolliert werden können. Werkzeuge zur Unterstützung dieser Aufgabe sind für die projektbezogenen Entwurfsergebnisse die Enzyklopädie des verwendeten CASE-Systems (vgl. Lerneinheit WERSP) bzw. ein Datenkatalog-System für die im Unternehmen vorhandenen Stellen und Arbeitsabläufe (vgl. Lerneinheit DAKAT im Band "Informationsmanagement"). Aufgaben beim Entwerfen der Arbeitsorganisation Entwerfen der Arbeitsorganisation heißt Gestalten der Ablauforganisation (Arbeitsabläufe) und Gestalten der Strukturorganisation (Stellenbildung). Entweder wird von einer vorhandenen Strukturorganisation ausgegangen und die raum-zeitliche Ordnung der Tätigkeiten in diese eingefügt (strukturorientierte Sicht), oder es werden die Tätigkeiten zunächst in ihren räumlichen und zeitlichen Bewegungen geordnet und dann den Aufgabenträgern zugeordnet (ablauforientierte Sicht). Die enge Verknüpfung zwischen Ablauforganisation und Strukturorganisation verlangt in der Regel ein mehrmaliges Wiederholen dieser organisierenden Arbeitsschritte, sodaß letztlich das gleiche Ergebnis erreicht wird, unabhängig davon, ob die strukturorientierte oder die ablauforientierte Sicht verwendet wird. Technologisch gesehen ist Arbeitsorganisation die Kombination von Produktionsfaktoren unter ökonomischen Zielen und unter Beachtung normativer, gesetzlicher Restriktionen. Sie ist häufig durch Arbeitsteilung gekennzeichnet. Um die Verhinderung bzw. die Beseitigung negativer Folgen einer technologisch orientierten Arbeitsorganisation bemüht sich insbesondere die Arbeitswissenschaft. Die Einbeziehung psycho-sozialer Faktoren in das Gestalten der Arbeitsorganisation zielt darauf ab, subjektive Arbeitszufriedenheit zu erzeugen bzw. zu erhöhen. Dabei wird das Wissen über individuelle Verhaltensweisen und soziale Beziehungen bei arbeitsorganisatorischen Gestaltungsmaßnahmen berücksichtigt. Die Fortführung dieses Ansatzes führt zur Mitwirkung des Benutzers (Partizipation) bei der Gestaltung der Arbeitsorganisation (vgl. Lerneinheit PAORG sowie Lerneinheit BEBET im Band "Informationsmanagement"). Die Forderung, das logische Modell der Arbeitsorganisation für jede Anwendung und letztlich unternehmensweit zu entwerfen, besteht unabhängig davon, welcher Bereitstellungsweg für Anwendungssoftware gewählt wird: selbsterstellte oder fremderstellte Anwendungssoftware oder Standard-Anwendungssoftware. Über die Interaktionsaufgabe (vgl. weiter unten) wird ein Teil der Arbeitsabläufe im

WAORG - Entwerfen der Arbeitsorganisation

AI

Software-System implementiert. Bei einem Wechsel der Implementierungsform (z.B. beim Ersatz selbsterstellter Anwendungssoftware durch Standard-Anwendungssoftware) kann das logische Modell der Arbeitsorganisation die Erhaltung des arbeitsorganisatorischen Wissens sichern, und es kann als Referenzmodell verwendet werden. Ordnungskomponenten der Arbeltsorganisation Ordnungskomponenten der Arbeitsorganisation sind alle Tatbestände, die einen Zuwachs an Organisiertheit bewirken, nämlich: Arbeitsinhalt, Arbeitszeit, Arbeitsraum und Arbeitszuordnung. Jede Ordnungskomponente tritt in mehreren Präzisierungsschichten auf. Der Arbeitsinhalt besteht aus materiellen oder immateriellen Objekten und Verrichtungen, die diese Objekte erbringen. Zunächst sind die Objekte zu bestimmen. Die gegebene Arbeitsaufgabe enthält lediglich die Angabe des zu erbringenden Endobjekts, das in der Regel aus einer Reihe von Vorobjekten besteht. Da diese entweder nicht in der gesetzten Aufgabe benannt sind oder höchstens als Bestandteil des zu erbringenden Endobjekts verlangt werden, ist die Objektstruktur des Arbeitsinhalts weitgehend offen und bietet Gestaltungsspielraum. Durch die Bestimmung der Objektstruktur wird die Aufgabe systematisch in Teilaufgaben zerlegt. Wenn zur Hervorbringung eines Objekts mehrere alternative Verrichtungen möglich sind, besteht auch bei der Festlegung der Verrichtungen ein Gestaltungsspielraum. Die Bestimmung der Objekte und der Verrichtungen kann in der Regel nicht ausschließlich unter organisatorischen Gesichtspunkten erfolgen, da die Art des technologischen Verfahrens oder sogar ein bestimmtes Sachmittel oft bereits vorliegen (z.B. durch die Grundkonzeption vorgegeben sind, vgl. Lerneinheit GRUND). Die Arbeitszeit meint die Zeitfolge, die Zeitdauer und die Zeitpunkte der Durchführung von Verrichtungen an Objekten. Die Zeitfolge regelt die zeitliche Position der Verrichtungen, die Zeitdauer die Durchführungszeit und der Zeitpunkt die absoluten Kalender- und Uhrzeiten. Auch die Bestimmung der Arbeitszeit kann nicht ausschließlich unter organisatorischen Gesichtspunkten erfolgen, wenn das technologische Verfahren oder ein bestimmtes Sachmittel bereits vorliegen. Der Arbeitsraum meint die Bestimmung von Arbeitsbereich, Arbeitsweg und Arbeitsort. Dabei ergeben sich unterschiedliche Gestaltungsprobleme für stationäre bzw. für mobile Arbeitsprozesse. Die Bestimmung des Arbeitsbereichs bedeutet, daß die Arbeit innerhalb einer räumlichen Begrenzung stattfinden muß. Der Arbeitsweg ist für mobile Arbeitsprozesse innerhalb des Arbeitsbereichs festzulegen. Für stationäre Arbeitsprozesse ist der Arbeitsort zu bestimmen. Die Kombination der Regelungen Arbeitsbereich, Arbeitsweg und Arbeitsort ist die Festlegung von räumlichen Entfernungen zwischen den Verrichtungen eines Arbeitsprozesses. Auch hierbei sind häufig Restriktionen durch die gegebene Technologie oder durch die vorhandenen Sachmittel zu beachten. Die Arbeitszuordnung legt fest, welche Verrichtungen des Arbeitsprozesses auf welche Personen oder Sachmittel zugeordnet werden. Die Präzision der Zu-

48

Aufgaben der Grobprojektierung

Ordnung reicht dabei von Nicht-Zuordnung über Gruppenzuordnung bis zur Einzelzuordnung. Formalziele beim Gestalten der Ablauforganisation Unabhängig von den konkreten Projektzielen (vgl. Lerneinheit FORMZ) kann davon ausgegangen werden, daß das Gestalten der Ablauforganisation unter den folgenden Kategorien von Formalzielen erfolgt: wirtschaftliche Ziele, individualsoziale Ziele und flexibilitätsorientierte Ziele. Sowohl zwischen diesen Kategorien als auch zwischen den einzelnen Formalzielen jeder der drei Kategorien bestehen Zielbeziehungen, die beim Entwerfen der Arbeitsorganisation zu beachten sind. Wirtschaftliche Ziele sind insbesondere die Minimierung der Durchlaufzeit, die Maximierung der Kapazitätsauslastung (bzw. Minimierung der Leerzeit), die Minimierung der Bearbeitungskosten und die Sicherung der Qualität der Bearbeitung. In der Praxis wird meist nicht Maximierung bzw. Minimierung angestrebt. Auch wenn sie zum Ausgangspunkt der Überlegungen gemacht werden, kann meist (nur) eine betriebsindividuell "gute Lösung" realisiert werden. Die Durchlaufzeit besteht aus Bearbeitungszeit, Transformationszeit, Abstimmungs- und Kontrollzeit, Transportzeit, Rüstzeit und Liegezeit. Besonderer Beachtung bedürfen die Zeiten, die häufig und/oder nicht wertsteigernd sind. Dies trifft insbesondere auf die Transformationszeit und auf die Liegezeit zu. Die kapazitätsbestimmende Arbeitszeit eines Aufgabenträgers setzt sich aus Bearbeitungszeit, Rüstzeit und Leerzeit (d.h. Zeit ohne Beschäftigung) zusammen. Eine hohe Kapazitätsauslastung wird erreicht, wenn unter Berücksichtigung arbeitsbedingter Pausen die Leerzeit null wird. Die Bearbeitungskosten werden durch die Ablauforganisation, vor allem durch die Vermeidung von mehrfach ausgeführten Tätigkeiten ("Wiederholtätigkeiten"), beeinflußt; sie verursachen Kosten ohne Wertzuwachs. Zwischen Zeit- und Kostenzielen besteht im allgemeinen Komplementarität, was insbesondere heißt, daß eine Verringerung der Durchlaufzeit zu einer Reduzierung der Kosten führt. Qualität bezeichnet eine Reihe von qualitativen Anforderungen wie Aktualität, Richtigkeit, Verständlichkeit und Vollständigkeit. Sie bezieht sich auf die zeitliche und räumliche Verfügbarkeit von Informationen. Eine sinkende Durchlaufzeit kann sich positiv auf Aktualität, Vollständigkeit und Verständlichkeit auswirken; die geforderte Richtigkeit kann dagegen zu längerer Durchlaufzeit führen, wenn mehr Kontrolle zur Sicherung der Qualität erforderlich ist. Die Berücksichtigung individual-sozialer Ziele soll - über die Steigerung der Motivation und der Arbeitszufriedenheit - letztlich zur Leistungssteigerung führen. Motivation und Arbeitszufriedenheit sind eng miteinander verbunden. Mit einer hohen Motivation kann im allgemeinen ein hohes Maß an Arbeitszufriedenheit erreicht werden; umgekehrt kann durch vorhandene Arbeitszufriedenheit die Motivation beeinflußt werden. Beiden Zielen kann dadurch entsprochen werden, daß Entfaltungsmöglichkeiten, Autonomiebereiche und Partizipationsmöglichkeiten geschaffen werden (vgl. Lerneinheit PAORG). Ein weiteres individual-sozial orientiertes Ziel besteht in der Schaffung und Aufrechterhaltung persönlicher Kontakte zwischen den Aufgabenträgern. Jeder betriebliche Arbeitsprozeß ist so-

WAORG - Entwerfen der Arbeitsorganisation

49

wohl ein sachlicher als auch ein sozialer Prozeß. Ein Mangel an Kontakten ist ein Zeichen für eine zu starke Ausrichtung des Arbeitsprozesses als Sachprozeß, was sich negativ auf die Erreichung wirtschaftlicher Ziele (wie Produktivität und Qualität) auswirken kann. Eine Möglichkeit, für ausreichende Kontakte zu sorgen, besteht in der Übertragung von Aufgaben auf Gruppen ("teilautonome Gruppe", vgl. Lerneinheit PAORG). Mit der Berücksichtigung von flexibilitätsorientierten Zielen soll erreicht werden, daß - ohne grundlegende Änderung der Arbeitsorganisation - auf qualitative und quantitative Veränderungen der Aufgaben reagiert werden kann. Dies setzt voraus, daß die Aufgabenträger über einen Handlungsspielraum (vgl. Lerneinheit PAORG) verfügen, der sie in die Lage versetzt, die Notwendigkeit von Anpassungen rechtzeitig zu erkennen und diese Anpassungen auch durchführen zu können. Der Bedarf an Flexibilität wird in erster Linie durch die Art der Aufgabe bestimmt. Beispielsweise verlangen nur schwach strukturierte und stark veränderliche Führungsaufgaben ein höheres Ausmaß an Flexibilität als stark strukturierte, kaum veränderliche Sachbearbeitungsaufgaben. Verrichtungsprinzip vs. Objektprinzip Beim Entwerfen der Arbeitsabläufe kann entweder nach dem Verrichtungsprinzip oder nach dem Objektprinzip vorgegangen werden. Das Verrichtungsprinzip beschreibt eine Vorgehensweise, bei der die körperlichen oder geistigen Tätigkeiten, die an materiellen oder immateriellen Aktionsobjekten durchzuführen sind ("Verrichtungen"), im Vordergrund der Gestaltung stehen; den Verrichtungen werden die Aktionsobjekte zugeordnet. Beim Objektprinzip stehen die materiellen oder immateriellen Aktionsobjekte, an denen körperliche oder geistige Verrichtungen durchzuführen sind, im Vordergrund der Gestaltung; den Aktionsobjekten werden die Verrichtungen zugeordnet. Die Vorteilhaftigkeit des einen oder des anderen Prinzips hängt von der Vielfalt der Verrichtungen bzw. der Vielfalt der Objektgliederung ab. Wenn die Anzahl unterschiedlicher Verrichtungen groß und die Anzahl der Aktionsobjekte klein ist, empfiehlt sich die Verwendung des Verrichtungsprinzips. Ist dagegen die Anzahl der Aktionsobjekte groß und die der Verrichtungen gering, empfiehlt sich die Verwendung des Objektprinzips. Die empfohlene Vorgehensweise ist die jeweils einfacher zu handhabende; keine Fehler beim Zuordnen unterstellt, müssen beide Vorgehensweisen zum gleichen Ergebnis führen. Vorgehensweise beim Entwerfen der Arbeitsorganisation Für das praktische Vorgehen beim Umsetzen einer verbal formulierten Aufgabe in ein logisches Modell der Arbeitsorganisation kann ein rezeptartiges Vorgehen nicht angegeben werden. Unter Verwendung der genannten Ordnungskomponenten der Arbeitsorganisation kann mit den im folgenden erläuterten Arbeitsschritten vorgegangen werden (vgl. Abbildung WAORG-2). Erster Arbeitsschritt: Aufgabenanalyse. Mit der Aufgabenanalyse wird die Gesamtaufgabe, die Sachziel des zu schaffenden Informationssystems ist, in Teilaufgaben und werden die Teilaufgaben in Tätigkeiten erster bis n-ter Ordnung zer-

50

Aufgaben der

Grobprojektierung

legt ("Aufgabenzerlegung"). Die Aufgabenzerlegung erfolgt so lange, bis elementare Tätigkeiten entstehen, deren weitere Zerlegung im gegebenen Zusammenhang nicht mehr möglich oder nicht mehr sinnvoll ist. Die Aufgabenanalyse berücksichtigt im allgemeinen nicht die (geplante) Situation der Aufgabenerfüllung (z.B. die Frage, welcher Aufgabenträger die Aufgaben mit welchem Sachmittel durchführen wird). Das Ergebnis der Aufgabenanalyse ist daher ein theoretischer Möglichkeitsraum der Aufgabenzerlegung, der durch die nachfolgende Aufgabensynthese - unter Berücksichtigung der verfolgten Formalziele vom Systemplaner mehr oder weniger ausgeschöpft wird. Der Grad der Arbeitsteilung wird daher nicht durch die Aufgabenanalyse bestimmt, sondern vom Systemplaner durch die Aufgabensynthese festgelegt. Dabei ist auch die Strukturiertheit der Aufgaben zu beachten (vgl. weiter unten).

Abb. WAORG-2: Arbeitsschritte beim Entwerfen der Arbeitsorganisation

Zweiter Arbeitsschritt: Aufgabensynthese. Mit der Aufgabensynthese werden die mit der Aufgabenanalyse bestimmten Tätigkeiten - unter Berücksichtigung der (geplanten) Situation der Aufgabenerfüllung (z.B. des Aufgabenträgers, der die Aufgaben durchführen wird, und des Sachmittels, das er dazu verwenden wird) - zusammengefaßt. Die strukturbezogene Aufgabensynthese hat die Stellenbildung zum Ziel; es werden die Tätigkeiten, die den Aufgabenbereich eines Aufgabenträgers abgrenzen, zu Stellen zusammengefaßt. Die ablaufbezogene Aufgabensynthese hat die Bildung von Arbeitsabläufen zum Ziel; es werden unter Berücksichtigung der Dimensionen Raum, Zeit, logische Abfolge und Menge - die Tätigkeiten zunächst zu Arbeitsgängen und dann zu Arbeitsabläufen geordnet. Bei der strukturbezogenen Aufgabensynthese steht die Entscheidung über die Anzahl der Gliederungsebenen der Organisation ("Hierarchie-Ebenen"), von der

WAORG - Entwerfen der Arbeitsorganisation

51

Gesamtaufgabe bis zu den Stellenaufgaben, und damit über den Grad der Arbeitsteilung im Vordergrund der Gestaltung. Arbeitsteilung erfordert die Bildung neuer Teilaufgaben, die zur Koordination der zerlegten Teilaufgaben bzw. ihrer Aufgabenträger erforderlich sind. Eine gegebene Gesamtaufgabe enthält also keine nach Umfang und Inhalt definierte Menge von Teilaufgaben; die Menge der Teilaufgaben hängt vielmehr vom Grad der Arbeitsteilung ab. Für die ablaufbezogene Aufgabensynthese bedeutet Arbeitsteilung Arbeitsgliederung, die als Fortsetzung der Aufgabenzerlegung verstanden werden kann. Je höher der Grad der Arbeitsteilung ist, desto geringer ist der Gestaltungsspielraum bei der Bildung von Arbeitsabläufen. Mit anderen Worten: Je weniger (bzw. je mehr) Tätigkeiten zu einem Arbeitsgang zusammengefaßt werden, desto mehr (bzw. desto weniger) Arbeitsteilung ist möglich. Nach herrschender, nicht unbestrittener Meinung lassen sich durch Arbeitsteilung "Lernerfolge" erzielen, die zu kürzeren Bearbeitungszeiten führen. Auf mögliche negative Folgen, wie sinkende Arbeitszufriedenheit und verminderte Arbeitsqualität, wird hingewiesen.

Abb. WAORG-3: Aufgabenzuordnung

Dritter Arbeitsschritt: Aufgabenzuordnung. Mit der Aufgabenzuordnung werden die durch die Aufgabensynthese gebildeten Teilaufgaben auf Menschen und Sachmittel (insbesondere Computersysteme) als Aufgabenträger zugeordnet. Dabei wird nach Abbildung WAORG-3 vorgegangen, also zunächst festgelegt, welche Teilaufgaben systemunterstützt ("automatisiert") und welche nicht systemunterstützt werden sollen. Für systemunterstützte Teilaufgaben ist anschließend festzulegen, welche von ihnen Sachaufgaben und welche Interaktionsaufgaben sind. Sachaufgabe ist der Teil einer Aufgabe, der unmittelbar der Erbringung einer Leistung dient. Interaktionsaufgabe ist der Teil einer Aufgabe, welcher der Kommunikation zwischen dem Menschen als Aufgabenträger und der einem Sachmittel zugeordneten Sachaufgabe dient. Umfang und Inhalt der Interaktionsaufgabe werden im wesentlichen durch die Art des verwendeten Sachmittels bestimmt. Je mehr Computersysteme als Sachmittel verwendet werden, desto bedeutsamer wird die Gestaltung der Interaktionsaufgabe für das Entwerfen der Arbeitsorganisation. Wie bei der Arbeitsteilung gilt auch hier, daß eine gegebene Gesamtaufgabe keine nach Umfang und Inhalt definierte Menge von Teilaufgaben enthält; diese hängt auch von der Art des verwendeten Sachmittels ab. Je einfacher (bzw. je komplexer) das verwendete Sachmittel ist, desto geringer (bzw. desto zahlreicher) sind die durch Aufgabenzuordnung auf Sachmittel entstehenden Teilaufgaben. Die strukturbezogene Auf-

52

Aufgaben der Grobprojektierung

gabenzuordnung geht vom Ergebnis der strukturbezogenen Aufgabensynthese aus, also von den gebildeten Stellen, die ablaufbezogene Aufgabenzuordnung vom Ergebnis der ablaufbezogenen Aufgabensynthese, also von den gebildeten Arbeitsabläufen. Die Aufgabenzuordnung erfolgt unter Beachtung des Grundsatzes der Äquivalenz von objektiven und subjektiven Anforderungen. Einem Aufgabenträger sollen nach Art und Anzahl die Arbeitsgänge übertragen werden, zu deren Erfüllung er auf Grund seiner qualitativen und quantitativen Leistungsfähigkeit in der Lage ist. Sowohl Überforderung als auch Unterforderung sollen vermieden werden. Bei der Aufgabenzuordnung auf Personen einerseits und auf Sachmittel andererseits sollen folgende Gestaltungsempfehlungen beachtet werden: • Aufgaben, die durch eine hohe Wiederholungshäufigkeit und/oder durch eine große Anzahl von Bearbeitungsvorgängen gekennzeichnet sind, sowie Aufgaben, für die brauchbare Methoden zur Verfügung stehen und die manuell aus Zeit- und Kostengründen oder wegen mangelnder Sachkenntnis nicht bewältigt werden können, sollen automatisiert werden. • Aufgaben, für deren Bewältigung die spezifischen Sachkenntnisse und Fähigkeiten des Menschen, wie etwa die Fähigkeit zur Erfahrungsbildung und -anwendung, zur flexiblen Situationsbewertung, zum Erkennen von Strukturen und Zusammenhängen sowie das persönliche "Fingerspitzengefühl" erforderlich sind, sollen nicht automatisiert, sondern dem Menschen als Aufgabenträger zugeordnet werden. Für Aufgaben, die Personen als Aufgabenträger zugeordnet werden und welche die besonderen Fähigkeiten, aber auch die besonderen Schwächen von Menschen berücksichtigen, gelten folgende Anforderungen: • Sie sollen einen großen Handlungsspielraum haben und einen angemessenen zeitlichen Spielraum zur Aufgabendurchführung bieten. • Sie sollen durchschaubar und (auch) nach individuellen Zielen gestaltbar sein. • Sie sollen ausreichende körperliche Aktivität, einen konkreten Kontakt zu materiellen und sozialen Bedingungen der Arbeit und damit die Beanspruchung vielfältiger Sinnesqualitäten ermöglichen. • Sie sollen Variationsmöglichkeiten bei der Aufgabendurchführung und Möglichkeiten aufgabenbezogener Kommunikation und unmittelbarer zwischenmenschlicher Kontakte bieten. Vierter Arbeitsschritt: Entwerfen der Interaktionsaufgabe. Die Interaktionsaufgabe ist die Schnittstelle zwischen der systemunterstützten Sachaufgabe und den nicht systemunterstützten Teilaufgaben einer Aufgabe ("Benutzerschnittstelle"). Die Gestaltung der Interaktionsaufgabe wirkt sich unmittelbar auf den Arbeitsablauf aus; sie ist deshalb eine zentrale Aufgabe beim Gestalten der Arbeitsorganisation. Beim Entwerfen der Interaktionsaufgabe steht die Entscheidung über die Dialogform ("Interaktionsform") im Vordergrund. Dazu braucht der Systemplaner Wissen über die alternativen Dialogformen und ihre charakteristischen Merkmale, über die Merkmale der Personen, die als Aufgabenträger über eine Interaktionsaufgabe eine Sachaufgabe erfüllen sollen, und über die Sachaufgabe selbst.

WAORG - Entwerfen der Arbeitsorganisation

53

Dialogformen Das Spektrum der Dialogformen ist vielfältig. Eine einfache Klassifizierung führt zur Unterscheidung zwischen benutzergeführtem oder benutzergesteuertem Dialog und systemgeführtem oder systemgesteuertem (auch: computergeführtem oder computergesteuertem) Dialog. Beim benutzergeführten Dialog erhält der Benutzer keine Hinweise auf momentan mögliche oder zulässige Funktionen; er formuliert seine Kommandos aktiv selbst. Entscheidender Vorteil ist die hohe Flexibilität; entscheidender Nachteil die schwierige Erlernbarkeit. Da der sachkundige Benutzer am besten weiß, welche Funktionen in welcher Abfolge zur Bearbeitung einer bestimmten Aufgabe erforderlich sind, soll ihm dies nicht vom Programm "vorgeschrieben" werden, der Dialog für den sachkundigen Benutzer daher benutzergeführt sein. Beim systemgeführten Dialog wird der Benutzer durch den Dialog geführt; er verhält sich passiv. Entscheidender Vorteil ist die einfache Erlernbarkeit, entscheidender Nachteil die fehlende Flexibilität. Beim gemischten Dialog wird versucht, die Vorteile der beiden Dialogformen zu kombinieren und ihre Nachteile zu vermeiden; die Initiative zum Dialog wechselt zwischen Benutzer und System. Für die Wahl der Dialogform sind Kriterien wie Qualifikation der Benutzer, zulässiger Zeitaufwand für die Abwicklung des Dialogs und zulässige Fehlerrate entscheidend. Wichtige Merkmale der Dialogformen sind Flexibilität, Belastung des Gedächtnisses und Problemangemesssenheit. Individuelle Präferenzen der Benutzer sind der Grund für die Forderung, mehrere Dialogformen zur Auswahl zur Verfügung zu stellen. Dies führt letztlich zu der Forderung, anpaßbare Benutzerschnittstellen zu konstruieren. Eine Benutzerschnittstelle, die sich "automatisch" und "selbständig" an den Benutzer anpaßt, wird als adaptive Benutzerschnittstelle bezeichnet (das System ist Initiator der Anpassung, und es führt die Anpassung durch). Eine Benutzerschnittstelle, die vom Benutzer angepaßt wird, heißt adaptierbare Benutzerschnittstelle (der Benutzer ist Initiator der Anpassung, und er führt die Anpassung selbst durch). Anpaßbarkeit ist in jedem Fall durch den Systementwurf vorgeplant. Das Problem der Anpaßbarkeit besteht darin, beim Systementwurf vorherzusehen, welche Anpassungen benötigt werden. Es gibt zahlreiche Möglichkeiten zur Anpassung der Dialogform an den Benutzer und an die Sachaufgabe. So können Dialogformen in unterschiedlichen Kombinationen verwendet werden, oder eine bestimmte Dialogform wird an die Präferenz des Benutzers angepaßt. Die kombinierte Bereitstellung verschiedener Dialogformen wird als multimodale Benutzerschnittstelle bezeichnet. Die Realisierung der gewählten Dialogform durch Dialogtechniken ist Gegenstand des Entwickeins der Arbeitsorganisation (vgl. Lerneinheit EAORG). Die Gestaltung der Sachaufgabe ist Gegenstand des Entwerfens des Datensystems (vgl. Lerneinheit WDASY) und insbesondere Gegenstand des Entwerfens des Methodensystems (vgl. Lerneinheit WMESY).

54

Aufgaben der Grobprojektierung

Strukturiertheit und Formalisierbarkeit von Aufgaben Bei der Bestimmung der Objektstruktur des Arbeitsinhalts (Aufgabenanalyse) wird unterstellt, daß jede Aufgabe in gleicher Weise einer Zerlegung zugänglich ist. Dies ist jedoch nicht der Fall, sodaß die Aufgabenanalyse aufgabenabhängig zu unterschiedlich feinen Teilaufgaben führt. Je feiner die Objektstruktur gegliedert werden kann, desto arbeitsteiliger können Stellen gebildet und desto formalisierter können Arbeitsabläufe gestaltet werden. Auf die Eigenschaft von Aufgaben, schwach oder stark strukturiert zu sein, ist an anderer Stelle schon eingegangen worden (vgl. Lerneinheit WMESY). Im Zusammenhang mit der Aufgabenanalyse interessiert zusätzlich, aus welchen Gründen die Strukturiertheit von Aufgaben zunimmt und wodurch der Gestaltungsspielraum beim Entwerfen der Arbeitsorganisation eingeschränkt wird. Dieses Phänomen wird als Formalisierbarkeit von Aufgaben bezeichnet. Die Formalisierbarkeit der Aufgaben nimmt aus verschiedenen Gründen zu. Beispiele für derartige Gründe sind: • Routinearbeiten verlangen schnelles, sicheres und bequemes Verrichten, sodaß sich formalisierte Arbeitsformen herausbilden und verfestigen. • Aufgaben werden systematisch daraufhin untersucht, welche Teilaufgaben formalisierbar sind. • Arbeitsergebnisse der Wissenschaft, die ihrem Wesen nach formal sind, werden in die Praxis eingeführt. • Die Arbeitsteiligkeit von Arbeitsorganisationen erfordert formalisierte Schnittstellen zur Koordination; die Formalisierung der Schnittstellen wirkt auf die Aufgabe zurück. • Die Sachmittel werden standardisiert und erzwingen mehr Formalisierung bei ihrer Handhabung. • Normative (z.B. gesetzliche) Restriktionen, die bei der Aufgabendurchführung zu beachten sind, wirken formalisierend. Forschungsbefunde Die Forschungsbefunde zur Frage, wie die Arbeitsorganisation durch Computerisierung beeinflußt wird, sind vielfältig und widersprüchlich. Weitgehend Einigkeit besteht darüber, daß Arbeitsteilung und Formalisierung keine "Erfindungen" des Computerzeitalters sind. Darauf aufbauend können die Befunde zu folgenden, gegensätzlichen Thesen geordnet werden. Die eine These behauptet, daß Arbeitsteilung durch Computerisierung verstärkt und gleichzeitig weniger sichtbar gemacht wird. Die andere These behauptet, daß Arbeitsteilung trotz Formalisierung durch Computerisierung reduziert wird. Vielen empirischen Untersuchungen gemeinsam ist die Schlußfolgerung, daß Informations- und Kommunikationstechniken einen erheblichen Gestaltungsspielraum bei der Konstruktion von Informationssystemen eröffnen, der beim Entwerfen der Arbeitsorganisation unter technologischen und psycho-sozialen Zielen genutzt werden kann, daß diese Nutzung tatsächlich aber nicht ausreichend erfolgt. Kieser/Kubicek geben zahlreiche Quellen mit Forschungsbefunden an und fügen eine eigene Interpretation bei.

WAORG - Entwerfen der Arbeitsorganisation

55

Ähnlich kontrovers sind die Befunde über die Benutzerakzeptanz computerisierter Arbeitsplätze. Häufig wird behauptet, daß vor allem Frauen computerisierten Arbeitsplätzen ablehnend gegenüberstehen. Ein neuerer Befund weist auf regionale und soziale Unterschiede hin. Ostdeutsche Frauen stehen der Arbeit am Computer weit positiver gegenüber als ihre westdeutschen Kolleginnen: Beim Angebot eines Tätigkeitsbereichs würden über die Hälfte den Arbeitsplatz mit Computer wählen. Bei den westdeutschen Frauen ziehen dagegen zwei Drittel den Arbeitsplatz ohne Computer vor. (Repräsentative Befragung von 3001 Personen im Alter zwischen 16 und 59 Jahren; zitiert nach HANDELSBLATT Nr. 172 vom 7. 9. 1993, 20) G. Peters hat durch Expertenbefragungen (20 Experten, Erhebungszeitraum vermutlich 1987) untersucht, welche Formalziele bei der Gestaltung der Arbeitsorganisation in der Praxis verwendet werden. Die in der Literatur häufig berichtete Dominanz zeitlicher Ziele wurde bestätigt; dabei hatte die Minimierung der Durchlaufzeit die größte Bedeutung (17 Bestätigungen). Wesentlich seltener (9 Bestätigungen) wurde die Maximierung der Kapazitätsauslastung verfolgt. Relativ häufig (12 Bestätigungen) wurde die Minimierung von Terminüberschreitungen als Ziel genannt; bisherige Befunde weisen nur selten auf die Relevanz dieses Ziels hin. Als Ursache für die hohe Bedeutung dieses Ziels wird die mangelnde zeitliche Abstimmung der Teilleistungen einzelner Aufgabenträger aufeinander angegeben. Auf die Berücksichtigung kostenorientierter Ziele wurde häufig verwiesen (16 Bestätigungen). Nachweisbar war die komplementäre Beziehung zwischen zeitlichen Zielen (insbes. Durchlaufzeit) und Kostenzielen. Soziale Ziele spielten insgesamt eine geringere Rolle als wirtschaftliche Ziele; es fanden sich 12 Bestätigungen für ihre explizite Berücksichtigung. Mit 14 Bestätigungen wurde den flexibilitätsorientierten Zielen eine größere Bedeutung zugemessen als den sozialen Zielen. H.-W. Walther untersuchte mit einer flexiblen und einer starren Version eines Texteditors experimentell den Einfluß der Dialogflexibilität auf Arbeitszufriedenheit und Leistungsfähigkeit der Benutzer. Eindeutige Ergebnisse zeigten sich im Hinblick auf die Einstellung der Benutzer: Sie brachten der flexiblen Variante eine positivere Einstellung entgegen als der starren Variante; sie empfanden den flexiblen Editor als "toleranter", "freundlicher", "angenehmer" und "persönlicher", und zwar unabhängig von ihrer Erfahrung (also unabhängig vom Benutzertyp). Dagegen traten Angstgefühle (wie Spannung, Nervosität, Beunruhigung, Besorgnis) deutlich in Abhängigkeit vom Benutzertyp auf. Daraus ist zu schließen, daß ein vom Benutzertyp abhängiges Ausmaß an Dialogflexibilität erforderlich ist: Je geringer die Erfahrung des Benutzers ist, desto geringer soll das Ausmaß an Dialogflexibilität sein. Koller/Ziegler kommen durch Laborstudien zu folgenden Aussagen bezüglich der Präferenzen von Benutzern, die zuvor keine "EDV-Kenntnisse" hatten, über die Dialogformen: Es gibt Unterschiede zwischen den Versuchspersonen bezüglich der bevorzugten Dialogform. Benutzer entscheiden sich im allgemeinen für eine bestimmte Dialogform und benutzen diese überwiegend. Später erlernte Dialogformen werden bevorzugt. Zwischen dem Zeitbedarf einer Dialogform zur Ausführung einer Funktion und der Benutzerpräferenz besteht kein Zusammenhang.

56

Aufgaben der Grobprojektierung

Methodenverweise Vorgehensweise bei der Grobprojektierung (Lerneinheit VGROB); Prinzipien der Arbeitsorganisation (Lerneinheit PAORG); Integrationsprinzipien (Lerneinheit PINTE).

Kontrollfragen 1. Aus welchen Gründen ist die Einbeziehung psycho-sozialer Faktoren in die Gestaltung der Arbeitsorganisation erforderlich? 2. Welches sind die "Ordnungskomponenten" der Arbeitsorganisation? 3. In welchen Arbeitsschritten wird das Entwerfen des logischen Modells der Arbeitsorganisation abgearbeitet? 4. Zu welchen Arbeitsergebnissen führen Aufgabenanalyse und Aufgabensynthese? 5. Welches sind die "Quellen der Formalisierung" von Aufgaben?

Quellenliteratur Frese, E.: Aufgabenanalyse und -synthese. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980, 207 - 217 Kosiol, E.: Grundprobleme der Ablauforganisation. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A„ Poeschel Verlag, Stuttgart 1980, 2 - 7 Laske, St.: Arbeitsorganisation und Arbeitsqualität. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A„ Poeschel Verlag, Stuttgart 1980,118 - 126 Liebelt, W. und Sulzberger, M.: Grundlagen der Ablauforganisation. Verlag Schmidt, Gießen 1988 Peters, G.: Ablauforganisation und Informationstechnologie im Büro. Konzeptionelle Überlegungen und empirisch-explorative Studie. Müller Botermann Verlag, Köln 1988

Vertiefungsliteratur Bodendorf, F.: Benutzermodell - ein konzeptioneller Überblick. In: WIRTSCHAFISINFORMATIK 2/1992, 233 - 245 Eberleh, E.: Klassifikation von Dialogformen. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988, 102 - 120 Haaks, D.: Anpaßbare Informationssysteme. Auf dem Weg zu aufgaben- und benutzerorientierter Systemgestaltung und Funktionalität. Verlag für Angewandte Psychologie, Göttingen/Stuttgart 1992 Kieser, A. und Kubicek, H.: Organisation. 2. A., Verlag de Gruyter, Berlin/New York 1983 Koller, F. und Ziegler, J.: Benutzerpräferenzen bei alternativen Eingabetechniken. In: Maaß, S. und Oberquelle, H. (Hrsg.): Software-Ergonomie '89. Aufgabenorientierte Systemgestaltung und Funktionalität. Verlag Teubner, Stuttgart 1989 Maguire, M.: An evaluation of published recommendations on the design of man-computer dialogues. In: International Journal of Man-Machine Studies 16/1982, 237 - 261 Schweitzer, M.: Arbeitsteilung. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980, 139 - 144 Shneiderman, B.: Direct Manipulation. A Step Beyond Programming Languages. In: IEEE Computer, Vol. 16. August 1983, 57 - 69 Waither, H.-W.: The on-line user-computer interfaces: The effects of interface flexibility, experience, and terminal type on user satisfaction and performance. Dissertation. The University of Texas at Austin, August 1973

WTRAN - Entwerfen des Transportsystems Lernziele Sie können die Aufgaben erläutern, die beim Entwerfen des Transportsystems zu bearbeiten sind. Sie kennen die Bedeutung der Informationsnachfrage und des Informationsangebots für das Gestalten der Transportwege und der Topologie des Transportsystems. Sie können erläutern, welchen Beitrag die Graphentheorie beim Entwerfen des Transportsystems leisten kann. Sie kennen eine in Arbeitsschritte gegliederte Vorgehensweise zum Entwerfen des Transportsystems. Definitionen und Abkürzungen Adjazenzmatrix (adjacent matrix) = eine Matrix mit allen Ecken eines Graphen in den Zeilen und in den Spalten, deren Elemente 1 sind, wenn zwischen den Ecken eine direkte Beziehung besteht, und deren Elemente 0 sind, wenn keine direkte Beziehung besteht. Digraph (digraph) = ein gerichteter Graph, der keine Schleifen und keine parallelen Kanten mit gleichem Richtungssinn hat. Entfernungsmatrix (distance matrix) = eine Matrix mit allen Ecken eines Graphen in den Zeilen und in den Spalten, deren Elemente die Anzahl der Kanten enthalten, die zwischen den Ecken bestehen. Graph (graph) = eine endliche, nicht leere Menge V von P Ecken oder Knoten mit einer Menge X von q zweielementigen Teilmengen von V. Informationsangebot (information supply) = die Fähigkeit einer Systemkomponente, auf Grund des vorhandenen Bestands oder mit Hilfe ihrer Ressourcen Information für andere Systemkomponenten zur Verfügung zu stellen. Informationsnachfrage (information demand) = der Bedarf bzw. das Bedürfnis einer Systemkomponente nach Information, der bzw. das von anderen Systemkomponenten gedeckt werden muß. Topologie (topology) = die Lehre von der Anordnung geometrischer Gebilde im Raum; stellt die Transportwege in einem Transportsystem abstrakt dar. Transport (transport) = das Bewegen oder Weiterbewegen von Information in Form von Daten, Text, Bild und Sprache. Transportsystem (transport system) = die Gesamtheit der Transportwege in einem Informationssystem. Synonym: Kommunikationssystem. Transportweg (transport Channel) = die Art und Weise, in der eine Systemkomponente mit Informationsnachfrage und eine Systemkomponente mit Informationsangebot verbunden werden. Synonym: Kommunikationsweg. Vorgangskette (trigger chain) = die Ordnung einzelner Bearbeitungsvorgänge so, daß in sich relativ abgeschlossene Arbeitsabläufe zwischen einem definierten Endereignis und einem definierten (auslösenden) Startereignis entstehen, zwischenbetriebliche Integration (interorganizational integration) = die Schaffung und Nutzung von Transportwegen zwischen einem Unternehmen und seiner Umwelt (z.B. Kunden und Lieferanten) so, daß der Transport von Daten ökonomisch vorteilhaft abgewickelt werden kann.

58

Aufgaben der Grobprojektierung

Schnittstellen beim Entwerfen des Transportsystems Die Schnittstellen beim Entwerfen des Transportsystems sind durch die nachfolgend beschriebenen Inputs und Outputs gekennzeichnet. Inputs zum Entwerfen des Transportsystems sind: • die angepaßte Grundkonzeption (vgl. Lerneinheit AFEIN) als Ergebnis der Feinstudie; • die Systementwürfe in den Teilprojekten Datensystem (vgl. Lerneinheit WDASY), Methodensystem (vgl. Lerneinheit WMESY) und Arbeitsorganisation (vgl. Lerneinheit WAORG). Outputs des Entwerfens des Transportsystems sind: • der Systementwurf im Teilprojekt Transportsystem, durch den Entwurfsentscheidungen in anderen Teilprojekten beeinflußt werden; • das Ergebnis des Entwerfens des Transportsystems, also das logische Transportmodell. Die angepaßte Grundkonzeption als Input zum Entwerfen des Transportsystems beinhaltet nur globale Vorstellungen über die Anforderungen an die Gestaltung der Transportwege im zu schaffenden Informationssystem (vgl. Lerneinheit ANFOA); dabei handelt es sich in erster Linie um Sachziele (vgl. Lerneinheit SACHZ). Der Weg von den Inputs zum Ergebnis des Entwerfens des Transportsystems als logisches Transportmodell umfaßt insbesondere die Spezifizierung dieser Anforderungen und das Ableiten der Transportbedarfe aus der Informationsnachfrage. Abbildung WTRAN-1 zeigt die Einbettung des Entwerfens des Transportsystems in die genannten Inputs und Outputs. Die seitliche Anordnung des Inputs "Systementwürfe anderer Teilprojekte" deutet auf den interaktiven Zusammenhang der Entwurfsarbeit in allen Teilprojekten hin.

Abb. WTRAN-1: Inputs und Outputs beim Entwerfen des Transportsystems

Beim Entwerfen des Transportsystems ist nicht nur der interaktive Zusammenhang der Entwurfsarbeiten in allen Teilprojekten des zu schaffenden Informationssystems zu beachten, sondern auch die Tatsache, daß der Entwurf des Transportsystems zum planmäßigen Aufbau des unternehmensweiten Transportsystems beitragen soll. Deshalb ist beim Entwerfen des Transoortsvstems der im

WTRAN - Entwerfen des Transportsystems

59

Unternehmen vorhandene Bestand an Transportwegen daraufhin zu überprüfen, ob der Transportbedarf für das zu schaffende Informationssystem durch den vorhandenen Bestand an Transportwegen gedeckt werden kann. Dadurch soll das Entstehen von Redundanz vermieden und Konsistenz erreicht werden. Dies schließt nicht aus, daß einzelne Transportwege später mehrfach (z.B. durch Verwendung unterschiedlicher Transportmedien) implementiert werden, wenn die Redundanzen und daraus entstehende Inkonsistenzen wirkungsvoll kontrolliert werden können. Werkzeuge zur Unterstützung dieser Aufgabe sind für die projektbezogenen Entwurfsergebnisse die Enzyklopädie des verwendeten CASESystems (vgl. Lerneinheit WERSP) bzw. ein Datenkatalog-System für die im Unternehmen vorhandenen Transportwege (vgl. Lerneinheit DAKAT im Band "Informationsmanagement"). Aufgaben beim Entwerfen des Transportsystems Jedes Informationssystem besteht aus einer Menge von Komponenten (Aufgaben, Menschen als Aufgabenträger, Techniksysteme als Sachmittel bzw. als Sachmittel und als Aufgabenträger), und jedes Informationssystem ist Teil eines größeren organisatorischen Ganzen. Zwischen den Komponenten innerhalb des Informationssystems sowie zwischen ihnen und der Umwelt bestehen Abhängigkeiten, deren organisatorische Auswirkungen beim Festlegen der Sachziele als Schnittstellenanforderungen beschrieben wurden (vgl. Lerneinheit SACHZ). Von herausragender Bedeutung für das Funktionieren eines Informationssystems sind die Schnittstellen, welche die Anforderungen von Komponenten bezüglich ihrer Informationsnachfrage bzw. ihres Informationsangebots beschreiben. Aus Art und Umfang von Informationsnachfrage und Informationsangebot ergibt sich der Transportbedarf für das Informationssystem. Die Abdeckung des Transportbedarfs erfordert die Schaffung von Transportwegen für Information zwischen den Systemkomponenten. Die Gesamtheit der Transportwege ist das Transportsystem. Mit dem Entwerfen des Transportsystems werden Entscheidungen darüber gefällt, welche Systemkomponenten als Informationsnachfrager mit welchen Systemkomponenten als Informationsanbieter interagieren und wie die Transportwege - ohne auf deren physische Realisierung einzugehen - gestaltet werden sollen (z.B. direkte Interaktion oder indirekte Interaktion). Bei den Entwurfsarbeiten in anderen Teilprojekten werden Entscheidungen gefällt, die sich nachhaltig auf das Entwerfen des Transportsystems auswirken. Dies gilt besonders für das Teilprojekt Arbeitsorganisation, in dem die örtliche Verteilung der betrieblichen Aufgaben (und damit der Aufgabenträger und Sachmittel) festgelegt wird. Je mehr das betriebliche Aufgabensystem örtlich verteilt ist, desto größer ist der Transportbedarf und desto umfangreicher das logische Transportmodell. Das Ermitteln von Informationsnachfrage und Informationsangebot kann sich an der Beantwortung folgender Fragen orientieren: 1. 2. 3. 4.

"Wozu?", also die Frage nach dem Zweck der Kommunikation. "Was?", also die Frage nach dem Inhalt der Kommunikation. "Wer?", also die Frage nach den Partnern der Kommunikation. "Wann?", also die Frage nach dem Zeitpunkt oder Zeitraum ("Termin") der Kommunikation.

60

Aufgaben der

Grobprojektierung

Abbildung WTRAN-2 zeigt, daß diese Fragen bereits bei "klassischen Berichtssystemen" als Gestaltungsaufgaben erkannt wurden; sie gibt auch Details zu den Aufgaben an. Die Frage nach dem "Wie?", also die Frage nach der physischen Realisierung des Transportsystems, ist Aufgabe des Entwickeins des Transportsystems (vgl. Lerneinheit ETRAN). Ergänzend zu den in Abbildung WTRAN-2 genannten sachlichen Gesichtspunkten ist beim Entwerfen des Transportsystems die Tatsache zu beachten, daß Kommunikation auch eine soziale Funktion hat. Art: mündlich fernmündlich schriftlich fernschriftlich Kombinationen sonstiges Form Methoden der Er- und Bearbeitung Informationswege

Inhalt: Berichtsangaben im eigentlichen Sinn Vergleichsangaben Zeitvergleich Betriebsvergleich Soll-Ist-Vergleich Soll: Vorschau Vorgabe Maßstab Verdichtungsgrad Genauigkeit Termine: laufende Berichterstattung mit festen Terminen laufende Berichterstattung mit freien Terminen Berichterstattung auf Abruf Bearbeitungszeit

Die Frage "wozu" ist die Frage nach dem Auswertungszweck: - vorgesehener Auswertungszweck - möglicher Auswertungszweck - tatsächlicher Auswertungszweck

Stellen zur Sammlung Erfassung Aufbereitung Verarbeitung Weiterleitung Bereithaltung Auswertung Ablage Vernichtung Personen (Gliederung wie oben)

Abb. WTRAN-2: Gestaltungsaufgaben des Informationsaustauschs (Quelle: Blohm)

Alternative

Transportwege

Für das Festlegen der Transportwege sind Kenntnisse über die grundsätzlichen Alternativen der Kommunikation und ihre Eigenschaften von Bedeutung. Dabei wird von einer Gliederung der Transportwege in interne Transportwege und externe Transportwege ausgegangen, weil der Transportbedarf und damit die Art der Transportwege für beide im allgemeinen sehr verschieden sind. Interne Transportwege dienen dem Informationstransport zwischen den Aufgabenträgern und Sachmitteln innerhalb eines Unternehmens; sie werden in ihrer Gesamtheit als "internes Transportsystem" bezeichnet. Externe Transportwege dienen dem Informationstransport zwischen den Aufgabenträgern und Sachmitteln eines Unternehmens und denen seiner Umwelt (z.B. Kunden und Lieferanten); sie werden in ihrer Gesamtheit als "externes Transportsystem" bezeichnet. Ein interner Transportweg kann als vertikaler Transportweg oder als horizontaler Transportweg sowie als Dienstweg oder als Direktweg gestaltet werden.

WTRAN - Entwerfen des Transportsystems

61

• Vertikaler Transportweg: Er ist der Unternehmenshierarchie angepaßt und entspricht dem organisatorischen Aufbau. Ein vertikaler Transportweg erstreckt sich von der Ausführungsebene bis zur Führungsebene, also von unten nach oben, wie auch umgekehrt (vgl. Abbildung WTRAN-3, linker Teil). • Horizontaler Transportweg: Er verbindet die Stellen gleicher Tätigkeitsebenen. Auf einem horizontalen Transportweg wird Information übermittelt, die dem Grundsatz gleicher Informationsbreite entspricht. Jede Spezifizierung oder Verdichtung verlagert die Kommunikation auf eine andere Ebene (vgl. Abbildung WTRAN-3, rechter Teil). • Dienstweg oder Direktweg: Von Dienstweg wird dann gesprochen, wenn Information genau nach dem Organigramm und den einzelnen Führungsebenen, also nach der Kompetenzverteilung, weitergegeben wird (vgl. Abbildung WTRAN-3). Von Direktweg wird gesprochen, wenn Information unter Ausschaltung der Kompetenzverteilung direkt zwischen zwei Kommunikationspartnern ausgetauscht wird (vgl. Abbildung WTRAN-3).

Direktweg

Dienstweg

Direktweg

Dienstweg

Abb. WTRAN-3: Vertikaler und horizontaler Transportweg (Quelle: nach Blohm)

Ziel bei der Schaffung und Ausgestaltung externer Transportwege ist die Herstellung oder Verbesserung der zwischenbetrieblichen Integration (genauer: die Integration bei der zwischenbetrieblichen Kommunikation). Potentielle Partner zwischenbetrieblicher Integration sind in erster Linie Kunden und Lieferanten sowie Dienstleistungsgeber wie Banken, Logistikunternehmen und Datenbankdienste, aber auch Behörden (z.B. Zollbehörde). Ist die zwischenbetriebliche Kommunikation durch Marktbeziehungen gekennzeichnet und wird die Kommunikation über elektronische Medien abgewickelt, werden die Märkte elektronische Märkte genannt (vgl. Lerneinheit ETRAN). Im Unterschied zum Entwerfen innerbetrieblicher Transportwege, sind für potentielle externe Transportwege, bei deren Schaffung und Ausgestaltung zwischenbetriebliche Integration hergestellt oder verbessert werden soll, vertragliche Vereinbarungen mit den Partnern über die Entwicklung und Einführung erforderlich (vgl. Lerneinheit RECHT im Band "Informationsmanagement"). Gegenstand der Vereinbarungen ist die Definition der Anforderungen an den Transportweg, im einzelnen: • Daten- und Funktionsanforderungen beschreiben, welche Daten von den Partnern benötigt werden, wie sie auf den Transportweg gelangen, welche Bearbeitungsvorgänge an ihnen ausgeführt werden und wie sie den Transportweg verlassen. Die Darstellung der Abläufe und Dokumente kann mit Hilfe von Vorgangsketten erfolgen; sie erleichtern den Vergleich mehrerer System-

62

Aufgaben der

Grobprojektierung

entwürfe (z.B. den Vergleich der Anzahl der Vorgänge je Systementwurf) und lassen sich dazu verwenden, Verlagerungen von Funktionen zwischen den Partnern zu "simulieren". Als Darstellungsmittel für Vorgangsketten kann ein Diagramm verwendet werden, in dessen Zeilen die Vorgänge (meist geordnet zu Vorgangsgruppen) und in dessen Spalten die am Vorgang beteiligten Funktionseinheiten, wie Aufgabenträger oder Organisationen (z.B. Endverbraucher, Hersteller, Zulieferer), stehen. In den Feldern des Diagramms wird durch grafische Symbole dokumentiert, welche Vorgänge von welchen Funktionseinheiten mit welcher Art von Operation ausgeführt werden; der Ablauf wird durch gerichtete Kanten dargestellt (vgl. Lerneinheit DARST). • Aus den Vorgangsketten ist ersichtlich, welche Schnittstellen zwischen den Partnern bestehen; diese müssen genau spezifiziert werden, damit sich die Partner bei der Systementwicklung entsprechend orientieren können. • In der Regel beeinflussen veränderte, zwischenbetrieblich integrierte Vorgangsketten auch die Ablauforganisation außerhalb der Vorgangsketten; die Veränderungspotentiale müssen in den Entwurf der Arbeitsorganisation eingebracht werden (vgl. Lerneinheit WAORG). • Wegen der Beteiligung außerbetrieblicher Partner, sind einschlägige vertragliche Regelungen zu empfehlen, die unter anderem Fragen des Datenschutzes und der Datensicherheit, Vorschriften zur Archivierung, vorgesehene Maßnahmen zur Fehlerbeseitigung und Erweiterungsmöglichkeiten behandeln. Eigenschaften

Ring

Stern

Kette

Geschwindigkeit

langsam

schnell

schnell

Genauigkeit

gering

gut

gut

Arbeitszufriedenheit

sehr gut

gering

sehr gering

Anpaßbarkeit

schnell

langsam

langsam

Abb. WTRAN-4: Bewertung alternativer Topologien

Alternative

Topologien

Ergänzend zum Gestalten der einzelnen Transportwege ist zu entscheiden, wie diese in ihrer Gesamtheit im Transportsystem angeordnet sein sollen. Dafür ist Information über die betriebswirtschaftlich bedeutsamen Eigenschaften alternativer Topologien erforderlich. Abbildung WTRAN-4 zeigt am Beispiel der Topologien Ring, Kette und Stern eine Bewertung verschiedener Eigenschaften. Die Bewertungen stammen aus verschiedenen, teilweise widersprüchlichen Befunden; sie sollen die Notwendigkeit der Zuordnung von konkreten Ausprägungen auf Eigenschaften und Topologien verdeutlichen. Ob und wenn ja welche Eigenschaften den Entwurf des Transportsystems bestimmen, hängt von den Planungszielen ab (vgl. Lerneinheit FORMZ). Nach Abbildung WTRAN-4 kann keine der genannten Topologien als eindeutig überlegen angesehen werden. Auffällig ist, daß sich die Kette und der Stern weitgehend gleich verhalten, während sich der Ring deutlich von den beiden anderen unterscheidet (bezüglich der "harten" Eigenschaften Geschwindigkeit und Genauigkeit

WTRAN - Entwerfen des Transportsystems

63

im negativen, bezüglich der "weichen" Eigenschaften Arbeitszufriedenheit und Anpaßbarkeit an sich ändernde Aufgaben im positiven Sinn). Daher wird das Transportsystem eines Informationssystems im allgemeinen als eine Mischung mehrerer Topologien ("Mischtopologie") entworfen (z.B. als Sternring), und verschiedene Informationssysteme eines Unternehmens haben in der Regel unterschiedliche Topologien. Beschreibungsmittel für Transportsysteme Die Betrachtung der formalen Eigenschaften des Transportsystems als eine geordnete Menge informationsnachfragender und informationsanbietender Komponenten eines Informationssystems zeigt dessen Übereinstimmung mit der Definition eines als Graph bezeichneten Gebildes, das heißt als eine Anzahl von Ecken, die in bestimmter Weise durch Kanten miteinander verbunden sind. Wenn informationsnachfragende und informationsanbietende Komponenten eines Informationssystems als Ecken und der zwischen ihnen bestehende Transportbedarf als Kanten abgebildet werden, dann ist es möglich, das Transportsystem formal als Graph zu beschreiben und mit der Graphentheorie mathematisch zu behandeln. Die Graphentheorie kann daher als geeignetes Beschreibungsmittel für Transportsysteme angesehen und entsprechend verwendet werden. Die Beschreibung soll jedoch nicht Selbstzweck sein, sondern die Voraussetzung für eine formale Behandlung von Transportsystemen schaffen, zum Beispiel für die Bewertung alternativer Transportsysteme anhand solcher Bewertungskriterien, die wesentliche Eigenschaften von Transportsystemen abbilden; die mathematische Formulierung eines Bewertungskriteriums ist eine graphentheoretische Maßzahl. Bereits aus der Adjazenzmatrix A(D) lassen sich Aussagen über bestimmte Eigenschaften des Transportsystems gewinnen (z.B. über den Eingangsgrad und über den Ausgangsgrad). Die meisten graphentheoretischen Maßzahlen gehen von der Entfernung zwischen zwei Ecken aus, wobei als Entfernung die "Länge des kürzesten Weges zwischen zwei Ecken" verstanden wird. Die Entfernungen werden im allgemeinen in einer Entfernungsmatrix E(D) abgebildet; sie werden entweder (bei einfachen Graphen) direkt aus dem Graphen abgelesen oder (bei komplexen Graphen) mit Hilfe mathematischer Verfahren (z.B. mit dem Verfahren von Hasse) rechnerisch ermittelt. Graphentheoretische Maßzahlen Auf Grundlage der Adjazenzmatrix A(D) und der Entfernungsmatrix E(D) lassen sich graphentheoretische Maßzahlen formulieren, die in zwei Gruppen gegliedert werden können: a) Maßzahlen, welche die relative Position einer Systemkomponente im Transportsystem kennzeichnen (1. bis 4. der nachfolgenden Aufzählung) und b) Maßzahlen, welche das Transportsystem insgesamt charakterisieren (5. bis 9. der nachfolgenden Aufzählung). • 1. Der Eingangsgrad aj einer Systemkomponente vi und der Ausgangsgrad a; einer Systemkomponente vj, d.h. die Anzahl der von vi ausgehenden Transportwege (= Zeilensumme der i-ten Zeile von A(D)) bzw. die Anzahl der in vj eingehenden Transportwege (= Spaltensumme der j-ten Spalte von A(D)).

64

Aufgaben der Grobprojektierung

• 2. Die größte Entfernung bj einer Systemkomponente vi zu allen anderen Systemkomponenten (= Maximum der i-ten Zeile von E(D)). • 3. Die relative Zentralität q einer Systemkomponente vj, d.h. das Verhältnis der Summe aller Entfernungen innerhalb des Transportsystems ("Dispersion", siehe auch unter 5.) zur Summe der Entfernungen von v; zu allen anderen Systemkomponenten des Transportsystems (= Quotient aus der Summe aller Elemente von E(D) und der Summe der Elemente der i-ten Zeile von E(D)). • 4. Die relative Randposition oder die relative Außenposition di einer Systemkomponente v;, d.h. die Differenz zwischen der maximalen Zentralität des Transportsystems und der vi zugehörigen Zentralität. • 5. Die Dispersion D, d.h. die Summe aller Entfernungen im Transportsystem (= Summe aller Elemente von E(D)). • 6. Der Diameter d, d.h. die größte Entfernung innerhalb des Transportsystems (= größter Wert in E(D)). • 7. Die Existenz eines Zentrums, d.h. einer Systemkomponente vi, deren größte Entfernung zu allen anderen Systemkomponenten (also deren bi) ein Minimum ist (= Minimum der Zeilen- bzw. Spaltenmaxima in E(D)). • 8. Der Radius r, d.h. die größte Entfernung vom Zentrum zu irgendeiner anderen Systemkomponente, also die größte Entfernung des Zentrums (= Maximum der dem Zentrum entsprechenden Zeile in E(D)). • 9. Die Existenz von Zerlegungspunkten, d.h. solcher Systemkomponenten, bei deren Wegfall das Transportsystem in mehrere Teilsysteme zerfällt. Vorgehensweise beim Entwerfen des Transportsystems Für das praktische Vorgehen beim Entwerfen des logischen Transportmodells kann ein rezeptartiges Vorgehen nicht angegeben werden. Aus den Aufgaben beim Entwerfen des Transportsystems sowie aus der Information über alternative Transportwege und alternative Topologien kann folgende, nach Arbeitsschritten geordnete Vorgehensweise abgeleitet werden (Abbildung WTRAN-5). • Erster Arbeitsschritt: Ermitteln der Informationsnachfrage. Dabei wird von den Schnittstellenanforderungen der angepaßten Grundkonzeption ausgegangen. Unter Verwendung der Entwurfsergebnisse zum Datensystem, zum Methodensystem und insbesondere zur Arbeitsorganisation (vor allem bezüglich der Zuordnung von Aufgaben auf Aufgabenträger) wird ermittelt, welche Systemkomponenten welche Information benötigen. Wichtige Attribute der Informationsnachfrage sind ihr Inhalt ("Was?"), ihre Termine ("Wann?") und ihre Menge ("Wieviel?"). Ergebnis des ersten Arbeitsschritts ist die systematische Darstellung aller nachfragenden Systemkomponenten und ihrer Informationen nach Inhalt, Termin und Menge. • Zweiter Arbeitsschritt: Ermitteln des Informationsangebots. Dabei wird ebenfalls von den Schnittstellenanforderungen der angepaßten Grundkonzeption ausgegangen und unter Verwendung der Entwurfsergebnisse zum Datensystem, zum Methodensystem und insbesondere zur Arbeitsorganisation festgestellt, in welchen Systemkomponenten welche Informationen vorhanden sind bzw. welche Informationen von ihnen erzeugt werden. Analog zur Informationsnachfrage sind der Inhalt ("Was?"), die Termine ("Wann?") und die Men-

WTRAN - Entwerfen des

Transportsystems

65

ge ("Wieviel?") wichtige Attribute des Informationsangebots. Ergebnis des zweiten Arbeitsschritts ist die systematische Darstellung aller anbietenden Systemkomponenten und ihrer Informationen nach Inhalt, Termin und Menge. Dritter Arbeitsschritt: Festlegen der Transportwege. Durch das Ermitteln der nachfragenden Systemkomponenten auf der einen und der anbietenden Systemkomponenten auf der anderen Seite wird ein "Informationsgebirge" herausgearbeitet; es zeigt das Spannungsfeld zwischen Informationsnachfrage und Informationsangebot in inhaltlicher, terminlicher und mengenmäßiger Hinsicht, das durch das Festlegen von Transportwegen zum Ausgleich gebracht werden muß. Jeder einzelne Transportweg hat den Zweck, die Nachfrage einer Systemkomponente nach Information und das Angebot einer Systemkomponente an Information zum Ausgleich zu bringen. Dabei können verschiedene Arten von Transportwegen vorgesehen werden (vgl. den Abschnitt "Alternative Transportwege"). Vierter Arbeitsschritt: Gestalten der Topologie. Beim Festlegen der Transportwege kann in der Regel nicht von einem generellen Ordnungsrahmen ausgegangen werden; das Transportsystem besteht daher zunächst nur aus einer ungeordneten Menge von Transportwegen. Die Ordnung erfolgt nach Mustern, die durch Topologien gegeben sind. Dazu sind zunächst die Eigenschaften zu bestimmen, die für das Bewerten alternativer Topologien und für die Auswahl einer Topologie von Bedeutung sind. Dabei erfolgt eine Orientierung an den Planungszielen, insbesondere an den Formalzielen (vgl. Lerneinheit FORMZ). Auf die Zweckmäßigkeit der Verwendung von Mischtopologien wurde bereits hingewiesen. Die Topologie des Transportsystems kann als Graph beschrieben und mit Hilfe graphentheoretischer Instrumente (wie z.B. Maßzahlen) mathematisch behandelt werden. Damit wird die quantitative Bewertung alternativer Topologien unterstützt.

Abb. WTRAN-5: Arbeitsschritte beim Entwerfen des Transportsystems

66

Aufgaben der Grobprojektierung

Demonstrationsbeispiel Für das in Abbildung WTRAN-6 gezeigte logische Modell eines Transportsystems, das im Sinn der Graphentheorie ein Digraph ist, werden zunächst die Adjazenzmatrix A(D) und die Entfernungsmatrix E(D) ermittelt (vgl. Abbildung WTRAN-7). Von den Informationen dieser beiden Matrizen ausgehend, werden die Werte der graphentheoretischen Maßzahlen errechnet und in Abbildung WTRAN-8 dargestellt.

v

(0

1 0 1 0 0 0

1 1 0 0

A (D) =

v

4

V1

1 1 0 1 1 0

0 0 1 0 0 0

Abb. WTRAN-6: Logisches Modell Transportsystem als Digraph

5

A

0 0 1 0 0 0

fo

0 0 0 0

E(D) =

1 1 2 2

V

°J

1 0 1 2 2 2

1 1 0 1 1 2

2 2 1 0 2 3

2 2 1 2 0 3

A

2 2 3 3

°J

Abb. WTRAN-7: Adjazenzmatrix A(D) und Entfernungsmatrix E(D)

aj ai bi ci di

vi

v

3 3 2 7,4 1,3

2 2 2 6,5 2,2

2

v

3

4 4 2 8,7 0

v

4

v

5

1 1 1 1 3 3 5,2 5,2 3,5 3,5

v

6

1 1 3 4,8 3,9

D = 52, d = 3, r = 3 Zentrum: vi,v2 und v3 Zerlegungspunkte: vi und v 3

Abb. WTRAN-8: Graphentheoretische Maßzahlen

Eine Kommentierung des vorliegenden Entwurfs aus der Sicht der graphentheoretischen Maßzahlen kann wie folgt lauten: Die Topologie des Transportsystems ist sehr "dicht", da sie - bei sechs Knoten - drei Zentren hat (vi, und V3). Zwei dieser Zentren (vi und V3) sind auch Zerlegungspunkte, bei deren Ausfall das Transportsystem in mehrere Teile zerfällt. Soll oder kann diese Eigenschaft nicht verändert werden, sind die aus dem Entwurf des Transportsystems resultierenden Sicherungsanforderungen im Sicherungssystem (vgl. Lerneinheit WSICH) zu berücksichtigen. Letztlich wird dann bei der Implementierung von Sicherungs-

WTRAN - Entwerfen des Transportsystems

67

maßnahmen dafür gesorgt, daß auch bei Ausfall der Knoten vi und/oder V2 die Funktionsfähigkeit des Transportsystems aufrecht erhalten bleibt. Forschungsbefunde U. Oppelt fand in mehreren Untersuchungen von Arbeitsabläufen der Auftragsabwicklung folgende Verteilung der Durchlaufzeit bestätigt: Transportzeit rd. 50%, Liegezeit rd. 45% und Bearbeitungszeit rd. 5%. Demnach sind rd. 95% der Durchlaufzeit nicht wertschöpfend. Diese (und zahlreiche ähnlich lautende) Befunde weisen auf die Bedeutung der Gestaltung des Transportsystems hin mit dem Ziel, die Transportzeiten drastisch zu verkürzen. Effekte aus der Verkürzung der Bearbeitungszeit sind vemachlässigbar klein. Methodenverweise Vorgehensweise bei der Grobprojektierung (Lerneinheit VGROB); Optimierungsmodelle (Lerneinheit OPMOD); Prinzipien der Arbeitsorganisation (Lerneinheit PAORG); Integrationsprinzipien (Lerneinheit PINTE). Kontrollfragen 1. Welche Aufgaben sind beim Entwerfen des Transportsystems zu bearbeiten? 2. Welche alternativen Transportwege gibt es im internen Transportsystem? 3. Welche Rolle spielt die zwischenbetriebliche Integration beim Entwerfen des Transportsystems? 4. Mit welchen Kriterien können alternative Topologien bewertet werden? 5. Welchen Beitrag kann die Graphentheorie beim Entwerfen des Transportsystems leisten? Quellenliteratur Blohm, H.: Die Gestaltung des betrieblichen Berichtswesens als Problem der Leitungsorganisation. Verlag Neue Wirtschafts-Briefe, Herne/Berlin 1970 Heinrich, L. J.: Zur rechnerischen Lösung von Organisationsproblemen mit Hilfe der Graphentheorie. In: Layer, M. (Hrsg.): Rechnungswesen und Betriebswirtschaftspolitik. Schmidt Verlag, Bielefeld 1969, 169 - 179 Kubicek, H.: Informationsverbund, überbetrieblicher. In: Frese, E. et al. (Hrsg.): Handwörterbuch der Organisation. 3. A., Poeschel Verlag, Stuttgart 1992,994- 1009 Vertiefungsliteratur Bössmann, E.: Die ökonomische Analyse von Kommunikationsbeziehungen in Organisationen. Springer Verlag, Berlin et al. 1967 Hasse, M.: Über die Behandlung graphentheoretischer Probleme unter Verwendung der Matrizenrechnung. In: Wissenschaftliche Zeitschrift der Technischen Universität Dresden, 10/1961, 1313-1316 Oppelt, U.: EDI-Implementierung in der Praxis - Voraussetzungen, Vorgehensweise, Wirtschaftlichkeit. In: Reichwald, R. (Hrsg.): Marktnahe Produktion. Gabler Verlag, Wiesbaden 1992, 68-81

WSICH - Entwerfen des Sicherungssystems Lernziele Sie verstehen das Entwerfen des Sicherungssystems für ein Informationssystem als eine Querschnittsaufgabe der Grobprojektierung. Sie können Sicherungsbedarfe in eine Systematik einordnen und kennen die Zusammenhänge zwischen Gefahren und den daraus möglicherweise entstehenden wirtschaftlichen Schäden. Sie können die Vorgehensweise zum Herausarbeiten der Sicherungsbedarfe in Entwurfsschritte gliedern. Sie kennen die besonderen Sicherheitsrisiken, die durch den Einsatz von PCs entstehen. Definitionen und Abkürzungen BDSG = Akronym für Bundesdatenschutzgesetz; amtliche Abkürzung für das Gesetz zum Schutz vor Mißbrauch personenbezogener Daten bei der Datenverarbeitung der Bundesrepublik Deutschland, biometrische Daten (biometric data) = Daten über personenspezifische Merkmale wie Adernstruktur des Augenhintergrunds, Geometrie der Hand und des Gesichts, Fingerabdruck, Sprache, Unterschriftsdynamik, deliktische Handlung (crime) = eine strafbare oder als strafwürdig angesehene Handlung, deren Ziel die unberechtigte Nutzung oder die Zerstörung der Informationsinfrastruktur oder einzelner ihrer Komponenten ist. DSG = Akronym für Datenschutzgesetz; amtliche Abkürzung für das österreichische Bundesgesetz über den Schutz personenbezogener Daten. Fehler (error) = die Abweichung einer Größe von einem geplanten (z.B. einem theoretisch exakten) Wert. Gefahr (threat) = ein Ereignis, das auf die Komponenten eines Informationssystems so einwirken kann, daß ein Schaden entsteht. Synonym: Bedrohung, personenbezogene Daten (personal data) = im Sinn der Datenschutzgesetze Daten, die Informationen über persönliche oder sachliche Verhältnisse einer bestimmten oder mit Wahrscheinlichkeit bestimmbaren Person geben. Risiko (risk) = die Wahrscheinlichkeit des Auftretens eines unerwünschten Ereignisses in einem bestimmten Zeitraum und der mit diesem Ereignis verbundene Schaden. Sicherheit (security) = der Zustand eines Systems, der durch Sicherheitsziele vorgegeben ist und der durch Sicherungsmaßnahmen erreicht werden soll. Sicherheitsziel (security goal) = ein Ziel, das das Erreichen eines bestimmten Ausmaßes an Sicherheit vorgibt. Sicherungsbedarf (backup need) = die Art und die Menge der Sicherung, die wegen der bestehenden Sicherheitsrisiken erforderlich ist, um definierte Sicherheitsziele zu erfüllen. Unzuverlässigkeit (unreliability) = die Tatsache, daß ein System die durch die Aufgabenstellung bedingten Funktionen mit einer definierten Wahrscheinlichkeit nicht ausführen kann. Verfügbarkeit (availability) = die Zeitspanne, in der ein System die durch die Aufgabenstellung bedingten Funktionen fehlerfrei ausführt.

WSICH - Entwerfen des Sicherungssystems

69

Schnittstellen beim Entwerfen des Sicherungssystems Die Schnittstellen beim Entwerfen des Sicherungssystems sind durch die nachfolgend beschriebenen Inputs und Outputs gekennzeichnet. Inputs zum Entwerfen des Sicherungssystems sind: • die definierten Sicherheitsziele (vgl. Lerneinheit FORMZ) als Ergebnis der Anforderungsanalyse; • die Systementwürfe in den Teilprojekten Datensystem (vgl. Lerneinheit WDASY), Methodensystem (vgl. Lerneinheit WMESY), Arbeitsorganisation (vgl. Lerneinheit WAORG) und Transportsystem (vgl. Lerneinheit WTRAN). Outputs des Entwerfens des Sicherungssystems sind: • der Systementwurf im Teilprojekt Sicherungssystem, durch den Entwurfsentscheidungen in anderen Teilprojekten beeinflußt werden; • das Ergebnis des Entwerfens des Sicherungssystems, also die vorhandenen Sicherungsbedarfe. Abbildung WSICH-1 zeigt die Einbettung des Entwerfens des Sicherungssystems in die genannten Inputs und Outputs. Die seitliche Anordnung des Inputs "Systementwürfe anderer Teilprojekte" deutet auf den interaktiven Zusammenhang der Entwurfsarbeiten in allen Teilprojekten hin. Der Weg von den Inputs zum Ergebnis des Entwerfens des Sicherungssystems umfaßt insbesondere das Herausarbeiten der Sicherungsbedarfe aus den Systementwürfen der anderen Teilprojekte. Dies kann auch so verstanden werden, daß mit den Entwurfsentscheidungen in den Teilprojekten die Sicherheitsrisiken bestimmt sind, die - unter Berücksichtigung der Sicherheitsziele - Sicherungsbedarfe sind.

Abb. WSICH-1: Inputs und Outputs beim Entwerfen des Sicherungssystems

Beim Herausarbeiten der Sicherungsbedarfe für ein Informationssystem muß darauf geachtet werden, ob Sicherungsbedarfe in bereits installierten Komponenten der Informationsinfrastruktur ausgelöst werden (z.B. wenn durch Vernetzung zusätzliche Sicherheitsrisiken geschaffen werden). Die notwendigen Konsequenzen daraus sind jedoch nicht Gegenstand des IuK-Projekts (vgl. Lerneinheiten SICHM und KATAM im Band "Informationsmanagement").

70

Aufgaben der Grobprojektierung

Aufgaben beim Entwerfen des Sicherungssystems Beim Entwerfen des Sicherungssystems steht das Herausarbeiten der Sicherungsbedarfe, die sich aus dem Abgleich der Sicherheitsrisiken der Entwürfe im Datensystem, im Methodensystem, in der Arbeitsorganisation und im Transportsystem mit den definierten Sicherheitszielen ergeben, im Mittelpunkt. Dies weist auf die Notwendigkeit hin, die Sicherheitsziele bereits beim Systementwurf in allen Teilprojekten so zu berücksichtigen, daß die entstehenden Sicherungsbedarfe möglichst klein sind (z.B. durch umfangreiche Integritätsbedingungen im logischen Datenmodell). Wegen der herausragenden Bedeutung der Daten als wirtschaftliches Gut, steht das Herausarbeiten der Sicherungsbedarfe im Datensystem und damit die Datensicherheit meist im Vordergrund. Eine Einschränkung des Sicherheitsproblems auf Datensicherheit kann aber nicht zu einem Sicherungssystem führen, das in der Lage ist, die definierten Sicherheitsziele zu erfüllen. Ohne Kenntnis konkreter Zielformulierungen kann ein Informationssystem als sicher bezeichnet werden, wenn es die folgenden Bedingungen erfüllt: • Es befindet sich in betriebsfähigem Zustand, ohne irgendwelche Beeinträchtigung, mit anderen Worten: es ist für die Benutzer mit allen Funktionen und Daten verfügbar ("Verfügbarkeit"). • Es erfüllt die von den Benutzern erwarteten Funktionen planmäßig und stellt die erwarteten Daten fehlerfrei bereit ("Integrität"). • Es läßt die unberechtigte Nutzung von Funktionen und die unberechtigte Verwendung von Daten nicht zu ("Vertraulichkeit"). Ein Sicherungssystem ist nur in dem Ausmaß wirtschaftlich vertretbar, in dem der zu seiner Schaffung und Aufrechterhaltung erforderliche Aufwand in einem angemessenen Verhältnis zum angestrebten, durch die Sicherheitsziele definierten Nutzen steht, der mit dem abgewendeten Schaden identisch ist. Verletzungen der Sicherheit können zunächst zu einem realen Schaden führen (z.B. der Diebstahl eines Datenträgers). Ein realer Schaden führt zu einem wirtschaftlichen Schaden, wenn er - über den realen Schaden hinaus - Aufwendungen verursacht (z.B. für das Wiederherstellen der Daten) und/oder zu Ertragsausfällen führt (z.B. wegen der NichtVerfügbarkeit von Daten). Verletzungen der Sicherheit können auch ohne sichtbaren realen Schaden unmittelbar einen wirtschaftlichen Schaden verursachen (z.B. der Datendiebstahl durch Kopieren). Wirtschaftliche Schäden dieser Art sind oft von größerer Bedeutung als die aus realen Schäden resultierenden, weil sie weniger leicht (oder gar nicht) erkennbar sind, sodaß Gegenmaßnahmen nicht oder nicht rechtzeitig ergriffen werden können. Diese Beispiele führen zu einer Systematik der Sicherungsbedarfe, die nach den Gefahren, die auf Objekte eines Informationssystems einwirken können, gebildet wird (vgl. Abbildung WSICH-2). Sicherheitsrisiken können durch Fehler (verursacht von Menschen und Betriebsmitteln), durch deliktische Handlungen und durch Umgebungseinflüsse ausgelöst werden. Die Felder der Matrix sind die Sicherungsbedarfe, die bei Einwirken der Gefahren auf die Objekte dann entstehen, wenn die damit verbundenen Sicherheitsrisiken größer sind, als es die definierten Sicherheitsziele erlauben. Die Objekte, die in Abbildung WSICH-2

WSICH

- Entwerfen

des

Sicherungssystems

71

deliktische Handlungen

Gefahren Fehler

\

Objekte

Umgebungseinflüsse

verwendet werden, sind die Entwürfe aus Datensystem, Methodensystem, Arbeitsorganisation und Transportsystem. Gefahrengliederung und Objektgliederung können verfeinert werden.

Datenbasen Programme Arbeitsabläufe Abb. WSICH-2: Systematik der Sicherungsbedarfe

Transportwege

Vorgehensweise beim Entwerfen des Sicherungssystems Eine Vorgehensweise beim Entwerfen des Sicherungssystems kann mit den in Abbildung WSICH-3 gezeigten Arbeitsschritten angegeben werden. Definierte Sicherheitsziele y / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / j

Feststellen der potentiellen Gefahren Feststellen der Sicherheitsrisiken Abgleichen mit den Sicherheitszielen m

m

m

m

m

m

m

f

o

.

Vorhandene Abb. WSICH-3: Arbeitsschritte beim Sicherungsbedarfe W m E n t w e r f e n d e s S ichenin E ssvstems ' / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / M W cntwenen aes iicneningssystems Erster Arbeitsschritt: Feststellen der potentiellen Gefahren. Fehler, deliktische Handlungen und Umgebungseinflüsse können sehr unterschiedlicher Art sein (z.B. Handhabungsfehler, Hardware-Fehler, Software-Fehler bei der Gefahr "Fehler"). Die konkrete Ausprägung der Gefahren ist von vielen spezifischen Bedingungen abhängig, die nur in einer konkreten Anwendungsumgebung festgestellt werden können (z.B. die Art der Handhabungsfehler von der Qualifikation des Personals und der Handhabbarkeit der Objekte). Ausgehend von der Gesamtheit der möglichen Gefahren, sind diese daher so zu selektieren

72

Aufgaben der Grobprojektierung

und zu präzisieren, daß ein möglichst realistisches Bild der Gefahrensituation entsteht, die für das zu schaffende Informationssystem gültig ist. Diese Aufgabe ist vor allem deshalb mit Gründlichkeit durchzuführen, weil ein Schutz nur vor solchen Gefahren möglich ist, die bekannt sind. • Zweiter Arbeitsschritt: Feststellen der Sicherheitsrisiken. Dazu wird die gegebene Objektgliederung soweit verfeinert, daß zunächst für jedes Teilobjekt eine Aussage darüber gemacht werden kann, welche Gefahren auf die Teilobjekte einwirken können. In der Darstellung der Abbildung WSICH-2 kann man sich das Ergebnis dieser Analyse als einfache Eintragungen in die Felder der Matrix vorstellen (z.B. Handhabungsfehler X wirkt auf Datenbasis Y ein). Davon ausgehend, wird für jedes besetzte Feld der Matrix eine genaue Beschreibung der Art und des Umfangs der Einwirkung herausgearbeitet, sodaß es möglich ist, das Sicherheitsrisiko zumindest abzuschätzen. Vielfach ist es möglich, das Sicherheitsrisiko mit quantitativen Meßgrößen zu erfassen (z.B. die Häufigkeit und die durchschnittliche Dauer der Unterbrechung eines Transportwegs, mit der die Höhe des wirtschaftlichen Schadens bestimmt wird). • Dritter Arbeitsschritt: Abgleichen mit den Sicherheitszielen. Mit den definierten Sicherheitszielen ist die Meßlatte gelegt, an der die Zulässigkeit der festgestellten Sicherheitsrisiken beurteilt wird. Alle Sicherheitsrisiken, welche die Erreichung eines Sicherheitsziels verletzen, sind Sicherungsbedarfe; sie müssen durch Sicherungsmaßnahmen neutralisiert werden (vgl. Lerneinheit ESICH). Beim Herausarbeiten der Sicherungsbedarfe sind auch solche Sicherheitsrisiken zu berücksichtigen, die nicht durch projektspezifische Sicherheitsziele definiert, sondern extern vorgegeben sind. Dies gilt insbesondere für das Datensystem und den Fall, daß personenbezogene Daten zur Datenbasis gehören (z.B. bei Personal-Informationssystemen oder wenn Sicherungsmaßnahmen implementiert werden sollen, die zur Authentifikation biometrische Daten verwenden). Die einschlägigen Bestimmungen der Datenschutzgesetze sind zu beachten (BDSG und Datenschutzgesetze der Bundesländer in Deutschland, DSG in Österreich). Der Hinweis auf biometrische Daten zeigt, daß auch durch Sicherungsmaßnahmen selbst bestimmte Sicherungsbedarfe ausgelöst werden können. Sicherheitsrisiken im PC-Bereich Gegenüber zentralen Hostsystemen treten in einer PC-Umgebung zusätzliche Sicherheitsrisiken auf, wie die folgenden Beobachtungen zeigen: • Das Sicherheitsbewußtsein der PC-Benutzer ist unterentwickelt. • Es gibt kein geschultes Bedienungspersonal. • Eine klare organisatorische Funktionstrennung (z.B. in Systemverwaltung, Benutzung und Programmierung) ist in der Regel nicht vorhanden. • Systemfunktionen werden neben anderen Aufgaben "nebenbei" ausgeübt. • Arbeitsvorgänge werden nicht überprüft. • Die PCs sind vielen Personen zugänglich. • PCs lassen sich leicht wegtragen. • Das Betriebssystem bietet kaum Schutzmechanismen. • Daten lassen sich leicht auf Diskette kopieren oder ausdrucken.

WSICH - Entwerfen des Sicherungssystems

73

• Die Anfertigung von Sicherungskopien ist umständlich und wird daher oft vernachlässigt. • Angefertigte Sicherungskopien werden nicht sicher verwahrt. • Schutzmechanismen (z.B. Hardware-Schlösser) lassen sich leicht "knacken". Sind PCs vernetzt und haben sie Zugang zum Hostsystem, sind sie nicht nur selbst ein Sicherheitsrisiko, sondern sie können auch für Angriffe auf das Hostsystem benutzt werden. Dabei kann die "Intelligenz" des PCs (im Unterschied zu einem Terminal) ausgenutzt werden (z.B. zum Herausfinden von Paßwörtern durch Probieren). Zusätzliche Sicherheitsrisiken entstehen, wenn Mitarbeiter mobile PCs verwenden und von außen mit dem Hostsystem kommunizieren (z.B. Einschleppen von Viren). Der erfolgversprechendste Weg, die Sicherheitsrisiken im PC-Bereich in den Griff zu bekommen, ist die Verschlüsselung der Daten (vgl. Lerneinheit KRYPT); die damit verbundenen Laufzeitverluste müssen in Kauf genommen werden. Demonstrationsbeispiel Es wird gezeigt, daß im Transportsystem besondere Sicherheitsrisiken dann liegen, wenn es stark verteilt ist und daher sowohl innerbetriebliche als auch überbetriebliche Netze verwendet werden. Hauptgrund dafür ist, daß sich Netze bereits wegen ihrer örtlichen Ausdehnung physisch nicht leicht schützen lassen. Daneben birgt die technische Realisierung der Netze (z.B. die Protokolle) erhebliche Sicherheitslücken, die von Angreifern ausgenutzt werden können. Der am leichtesten zugängliche Angriffspunkt für einen Lauschangriff ist die Leitung, also das physische Netzmedium. Funkstrecken sind besonders leicht abhörbar. Bei Kabelstrecken kann der Angreifer die elektromagnetische Abstrahlung für einen Lauschangriff nutzen ("Nebensprecheffekt"). Außer der Abstrahlung, bieten Leitungen folgende Angriffsmöglichkeiten: • • • • •

Anzapfen der Leitung; Angriff auf Kommunikationseinrichtungen (z.B. Modem, Knotenrechner); Anbringen von Schnittstellentestern an Steckerverbindungen; Besetzen nicht benutzter Anschlußpunkte; Manipulieren von besetzten Anschlüssen (z.B. durch Adreßfälschung).

Lichtwellenleiter haben den Vorteil, nicht elektromagnetisch abzustrahlen; auch sind sie vergleichsweise schwer anzuzapfen. Metallkabel lassen sich leicht und unbemerkt anzapfen. In Fernverkehrsnetzen können die Nutzdaten verschlüsselt werden; die Verbindungsdaten sind dagegen nicht verschlüsselt. Aus diesen kann ein Angreifer Verkehrsflußanalysen und Teilnehmerprofile erstellen (was z.B. bei finanziellen Transaktionen ein erhebliches Sicherheitsrisiko sein kann). In Lokalen Netzen entsteht ein Sicherheitsrisiko auch dadurch, daß Teile des Betriebssystems über das Netz verschickt werden; dies ermöglicht es einem Angreifer, Trojanische Pferde einzubringen. Sicherheitsrisiken dieser Art korrespondieren häufig mit einfacher Handhabung (z.B. das unterbrechungsfreie Einfügen zusätzlicher Arbeitsstationen in einem Lokalen Netz), woraus folgt, daß sie nicht immer ausreichend beachtet werden.

74

Aufgaben der Grobprojektierung

Weitere Sicherheitsrisiken in Netzen gehen von folgenden Gefahren aus: • Datenverfälschung durch Wiederholen von Nachrichten, Einfügen von Daten, Verändern von Daten (z.B. Änderung einer Kontonummer im Überweisungsverkehr), Konstruieren von falschen Nachrichten, Löschen von Nachrichten, Einschleusen von Viren. • Fernzugriffe, das heißt Zugriffe von einem Rechnersystem auf ein anderes. • Sabotage durch Zerstören von Leitungen und Knoten, durch Störung der Übertragung (z.B. durch elektromagnetische Einwirkung), durch Unterbrechen des Netzes. Methodenverweise Vorgehensweise bei der Grobprojektierung (Lerneinheit VGROB); Integrationsprinzipien (Lerneinheit PINTE). Kontrollfragen 1. 2. 3. 4. 5.

Welches Ergebnis soll das Entwerfen des Sicherungssystems liefern? Wann ist ein Informationssystem als "sicher" zu bezeichnen? Welche Gefahrenquellen werden unterschieden? Mit welchen Arbeitsschritten wird beim Entwerfen des Sicherungssystems vorgegangen? Warum liegen im PC-Bereich besondere Sicherheitsrisiken?

Quellenliteratur Krallmann, H.: EDV-Sicherheitsmanagement. Integrierte Sicherheitskonzepte für betriebliche Informations- und Kommunikationssysteme. Schmidt Verlag, Berlin 1989 Pommerening, K.: Datenschutz und Datensicherheit. B.I. Wissenschaftsverlag, Mannheim et al. 1991 Vertiefungsliteratur Heilmann, W. und Reusch, G. (Hrsg.): Datensicherheit und Datenschutz. Hilfen zur Bestimmung des eigenen Standpunkts. Forkel Verlag, Stuttgart/Wiesbaden 1984 Schuppenhauer, R.: Grundsätze für eine ordnungsgemäße Datenverarbeitung. IdW-Verlag, Düsseldorf 1982 Weck, G.: Datensicherheit. Methoden, Maßnahmen und Auswirkungen des Schutzes von Information. Teubner Verlag, Stuttgart 1984

WINTE - Integration der Systementwürfe Lernziele Sie kennen die Aufgaben der Systemintegration beim Systementwurf. Sie erkennen, warum Potentiale für Integrationsdefizite beim Systementwurf entstehen und lernen Maßnahmen kennen, mit deren Hilfe Integrationsdefizite vermieden oder abgebaut werden können. Sie erkennen, daß das Entstehen und das Bestehenbleiben von Integrationsdefiziten häufig psycho-soziale und nicht ökonomische Ursachen hat. Definitionen und Abkürzungen Akzeptanz (acceptance) = die Eigenschaft eines Ergebnisses der Systemplanung, die Zustimmungsbereitschaft bei den Betroffenen (z.B. Anwender und Benutzer) zu finden. Arbeitsteilung (work partitioning) = die Zerlegung einer Aufgabe in gleichartige oder ähnliche Tätigkeiten und deren Zuordnung auf Aufgabenträger. Integration (integration) = die Herstellung oder Wiederherstellung eines Ganzen durch Vereinigen oder Verbinden logisch zusammengehöriger Teile. Integrationsdefizit (lack of integration) = die fehlende oder nicht ausreichende Abstimmung zwischen den Entwürfen der Teilsysteme. Integrationstest (integration test) = ein Test, mit dem das Zusammenwirken der Komponenten eines Systems überprüft wird. Synonym: Schnittstellentest. Interdependenz (interdependence) = eine Beziehungsform zwischen Elementen, Funktionen, Personen usw., die dadurch gekennzeichnet ist, daß A von B in der Weise abhängig ist, in der B von A abhängig ist. Kompetenz (competence) = der Handlungsspielraum eines Aufgabenträgers, der zur ordnungsgemäßen Aufgabenerfüllung erforderlich ist. Konflikt (conflict) = eine durch Interessensgegensätze gekennzeichnete Beziehung zwischen Personen oder Gruppen. Kooperation (Cooperation) = ein sozialer Prozeß mehrerer Aufgabenträger zur Erreichung gemeinsamer Ziele. Koordination (coordination) = die Abstimmung von interdependenten Tätigkeiten, die von mehreren Aufgabenträgern durchgeführt werden. Koordinator (coordinator) = ein Aufgabenträger für die Aufgabe "Sicherstellung der Kommunikation zwischen den Fachabteilungen und der IKS-Abteilung"; sein Arbeitsplatz ist in der Fachabteilung. Projektorganisation (project Organization) = die Art und Weise, in der ein Projektleiter eine Projektgruppe führt und die Projektaufgaben beeinflussen kann. Systementwurf (systems design) = das Ergebnis der Grobprojektierung, mit anderen Worten: das logische Modell des zu schaffenden Informationssystems. Systemintegration (systems integration) = der Vorgang des Zusammenfügens der Entwürfe von Teilsystemen zum Entwurf des Gesamtsystems. Test (test) = die nach einer vorab festgelegten, kontrollierbaren Methode durchgeführte experimentelle Untersuchung eines Objekts zur Feststellung bestimmter Eigenschaften.

76

Aufgaben der Grobprojektierung

Zweck der Systemintegration Zweck der Systemintegration ist es, die Systementwürfe so untereinander und mit der Informationsinfrastruktur abzustimmen, daß ein logisches Modell des Informationssystems entsteht, das Grundlage für die Entwicklung der physischen Modelle in den Teilprojekten und letztlich für ein produktives Informationssystem ist. Zwei unterschiedliche Integrationsfelder sind daher zu betrachten: die in den einzelnen Teilprojekten arbeitsteilig entworfenen Komponenten eines Informationssystems (Integration zwischen den entworfenen Teilsystemen) und die Abstimmung der Systementwürfe mit der vorhandenen Informationsinfrastruktur. Aufgaben der Systemintegration Abbildung WINTE-1 zeigt die beiden Integrationsfelder, aus denen die Aufgaben der Systemintegration abgeleitet werden können. Die sechs Kanten verdeutlichen das erste Integrationsfeld, die Einbettung der logischen Modelle in die bestehende Informationsinfrastruktur das zweite Integrationsfeld. Da das Entwerfen des Sicherungssystems als Querschnittsaufgabe verstanden wird, nennt Abbildung WINTE-1 das Sicherungssystem nicht. Logisches Modell Datensystem

Logisches Modell Arbeitsorganisation

X

Logisches Modell Methodensystem

Logisches Modell Transportsystem

Informationsinfrastruktur

Abb. WINTE-1 : Aufgaben bei der Integration der Systementwürfe

Integration zwischen den Teilsystemen: Das Entwerfen jedes einzelnen Teilsystems erfolgt unter Berücksichtigung der Entwurfsergebnisse der anderen Teilsysteme und des vorhandenen Bestands der Informationsinfrastruktur; dies reicht jedoch meist nicht aus, um eine volle Integration der Systementwürfe zu gewährleisten. Integrationsbedarfe können daher nach dem Systementwurf in den Teilprojekten zwischen allen Teilsystemen bestehen, das heißt: • zwischen dem logischen Modell des Datensystems und dem logischen Modell des Methodensystems; • zwischen dem logischen Modell des Datensystems und dem logischen Modell des Transportsystems; • zwischen dem logischen Modell des Datensystems und dem logischen Modell der Arbeitsorganisation; • zwischen dem logischen Modell der Arbeitsorganisation und dem logischen Modell des Methodensystems; • zwischen dem logischen Modell der Arbeitsorganisation und dem logischen Modell des Transportsystems;

WINTE - Integration der Systementwürfe

77

• zwischen dem logischen Modell des Methodensystems und dem logischen Modell des Transportsystems. Integration zwischen den Teilsystemen und der Informationsinfrastruktur: Beim Entwerfen jedes einzelnen Teilsystems muß auch der vorhandene Bestand der Informationsinfrastruktur berücksichtigt werden. Aufgabenschwerpunkte dieser Integration bestehen zwischen dem logischen Modell des Datensystems und dem bestehenden Datensystem des Unternehmens sowie zwischen dem logischen Methodenmodell und dem bestehenden Methodensystem des Unternehmens. Arbeitsteilung, Koordination und Kooperation Im Unterschied zur Systemintegration bei der Systementwicklung (vgl. Lerneinheit EINTE), können zur Integration der Systementwürfe Integrationsmaßnahmen nicht präzise angegeben werden, weil die auf der Entwurfsebene vorhandenen Produkte der Systemplanung in Form logischer Modelle nicht so konkret faßbar sind wie die Produkte der Systementwicklung in Form physischer Modelle. Integrationsmaßnahmen konzentrieren sich, daher darauf, die Ursachen für das Entstehen von Integrationsbedarfen zu erkennen und durch geeignete Vorkehrungen dafür zu sorgen, daß sie beim Entwerfen der Teilsysteme so weit wie möglich vermieden werden. Wichtigste Ursache für das Entstehen von Integrationsbedarfen auf der Entwurfsebene ist die Arbeitsteilung bei der Systemplanung; wichtigste Maßnahmen zur Beseitigung oder zumindest zur Reduzierung der Auswirkungen der Arbeitsteilung sind Kooperation und Koordination. Die komplexe Aufgabe "Systemplanung" muß in eine Reihe von Teilaufgaben zerlegt werden, die spezialisierten Aufgabenträgern (Personen, Gruppen oder Sachmitteln) zugeordnet werden. Die Folge dieser Arbeitsteilung ist Kooperation zwischen den Beteiligten sowie Koordination der von ihnen durchgeführten (arbeitsteiligen) Arbeitsprozesse unter funktionalen, räumlichen, zeitlichen, informatorischen, kompetenzmäßigen und verantwortungsmäßigen Gesichtspunkten sowie eine Abstimmung der Ziele der Beteiligten. Durch eine geeignete Projektorganisation (vgl. Lerneinheit PROPL) wird versucht, die Anforderungen an Kooperation und Koordination "in den Griff' zu bekommen. Projektorganisation reicht aber erfahrungsgemäß nicht aus, um negative Folgen der Arbeitsteilung zu vermeiden bzw. auftretende negative Folgen zügig zu beseitigen. Auch eine "gute" Projektorganisation kann negative Folgen der Arbeitsteilung nicht vermeiden. Das ist unter anderem darauf zurückzuführen, daß Kooperation und Koordination zu ausschließlich unter ökonomischen Zielen (wie Produktivität und Wirtschaftlichkeit) betrachtet werden. Eine "gute" Projektorganisation wird primär als ein Instrument verstanden, das nach Produktivität und Wirtschaftlichkeit gestaltet wird; psycho-soziale Ziele bleiben häufig unbeachtet. Im allgemeinen wird die Arbeitsteilung unter ökonomischen Zielen positiv bewertet (vgl. Lerneinheit WAORG); für die Systemplanung trifft dies häufig nicht zu. Das gilt sowohl für die Arbeitsteilung zwischen Spezialisten (wie Systemplaner, Organisator, Anwendungsprogrammierer und Informationsmanager), als

78

Aufgaben der Grobprojektierung

auch und vor allem für die Arbeitsteilung zwischen den Spezialisten auf der einen Seite und den Mitarbeitern der Fachabteilungen auf der anderen Seite (vgl. Lerneinheit AUTER). Soweit die Folgen der Arbeitsteilung unter ökonomischen Zielen positiv bewertet werden können, hält dieses Urteil nicht immer stand, wenn psycho-soziale Ziele in die Betrachtung einbezogen werden. Negative Folgen der Arbeitsteilung drücken sich beispielsweise durch mangelhafte Akzeptanz der Entwurfsergebnisse bei den Benutzern aus. Schnittstellen und Systemintegration Die Arbeitsteilung ist heute für die Systemplanung kennzeichnend; sie wird dies auch in Zukunft bleiben. Der Grad der Arbeitsteilung wird allerdings abnehmen (siehe dazu den Abschnitt "Gestaltungsmaßnahmen"). Systemplaner haben die Aufgabe, die Integrationsanforderungen zu erkennen und durch Schnittstellen zu beschreiben. Dabei dürfen die Schnittstellen nicht nur als ein technisches oder allenfalls als ein technisch-organisatorisches Problem, das allein mit den Methoden und Werkzeugen der Projektorganisation gelöst werden kann, gesehen werden. Dies ließe keinen Raum für die Lösung inhaltlicher Konflikte zwischen den Beteiligten. Folglich bedarf es für eine problemgerechte Beschreibung der Schnittstellen einer stärkeren Hinwendung zu den kommunikativen Tätigkeiten der Beteiligten. Diese Tätigkeiten müssen erklärt und durch geeignete Methoden und Werkzeuge der Projektorganisation sowie durch den Einsatz von Kommunikationstechniken unterstützt werden. Das setzt eine Erklärung der für jeden Aufgabenträger der Systemplanung typischen Aufgabenstruktur voraus sowie die Untersuchung der Bedingungen und Formen der sozialen Einbindung jedes Aufgabenträgers in den Prozeß der Systemplanung. In beiden Bereichen besteht ein Mangel an ausreichenden Erklärungen. Gestaltungsmaßnahmen der Systemintegration In Ermangelung einer ausreichenden Erklärungsgrundlage, sind die Gestaltungsmaßnahmen der Systemintegration zwangsläufig unvollständig und unvollkommen. Sie sind aber erfahrungsgemäß brauchbar, um Integrationsdefizite zu vermeiden bzw. abzubauen. Dazu gehören: • • • •

das projektbegleitende, systematische Testen; das Prototyping; die Projektbibliothek; die Partnerschaft zwischen Systemplanern und Mitarbeitern der Fachabteilungen; • die Unterstützung der Zusammenarbeit durch Verwendung geeigneter Kommunikationstechniken. Das projektbegleitende, systematische Testen (vgl. Lerneinheit TESTM) dient nicht nur dem Nachweis, daß die Systementwürfe den definierten Anforderungen entsprechen, sondern kann auch dazu verwendet werden, die Systementwürfe untereinander und mit dem Bestand der Informationsinfrastruktur abzustimmen. Dabei steht das Überprüfen der richtigen Funktionsweise des Zusammenwirkens der Systementwürfe untereinander und mit dem Bestand der Informationsinfrastruktur im Vordergrund ("Integrationstest"). Vorgehensweisen,

WINTE - Integration der Systementwürfe

79

Methoden und Werkzeuge für den Integrationstest bei Systementwürfen stehen im Unterschied zum Integrationstest bei der Software-Entwicklung - nicht zur Verfügung. Es muß daher versucht werden, die für das Testen von SoftwareProdukten verfügbaren Vorgehensweisen, Methoden und Werkzeuge auf Systementwürfe als Testobjekte zu übertragen und in analoger Weise anzuwenden. Die Schwierigkeit des Integrationstests auf der Entwurfsebene besteht darin, daß es sich um logische Modelle handelt, die nicht implementiert sind. Mit Prototyping (vgl. Lerneinheit PROTY) wird unter dem Aspekt der Integration der Systementwürfe versucht, Integrationsbedarfe zwischen den logischen Modellen der Teilsysteme sowie zwischen den Teilsystemen und der Informationsinfrastruktur so früh wie möglich zu erkennen oder sogar zu vermeiden. Dies erfolgt durch ein kooperatives und koordiniertes Zusammenwirken von Systemplanern und Mitarbeitern der Fachabteilungen beim Systementwurf. Eine Projektbibliothek dient der Kommunikation zwischen allen am Projekt Beteiligten, insbesondere zwischen den Systemplanern, aber auch zwischen den Systemplanern und den Mitarbeitern der Fachabteilungen. Sie verwaltet sämtliche Zwischenprodukte und Produkte der Systemplanung, ist allen an der Systemplanung Beteiligten zugänglich und darüber hinaus ein Instrument für die Projektplanung, -Überwachung und -Steuerung (vgl. Lerneinheit PROMA im Band "Informationsmanagement" ). Mit Partnerschaft zwischen Systemplanern und Mitarbeitern der Fachabteilungen (häufig als "Zusammenarbeit zwischen Fachabteilung und EDV" bezeichnet) sind Maßnahmen gemeint, die darauf abzielen, Verständigungsschwierigkeiten zwischen den Mitarbeitern der Fachabteilungen und den Systemplanern zu vermeiden bzw. abzubauen. Hier spielen psycho-soziale Faktoren, die sich im Verhalten von Mitarbeitern der Fachabteilungen und Systemplanern äußern, eine entscheidende Rolle. Potentielle Integrationsdefizite sind vor allem auf die mangelnde Kommunikationsfähigkeit der Systemplaner zurückzuführen (vgl. dazu den Abschnitt "Forschungsbefunde"). Die Zusammenarbeit zwischen den Fachabteilungen und der IKS-Abteilung muß durch geeignete Kommunikationstechniken (auch im methodischen, nicht nur im technischen Sinn) wie Gesprächstechnik, Fragetechnik, Argumentationstechnik, Präsentationstechnik (vgl. Lerneinheit PRAET) und Kreativitätstechnik (vgl. Lerneinheit KREAT) unterstützt werden. Kommunikationsaufgaben zwischen den beteiligten Abteilungen setzen auf der Seite der Fachabteilungen Kenntnisse und Fähigkeiten voraus, über welche die Mitarbeiter nicht immer oder nicht ausreichend verfügen. Teilweise lassen sie sich durch Schulung vermitteln, teilweise ist dies jedoch nicht sinnvoll; in diesem Fall werden Koordinatoren eingesetzt (vgl. Lerneinheit AUTER). Forschungsbefunde Eine Untersuchung von Couger/Zawacki, bei der rd. 600 Systemplaner und Anwendungsprogrammierer und rd. 1000 Personen an anderen Arbeitsplätzen im Bereich der Datenverarbeitung befragt wurden, zeigte unter anderem folgendes:

80

Aufgaben der Grobprojektierung

Die Kontaktfreudigkeit von Fachleuten der Datenverarbeitung ist - verglichen mit anderen Berufen - relativ gering; der Anteil an "Einzelgängern" unter ihnen ist relativ hoch. Dies führt zu der Neigung, aus ihrer Arbeit eine "Geheimwissenschaft" zu machen; zur mangelnden Bereitschaft, das Gespräch mit den Mitarbeitern der Fachabteilungen zu suchen; zu unverständlichen Darstellungen und Präsentationen der Projektergebnisse; zur mangelnden Bereitschaft, die Mitarbeiter der Fachabteilungen in der Handhabung der Projektergebnisse zu schulen. Wie er sich selber sieht:

Anzahl Nennungen:

* analytisches und logisches Denkvermögen, systematisches und abstraktes Denken * sieht die Gesamtzusammenhänge, besserer Überblick, koordiniert * innovativ und kreativ * Vertreter der Geschäftsleitung, Wirtschaftlichkeit * kooperativ, geduldig, kontaktfreudig, motivierend * belastbar unter Zeitdruck, Erfolgszwang * geprügelt, Sündenbock, mißverstanden, unterbezahlt * Kenntnisse über die Fachabteilung * der Fachabteilung überlegen * Helfer der Fachabteilung * Kenner der Grenzen und Möglichkeiten der EDV * ständige Weiterbildung * Organisationstalent, Durchsetzungsvermögen * klare Formulierungen, eindeutige Sprache gesamt:

15 11 10 9 6 6 5 5 5 5 4 4 3 2 90

Abb. WINTE-2: Das Selbstbild des DV-Organisators (Quelle: Klein)

H. Klein hat bei 17 Arbeitstagungen von eintägiger Dauer mit rd. 300 Teilnehmern aus 150 Unternehmen zum Thema "Leistungsfördernde Zusammenarbeit zwischen Fachabteilung und EDV" das Selbstbild und das Fremdbild des DVOrganisators erhoben. Die Teilnehmer, die Mitarbeiter von Datenverarbeitungsabteilungen waren, erhielten die Aufgabe zu beschreiben, wie sich der DV-Organisator selbst sieht; die Mitarbeiter der Fachabteilungen beschrieben, wie sie den DV-Organisator sehen. Abbildung WINTE-2 zeigt, daß sich der DV-Organisator der Fachabteilung überlegen sieht; Abbildung WINTE-3 zeigt, daß die Mitarbeiter der Fachabteilungen ein völlig anderes Bild von ihm haben. Zusammenfassend zeigen die Ergebnisse weit verbreitete Einstellungen: Selbstüberschätzung der Fachleute der Datenverarbeitung; negative Erfahrungen der Mitarbeiter der Fachabteilungen mit diesen; Vorurteile der Mitarbeiter der Fachabteilungen gegenüber den Fachleuten der Datenverarbeitung. Diese Konfliktsituation führt zu Integrationsdefiziten zwischen den Entwurfsergebnissen und den personellen und organisatorischen Bedingungen in den Fachabteilungen; sie können nur durch Kooperation und Koordination überwunden werden.

WINTE - Integration der Systementwürfe

81

Wie ihn die Fachabteilung sieht: Anzahl Nennungen: * mangelnde Kooperationsbereitschaft, kann EDV nicht vermitteln, zu sachlicher Umgangston, mangelnde Koordinierungsfähigkeit 37 * überheblich, elitäres Denken, belehrend, Besserwisser 22 * Lösungen nicht fachabteilungsgerecht, sondern EDVorientiert, EDV als Selbstzweck und Spielzeug 19 * keine Kenntnisse über die Probleme der Fachabteilung 15 * versteckt sich hinter Fachausdrücken, EDV-Chinesisch, Geheimniskrämer 10 * realitätsfremd, Theoretiker, vereinfacht die Probleme 9 * beruft sich auf EDV-Zwänge 6 * doktrinär: "Das geht, das geht nicht" ohne Erklärung 6 * unflexibel bei der Lösung von Problemen 6 * zur genauen Ordnung zwingend, schafft Ordnung, Pedant 4 * weiterbildungshungrig, extreme Spezialausbildung 3 * Versprechungen positiver als Lösungen 2 gesamt: 139 Abb. WINTE-3: Das Fremdbild des DV-Organisators (Quelle: Klein)

Lindheim/Egle kommen auf Grund einer kleinen empirischen Untersuchung zur Kommunikation zwischen Management, "EDV" und Fachbereich (10 Unternehmen im Raum Graz, Interviewmethode, Gesprächspartner: EDV-Leiter) unter anderem zu der Behauptung, daß "entgegen mancher Meinungen in der Literatur" einige Unternehmen "berechtigterweise" auf einen "EDV-Ausschuß" (Lenkungsausschuß) verzichten können. Sie stellen andererseits fest, daß eine intensive Kommunikation über die Wirtschaftlichkeit "der EDV" zweifellos helfen könnte, "übereinstimmende Nutzeneinschätzungen des EDV-Einsatzes zu finden". Diese und andere Ergebnisse der Untersuchung zeigen erhebliche Integrationsdefizite zwischen Management, Fachabteilung und EDV-Abteilung. Den Ursachen der Integrationsdefizite wird nicht nachgegangen; zweckmäßige Integrationsmaßnahmen (z.B. der Lenkungsausschuß) können folglich nicht angegeben werden. Vessey/Sravanapudi haben vier CASE-Werkzeuge untersucht (Untersuchungszeitraum 1992) und kommen zu folgenden Ergebnissen bezüglich deren Eigenschaft, Gruppenarbeit zu unterstützen: Die Werkzeuge unterstützen nur wenige Funktionen, die typisch für Gruppenarbeit sind und die in Groupware-Produkten implementiert sind. Beispiele für Einzelbefunde sind: Am besten unterstützt wird die Kontrolle von Nebenläufigkeit; Zugriffskontrolle wird nicht gut unterstützt; die Aktivitäten der Werkzeugbenutzer werden nicht überwacht; das Verfolgen von Änderungen in der Datenbasis wird kaum unterstützt; Kommunikationsmöglichkeiten werden kaum zur Verfügung gestellt. Zusammenfassend wird festgestellt, daß die untersuchten CASE-Werkzeuge auf den einzelnen Werkzeugbenutzer zugeschnitten sind; sie sind keine Mehrbenutzer-Werkzeuge.

82

Aufgaben der Grobprojektierung

Methodenverweise Vorgehensweise bei der Grobprojektierung (Lerneinheit VGROB); Integrationsprinzipien (Lerneinheit PINTE); Präsentationstechnik (Lerneinheit PRAET); Kreativitätstechniken (Lerneinheit KREAT). Kontrollfragen 1. Welcher Zweck wird mit der Integration der Systementwürfe verfolgt? 2. Warum ist die arbeitsteilige Durchfuhrung eines IuK-Projekts notwendig und warum folgen daraus Potentiale für Integrationsdefizite? 3. Warum ist die Beseitigung der Potentiale für Integrationsdefizite kein technisches oder technisch-organisatorisches Problem? 4. Welche Gestaltungsmaßnahmen der Systemintegration stehen zur Verfugung? 5. Stützen einschlägige Forschungsbefunde die These von der psycho-sozialen Dimension der Systemintegration? Quellenliteratur Couger, J. D. und Zawacki, R. A.: Motivating and Managing Computer Personnel. J. Wiley & Sons, New York et al. 1980 Heilmann, H.: Integration - Ein zentraler Begriff der Wirtschaftsinformatik im Wandel der Zeit. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 150/1989,46 - 58 Klein, H.: Partnerschaft zwischen Fachabteilung und EDV. In: Heilmann, H. (Hrsg.): Zusammenarbeit zwischen Fachabteilung und EDV. Forkel Verlag, Stuttgart/Wiesbaden 1980, 15-63 Lindheim, W. und Egle, W.: Schlüsselfaktoren für eine erfolgreiche Kommunikation zwischen Management, EDV, Fachbereich. In: EERWIRTSCHAFrSINGENlEUR 3/1987, 34 - 38 Schweitzer, M.: Arbeitsteilung. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980, 139 - 144 Vessey, I. and Sravanapudi, A. P.: Evaluation of Vendor Products: CASE-Tools as Collaborative Support Technologies. Unpublished Paper, Penn. State University 1992

BTECH - Bestimmen des Technikbedarfs Lernziele Sie kennen die Dimension des Technikbedarfs, seinen Informationswert sowie die Informationsquellen, die zum Bestimmen des Technikbedarfs zur Verfügung stehen. Sie wissen, warum zwischen Bruttobedarf und Nettobedarf unterschieden wird. Sie können den Prozeß des Bestimmens des Technikbedarfs mit einer Folge von Arbeitsschritten beschreiben. Definitionen und Abkürzungen Anbieter (supplier) = ein Unternehmen, das bereit und in der Lage ist, vom Anwender nachgefragte Techniksysteme zu liefern. Argumentebilanz (arguments balance sheet) = eine Methode zur systematischen Darstellung der zumeist verbal formulierten Argumente, die für ("ProArgumente") und die gegen ("Kontra-Argumente") eine untersuchte Alternative sprechen. Aufgabenfunktion (task function) = ein Element der Aufgabe, das sich aus ihrer Strukturierung in Anlehnung an den Ablauf des Informations- und Kommunikationsprozesses ergibt (z.B. Dateneingabe, Datenspeicherung). Bewertungskriterium (evaluation criterion) = ein Ziel, das Endpunkt einer Zielkette der Zielhierarchie in einem Zielsystem ist und zur Prognose der Konsequenzen einer Handlungsalternative dient. Synonym: Zielkriterium. Entwicklungsrückstau (development backlog) = die nicht abgearbeiteten Systemplanungsaufgaben, deren Erledigung auf Grund der Bedarfe der Anwender erforderlich ist. Synonym: Anwendungsrückstau. Funktion (function) = eine Komponente eines Systems (z.B. eines Anwendungssoftware-Systems), die eine bestimmte Anwendungsaufgabe oder einen Teil einer Anwendungsaufgabe realisiert (z.B. die "Aufrollung" in einem Lohnabrechnungssystem). Funktionsmerkmal (function attribute) = eine qualitative Aussage über eine bestimmte Fähigkeit eines Techniksystems. Individualsoftware (user-customized software) = eine Anwendungssoftware, die auf der Grundlage der Anforderungen eines Anwenders von diesem selbst oder für ihn (z.B. durch ein Software-Haus) entwickelt wurde. Informationswert (information value) = der Nutzen, den ein Entscheidungsträger einer Information zumißt. Konfiguration (configuration) = eine geordnete Menge von Techniksystemen oder ihrer Komponenten zur Deckung eines definierten Technikbedarfs. Leistungsmerkmal (performance attribute) = eine quantitative Aussage über eine bestimmte Fähigkeit eines Techniksyátems. Standardsoftware (software package) = eine Anwendungssoftware, die für den anonymen Markt entwickelt wurde und bei deren Entwicklung die Anforderungen einer größeren Anzahl von Anwendern berücksichtigt wurden. Verträglichkeit (compatibility) = die Eigenschaft eines Systems, ohne besondere Anpassungsmaßnahmen mit einem anderen System zusammenarbeiten zu können. Synonym: Kompatibilität.

84

Aufgaben der Grobprojektierung

Dimensionen des Technikbedarfs Das Bestimmen des Technikbedarfs ist die vorausschauende Ermittlung der Art und der Menge der Techniksysteme (Hardware und Software) sowie des Zeitpunkts ihrer Bereitstellung für das zu schaffende Informationssystem. Es sind also folgende Dimensionen des Technikbedarfs zu unterscheiden: • der qualitative Bedarf, der durch die Eigenschaften (Funktions- und Leistungsmerkmale) der erforderlichen Hardware und Software gegeben ist; • der quantitative Bedarf, also die Anzahl der Techniksysteme bzw. der Komponenten von Techniksystemen; • der zeitliche Bedarf, also der Zeitpunkt oder die Zeitpunkte zu dem bzw. zu denen die nach Quantität und Qualität definierten Techniksysteme zur Verfügung stehen sollen. Aufgabenträger beim Bestimmen des Technikbedarfs Die Notwendigkeit, den Technikbedarf durch den Anwender zu bestimmen, wird in der Praxis häufig nicht akzeptiert. Vielmehr wird es dem Anbieter der Techniksysteme überlassen, den Technikbedarf auf Grund der im Pflichtenheft dokumentierten Systementwürfe zu bestimmen. Diesem Vorgehen soll nicht gefolgt werden; es soll der Systemplaner des Anwenders die Anforderungen der Systementwürfe an die Techniksysteme in den Technikbedarf umsetzen und die Ergebnisse in die Ausschreibung aufnehmen (vgl. Lerneinheit TECHM im Band "Informationsmanagement"). Der Vorteil dieser Vorgehensweise besteht darin, daß damit eine vollständige Umsetzung der Anforderungen der Systementwürfe in den Technikbedarf gewährleistet ist und darüber hinaus in der Ausschreibung gezielt die Funktions- und Leistungsmerkmale der anzubietenden Techniksysteme abgefragt werden können. Diese Vorgehensweise stellt sicher, daß jedes für die Bewertung der Technikangebote vorgesehene Bewertungskriterium (vgl. Lerneinheit BEWER im Band "Informationsmanagement") in der Ausschreibung berücksichtigt und daß der Zielertrag dazu erhoben wird. Das schließt nicht aus, daß der Anbieter auf Grund seiner spezifischen Sachkenntnis über die angebotenen Techniksysteme alternative Konfigurationen zur Deckung des Technikbedarfs, insbesondere in qualitativer Hinsicht, entwickelt und anbietet. Ein kooperatives Vorgehen, bei dem Anwender und Anbieter beim Bestimmen des Technikbedarfs zusammenarbeiten, kann zweckmäßig sein. Informationen zum Bestimmen des Technikbedarfs Beim Entwerfen der Teilsysteme wurde vom Ergebnis der Feinstudie (vgl. Lerneinheit AFEIN), also von der angepaßten Grundkonzeption, ausgegangen. Die Entwurfsergebnisse der Grobprojektierung stellen im Sinn eines phasenweise präzisierenden Vorgehens eine Detaillierung der Entwurfsergebnisse der Grundkonzeption dar. Die für das Bestimmen des Technikbedarfs erforderlichen Informationen sind in erster Linie diesen Entwürfen zu entnehmen. Darüber hinaus ist die Grundkonzeption eine unmittelbare Informationsquelle, weil sie Entwurfsergebnisse enthält, die Restriktionen für die Entwürfe der Teilsysteme darstellen und nicht präzisiert werden müssen. Dies zeigt schematisch Abbildung BTECH-1.

BTECH - Bestimmen des Technikbedarfs

85

% Angepaßte « w. Grundkonzeption % Entwerfen Datensystem, Methodensystem, Arbeitsorganisation, Transportsystem, Sicherungssystem Systementwürfe

Bestimmen des Technikbedarfs

Pflichtenheft

Abb. BTECH-1: Informationen zum Bestimmen des Technikbedarfs

Bruttobedarf und Nettobedarf Aus den Anforderungen der Systementwürfe der Teilsysteme und aus der Grundkonzeption wird zunächst der Technikbedarf als Bruttobedarf ermittelt. Der Bruttobedarf wird um die Techniksysteme oder Komponenten von Techniksystemen, die beim Anwender verfügbar sind oder verfügbar gemacht werden sollen ("Technikbestand"), reduziert. Ein so verstandener Technikbestand kann Hardware oder Software oder beides umfassen. • Hardware-Bestand sind die vorhandenen Benutzerendgeräte (etwa Bildschirmgeräte, Arbeitsplatzdrucker), Speichersysteme oder kompletten Computersysteme; • Systemsoftware-Bestand sind die vorhandenen Systemprogramme (z.B. Betriebssysteme); • Anwendungssoftware-Bestand sind die Anwendungsprogramme, die entweder bereits verfügbar sind oder mit dem vorhandenen, eigenen Entwicklungspotential selbst entwickelt werden sollen. Beim Bestimmen des Technikbestands handelt es sich um Entscheidungen, die sich an folgenden Kriterien orientieren müssen: • an der Verträglichkeit der vorhandenen Techniksysteme mit den Techniksystemen des ermittelten Bruttobedarfs; • an der Wirtschaftlichkeit der vorhandenen Techniksysteme sowie an der Beeinflussung der Wirtschaftlichkeit des neuen Gesamtkonzepts durch den Technikbestand. Daher ist eine gründliche Analyse der vorhandenen Techniksysteme unter technischen und betriebswirtschaftlichen Kriterien erforderlich. Häufig erweist sich eine nach technischen Kriterien realisierbare Verwendung vorhandener Technik-

86

Aufgaben der Grobprojektierung

systeme unter betriebswirtschaftlichen Kriterien als unzweckmäßig, insbesondere bezüglich der Anwendungssoftware (z.B. wegen mangelnder Wartbarkeit oder wegen eines schlechten Laufzeitverhaltens). Arbeitsschritte zum Bestimmen des Technikbedarfs Die bisherigen Überlegungen werden dazu verwendet, eine aus vier Arbeitsschritten bestehende Vorgehensweise zum Bestimmen des Technikbedarfs zu entwickeln. Sie beginnt mit dem Bestimmen des qualitativen Technikbedarfs, setzt mit dem Bestimmen des quantitativen Technikbedarfs fort, an das sich das Bestimmen des Nettobedarfs anschließt; von diesem ausgehend wird die Deckung des Technikbedarfs eingeleitet. Funktions- und Leistungsmerkmale/^

I ,00

1

Aufgaben

Abb. BTECH-2: Beschreibungsschema d e n qualitativen Technikbedarf

fflr

• Erster Arbeitsschritt: Bestimmen des qualitativen Technikbedarfs. Aus den in den Systementwürfen dokumentierten Anforderungen der Aufgaben und der Aufgabenträger werden die erforderlichen Funktions- und Leistungsmerkmale der Techniksysteme abgeleitet. Dafür ist eine Gliederung nach Aufgabenfunktionen zweckmäßig, sodaß sich ein dreidimensionales Beschreibungsschema für den qualitativen Technikbedarf ergibt (vgl. Abbildung BTECH-2). Als Orientierungshilfe und zur Überprüfung der Zweckmäßigkeit der Anforderungen bzw. der Notwendigkeit der Funktions- und Leistungsmerkmale sollen Forschungsbefunde über die Beziehungen zwischen Aufgaben, Aufgabenfunktionen und Funktions- und Leistungsmerkmalen verwendet werden (siehe Abschnitt Forschungsbefunde, in dem auch eine weitere Erklärung der Abbildung BTECH-2 gegeben wird). • Zweiter Arbeitsschritt: Bestimmen des quantitativen Technikbedarfs. Die Ergebnisse des ersten Arbeitsschritts werden aus der Sicht der Aufgabenfunktion betrachtet, und es wird der quantitative Technikbedarf für jede Aufgabenfunktion (d.h. für die Dateneingabe, die Datenspeicherung usw.) bestimmt. Das Umsetzen der qualitativen Bedarfe in quantitative Bedarfe erfolgt unter Verwendung aller Angaben der Systementwürfe. Ergebnis des zweiten Arbeitsschritts ist der Bruttobedarf. • Dritter Arbeitsschritt: Bestimmen des Nettobedarfs. Der vorhandene Bestand an Techniksystemen wird zunächst unter Verwendung des Beschreibungsschemas für den qualitativen Technikbedarf daraufhin überprüft, ob er über die Funktions- und Leistungsmerkmale verfügt, die nach den Anforderungen der Aufgaben und der Aufgabenträger erforderlich sind. Das Ergebnis dieser

BTECH - Bestimmen des Technikbedarfs

87

Zulässigkeitsprüfung wird anschließend der erwähnten technischen und betriebswirtschaftlichen Analyse unterzogen. Die Frage "Eigenfertigung oder Fremdbezug von Anwendungssoftware" wird in die Überprüfung und Analyse einbezogen (vgl. dazu das Demonstrationsbeispiel). Ergebnis des dritten Arbeitsschritts ist der Nettobedarf, also der um den technisch und betriebswirtschaftlich verwertbaren Technikbestand reduzierte Bruttobedarf. • Vierter Arbeitsschritt: Decken des Technikbedarfs. Der Nettobedarf wird in eine ausschreibungsgerechte Form umgesetzt (vgl. dazu das Ergebnis in Lerneinheit PFLIC und Lerneinheit TECHM im Band "Informationsmanagement"); dabei werden auch die Bereitstellungszeitpunkte festgelegt. Demonstrationsbeispiel Beim Bestimmen des Nettobedarfs geht es unter anderem um die Frage, ob Anwendungssoftware mit eigenem Personal selbst entwickelt oder fremd bezogen werden soll. Fällt die Entscheidung zugunsten der Eigenentwicklung, dann ist dieser Teil des Technikbedarfs nicht Gegenstand der Ausschreibung. Für dieses Entscheidungsproblem ist der Terminus Eigenerstellung oder Fremdbezug geläufig. Der Begriff stellt die Analogie mit Entscheidungsproblemen in der Fertigungswirtschaft her; die dort übliche Vorgehensweise zur Problemlösung ist auch im vorliegenden Fall anwendbar.

Abb. BTECH-3: Entscheidungsprozeß "Eigenentwicklung oder Fremdbezug von Anwendungssoftware"

Zunächst wird die Entscheidungssituation bezüglich der Handlungsalternativen wie folgt präzisiert: Entweder ist Anwendungssoftware Individualsoftware, oder sie ist Standardsoftware; im Fall von Individualsoftware ist sie entweder Eigenentwicklung oder sie ist Fremdentwicklung. Auf Grund dieser Struktur der Handlungsalternativen ergibt sich der nachfolgend dargestellte Entscheidungsprozeß (vgl. Abbildung BTECH-3). Die mit den beiden Rauten symbo-

88

Aufgaben der Grobprojektierung

lisierten Entscheidungen können methodisch in verschiedener Weise unterstützt werden. Beispiele für Unterstützungsmethoden sind Nutzwertanalyse (vgl. Lerneinheit NUTZW), Normstrategien (vgl. Lerneinheit STRAT im Band "Informationsmanagement") und Argumentebilanz. Entscheidung zwischen Individualsoftware und Standardsoftware. Dabei handelt es sich um die Grundsatzentscheidung, ob Individualsoftware oder ob Standardsoftware vorzuziehen ist, unabhängig davon, welche StandardsoftwareProdukte zur Verfügung stehen. Die Entscheidung orientiert sich an Bewertungskriterien, die aus der Informatik-Strategie (vgl. Lerneinheit STRAT im Band "Informationsmanagement") abgeleitet werden (z.B. die strategische Aussage, Eigenentwicklung, wenn irgend möglich, zu vermeiden oder aber Eigenentwicklung immer dann vorzuziehen, wenn es sich um die Unterstützung von Geschäftsprozessen mit hoher Unternehmensspezifität und hoher strategischer Bedeutung handelt), an administrativen Zielen (z.B. Kostenziele) und an operativen Zielen (z.B. Produktivitätsziele). Dabei können Informationen über generelle Vorteile und Nachteile von Standardsoftware (respektive Nachteile und Vorteile von Individualsoftware) nützlich sein, wie zum Beispiel: • Die Beschaffungszeit und die Installierungszeit sind bei Standardsoftware kürzer als bei Individualsoftware. • Die Kosten für Standardsoftware sind geringer als die Kosten für Individualsoftware; sie lassen sich zudem zuverlässiger prognostizieren. • Die Funktions- und Leistungsmerkmale von Standardsoftware stimmen mit den Anforderungen nicht voll überein, sodaß entweder die Anforderungen angepaßt werden müssen oder die Software angepaßt werden muß (was letztlich zum Verlust der Vorteile von Standardsoftware führen kann). In der einschlägigen Fachliteratur findet sich dazu reichhaltiges Material (vgl. die angegebene Vertiefungsliteratur). Entscheidung zwischen alternativen Standardsoftware-Produkten. Falls die erste Entscheidung zugunsten von Standardsoftware fällt, geht der Technikbedarf in die Ausschreibung ein. Bei der Angebotsanalyse werden dann die alternativen Angebote bewertet (vgl. Lerneinheiten TECHM und BEWER im Band "Informationsmanagement"). Entscheidung zwischen Eigenentwicklung und Fremdentwicklung. Fällt die erste Entscheidung zugunsten von Individualsoftware, dann ist darüber zu entscheiden, ob sie mit eigenem Personal entwickelt oder im Auftrag fremd entwickelt werden soll. Analog zur ersten Entscheidung kann hier zunächst ohne die Kenntnis konkreter Handlungsalternativen vorgegangen werden, indem die Vorteilhaftigkeit der Eigenentwicklung oder der Fremdentwicklung in der vorliegenden Entscheidungssituation überprüft wird. Dabei können Informationen über generelle Vorteile und Nachteile der Eigenentwicklung (respektive Nachteile und Vorteile der Fremdentwicklung) herangezogen werden, wie zum Beispiel: • Es besteht ein Entwicklungsrückstau, sodaß eigenes Personal nicht ausreichend zur Verfügung steht. • Die Qualifikation des eigenen Personals wird geringer eingeschätzt als die

BTECH - Bestimmen des Technikbedarfs

89

des Personals eines Software-Hauses oder System-Hauses. • Geplante Entwicklungskosten und Entwicklungszeiten werden bei Eigenentwicklung oft nicht eingehalten, ohne daß dies zu Konsequenzen führt; mit Fremdentwicklern können Vertragsstrafen vereinbart werden. • Bei Fremdentwicklung besteht die Gefahr, daß Mitbewerber mit Hilfe des gleichen Software-Hauses oder System-Hauses erreichte Wettbewerbsvorteile schnell kompensieren können, sodaß ein ausschließliches Nutzungsrecht (mit entsprechend hohen Kosten) vereinbart werden muß.

Sachbearbeitung

Zugriffssicherung

Speicherinhaltsverzeichnis

Speicherung unterschiedlicher Informationsarten

Zugriff auf externe Datenbanken

Aufbau persönlicher Daten

Zugriff auf betriebliche Datenbanken

Leistungsmerkmale

Entscheidung zwischen alternativen Angeboten von Fremdentwicklern. Falls die dritte Entscheidung zugunsten der Fremdentwicklung fällt, geht der Technikbedarf in die Ausschreibung ein. Bei der Angebotsanalyse wird wie bei der zweiten Entscheidung vorgegangen.

• 4• Él r~ r • • 1. ' i

Spezialbzw. Fachaufgaben Unterstützungsaufgaben

•

Führungsaufgaben •

notwendig

m

B

hilfreich

m

u

u

G überflüssig

.......

• y

Abb. BTECH-4: Qualitativer Technikbedarf "Datenspeicherung" (Quelle: Picot/Reichwald)

Forschungsbefunde Picot/Reichwald haben für Systeme der Kommunikationstechnik eine auf die Aufgaben bzw. auf die Aufgabenträger bezogene Gewichtung von Funktions- und Leistungsmerkmalen, nach Aufgabenfunktionen gegliedert, durchgeführt. Sie haben sich bei ihren Befunden auf Expertenbefragungen gestützt. Für die folgenden vier Aufgabenfunktionen wird der qualitative Technikbedarf angegeben (Abbildungen 98 bis 100 der genannten Quelle):

90

• • • •

Aufgaben der Grobprojektierung

formale Erstellung von Informationen; Dokumentation und Informationsverwaltung; inhaltliche Bearbeitung von Informationen; Übertragung von Informationen.

Abbildung BTECH-4 zeigt die Dokumentation und Informationsverwaltung ("Datenspeicherung") als Beispiel. Wird der qualitative Technikbedarf aus der Sicht der Aufgaben betrachtet, dann lassen sich Konfigurationen für Aufgaben typen ableiten (Abbildungen 101 bis 104 der genannten Quelle). Abbildung BTECH-5 zeigt die Konfiguration für den Aufgabentyp Führungsaufgaben.

r

^Erstellung

Dokumentation Zugriff auf betriebliche Datenbanken Aufbau persönlicher Dateien

Bearbeitung

Übertragung^ Elektronischer Papierkorb Simultane technische Kommunikation Übertragung aller Informationsarten Zugang zu allen öffentlichen Diensten

Speicherinhaltsverzeichnis

Planungs- und Telekonferenz Kontrollfunktionen

Menü- und_ ZugriffsWindowsicherung technik

Abb. BTECH-5: Arbeitsplatzkonfiguration "Führungsaufgaben" (Quelle: Picot/Reichwald)

Methodenverweise Vorgehensweise bei der Grobprojektierung (Lerneinheit VGROB); Nutzwertanalyse (Lerneinheit NUTZW); Bewertungsmethoden (Lerneinheit BEWER im Band "Informationsmanagement").

Kontrollfragen 1. 2. 3. 4. 5.

Welches sind die drei Dimensionen des Technikbedarfs? Welche Informationsquellen werden für das Bestimmen des Technikbedarfs verwendet? Was wird unter Bruttobedarf und was unter Nettobedarf verstanden? Mit welchen Arbeitsschritten kann beim Bestimmen des Technikbedarfs vorgegangen werden? Mit welchen Methoden kann die Entscheidung "Eigenfertigung oder Fremdbezug" unterstützt werden?

BTECH - Bestimmen des Technikbedarfs

91

Quellenliteratur Frank, J.: Standard-Software - Kriterien und Methoden zur Beurteilung und Auswahl von Software-Produkten. 2. A., Verlagsgesellschaft Müller, Köln 1980 Knolmayer, G.: Die Auslagerung von Servicefunktionen als Strategie des IS-Managements. In: Heinrich, L. J. et al. (Hrsg.): Die Informationswirtschaft im Unternehmen. Universitätsverlag Trauner, Linz 1991, 323 - 341 Picot, A. und Reichwald, R. (Hrsg.): Kommunikationstechnik für Anwender. Forschungsprojekt Bürokommunikation Bd. 1. CW-Publikationen Verlagsgesellschaft, München 1983 Vertiefungsliteratur Ambichl, E. und Heinrich, L. J.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architekturen. In: Information Management 3/1992,24-31 Buhl, U. und Wirth, A.: Outsourcing von Informationsverarbeitungsleistungen unter Risikoaspekten. In: Frisch, W. und Taudes, A. (Hrsg.): Informationswirtschaft. Aktuelle Entwicklungen und Perspektiven. Physica-Verlag, Heidelberg 1993, 207 - 230 Picot, A. und Maier, M.: Analyse- und Gestaltungskonzepte für das Outsorcing. In: Information Management 4/1992, 14 - 27

PFLIC - Erstellen des Pflichtenhefts Lernziele Sie kennen den Zweck des Pflichtenhefts in der Systemplanung. Sie können das Pflichtenheft nach inhaltlichen Gesichtspunkten gliedern und die Inhalte angeben. Sie können begründen, warum diese Inhalte des Pflichtenhefts erforderlich sind. Sie verstehen die Notwendigkeit der Erarbeitung des Kriterienkatalogs im Zusammenhang mit dem Erstellen des Pflichtenhefts und den Zusammenhang dieser Dokumente mit der Ausschreibung. Sie erkennen den Einfluß des Protyping auf die Bedeutung des Pflichtenhefts. Definitionen und Abkürzungen Anforderung (requirement) = eine Aussage über die von einem System gewünschten Funktionen und Leistungen bezüglich quantitativer oder qualitativer Eigenschaften. Anforderungsprofil (requirements profile) = eine Zusammenstellung der aus den Zielen, Lösungsansätzen und Lösungsideen abgeleiteten Anforderungen an ein Informationssystem. Angebotsanalyse (bid analysis) = die Analyse und Bewertung der auf Grund einer Ausschreibung vorliegenden Angebote. Ausschreibung (tendering) = der Vorgang zur Einholung von Angeboten für Hardware, Software und Dienstleistungen. K.o.-Kriterium (kill criterion) = ein Kriterium, das eine als unabdingbar angesehene Anforderung mit einem limitierten Zielertrag beschreibt und zur Eliminierung der Alternativen im Bewertungsprozeß führt, welche diesen Zielertrag nicht erreichen. Synonym: Muß-Kriterium. Konflikt (conflict) = eine durch Interessensgegensätze gekennzeichnete Beziehung zwischen Individuen oder Gruppen. Kriterienkatalog (criteria list) = die systematische Zusammenstellung aller Auswahlkriterien zur Lösung eines Auswahlproblems. Mengengerüst (quantity requirements) = die Art, Anzahl und Verarbeitungshäufigkeit von Daten, die in ein System eingegeben und von diesem verarbeitet, verwaltet (gespeichert) und ausgegeben werden. Pflichtenheft (requirements definition) = ein Dokument, das die Projektziele nennt, die zu unterstützenden Aufgaben und die Systementwürfe beschreibt sowie den daraus abgeleiteten Technikbedarf angibt. Projektziel (project goal) = ein Ziel, das zur Planung, Überwachung und Steuerung eines Projekts der Systemplanung verwendet und aus den Planungszielen abgeleitet wird. Prototyping (prototyping) = ein methodischer Ansatz der Systemplanung mit ausgeprägter Benutzerbeteiligung unter Verwendung spezieller Werkzeuge. Stand der Technik (state of the art) = das allgemein anerkannte und im Normalfall erreichbare Niveau einer technisch orientierten Problemlösung. SVD = Akronym für Schweizerische Vereinigung für Datenverarbeitung. Zielertrag (goal achievement) = die Konsequenz einer Alternative bezüglich eines Zielkriteriums.

PFLIC - Erstellen des Pflichtenhefts

93

Zweck des Pflichtenhefts Die vierte Aufgabe der Grobprojektierung, die Systemauswahl (vgl. Lerneinheit ZAMGP), wird wegen ihrer Komplexität in mehrere Teilaufgaben gegliedert, und zwar: • • • • •

das das das das das

Erstellen des Pflichtenhefts; Entwickeln des Kriterienkatalogs; Durchführen der Ausschreibung; Analysieren und Bewerten der Angebote; Abschließen von Verträgen mit Lieferanten.

In dieser Lerneinheit werden die ersten beiden Teilaufgaben behandelt. (Die dritte bis fünfte Teilaufgabe werden im Band "Informationsmanagement" in den Lerneinheiten TECHM, BEWER bzw. BENCH und RECHT behandelt, weil sie nicht projektspezifisch sind.) Die Ergebnisse der Systemgliederung (vgl. Lerneinheit VGROB), zum Systementwurf (vgl. Lerneinheiten WDASY, WMESY, WAORG, WTRAN und WSICH) und zur Systemtechnologie (vgl. Lerneinheit BTECH) werden im Pflichtenheft dokumentiert. Das Pflichtenheft ist die Basis für das Entwickeln des Kriterienkatalogs, für die Gliederung der Angebote und den Angebotsvergleich, für die Vertragsverhandlungen, für das Abschließen von Verträgen sowie für die Zusammenarbeit zwischen Anwender und Lieferanten. Das Pflichtenheft dient auch dem Zweck, Konflikte zwischen dem Anwender und den Lieferanten rechtzeitig zu erkennen und, wenn möglich, zu verhindern. Ursachen für Konflikte sind zum Beispiel: • Der Anwender lernt während des Projekts. Er will deshalb definierte Anforderungen ändern und erweitern. Er versucht zum Beispiel, andere Arbeitsabläufe durchzusetzen oder andere Software- und/oder HardwareSchnittstellen vorzugeben. • Der Lieferant lernt während des Projekts. Er sieht erst beim Verwirklichen der Anforderungen den vollen Umfang der Schwierigkeiten sowie den mit ihrer Bearbeitung verbundenen Aufwand und die daraus folgenden Kosten. Manchmal wird zwischen Grob-Pflichtenheft und Detail-Pflichtenheft unterschieden. Das Grob-Pflichtenheft ist Grundlage für die Ausschreibung und die nachfolgenden Aufgaben der Bewertung und für das Abschließen von Verträgen. Das Detail-Pflichtenheft ist Grundlage für die Systementwicklung. Da der zweite Zweck durch Fortschreibung des zunächst dem ersten Zweck dienenden Pflichtenhefts erreicht wird, ist die Unterscheidung ohne praktische Bedeutung. Struktur und Inhalt des Pflichtenhefts Das Pflichtenheft beinhaltet eine vollständige, detaillierte Beschreibung aller geforderten Funktionen ("Funktionsmerkmale") und Leistungen ("Leistungsmerkmale") eines zu beschaffenden oder zu entwickelnden Hardware- und/oder Software-Systems und ist damit sowohl für den Anwender als auch für den An-

94

Aufgaben der Grobprojektierung

bieter von grundlegender Bedeutung. Folgende Struktur des Pflichtenhefts hat sich als zweckmäßig erwiesen: • • • • •

Vorstellung des Unternehmens des Ausschreibers; Darstellung der Ziele des Projekts; Beschreibung der zu unterstützenden Aufgaben; Beschreibung der Systementwürfe; Darstellung des Technikbedarfs.

Je nach Ausgangssituation (Erstbeschaffung oder Ablösung eines Systems, einzelner Komponenten oder einzelner Anwendungssoftware-Pakete) sind die Teile des Pflichtenhefts mehr oder weniger detailliert. Dabei ist auf das Verhältnis zwischen dem Aufwand des Ausschreibers für das Erstellen des Pflichtenhefts und dem Aufwand der Anbieter für die Bearbeitung des Pflichtenhefts einerseits sowie der Bedeutung der geplanten Investition andererseits zu achten (Größe und Komplexität des Projekts zu Umfang des Pflichtenhefts). Im folgenden werden die wesentlichen Inhalte des Pflichtenhefts erläutert und soweit erforderlich - die Aufgaben der Systemplanung angegeben, mit denen diese Inhalte erarbeitet wurden. Dabei wird insbesondere darauf eingegangen, warum diese Inhalte erforderlich sind. Vorstellung des Unternehmens des Ausschreibers In einer Kurzbeschreibung wird dem Anbieter das Unternehmen des Ausschreibers mit Namen, Unternehmensart (Branche) und Unternehmenszweck vorgestellt. Der Anbieter soll sich damit ein erstes "Bild über den Ausschreiber" machen und beurteilen können, ob eine Beteiligung an der Ausschreibung möglich und sinnvoll ist. Die Kurzbeschreibung enthält Informationen über: • die Art und die Größe des Unternehmens (z.B. Märkte, Erzeugnisse, Umsätze, Anzahl der Beschäftigten, getrennt nach Produktion und Verwaltung); • die Struktur des Unternehmens (z.B. Rechtsform, Tochtergesellschaften, Zweigniederlassungen); • die Verbindungen zu Lieferanten und Kunden (z.B. Einkaufs- und Vertriebsorganisation) und anderen externen Partnern (z.B. Banken); • die Ausstattung zur Erbringung der Leistungen im Unternehmen (z.B. Betriebsmittel, Fertigungstiefe, Fremdleistungen); • die interne Organisation des Unternehmens (z.B. die Abteilungsgliederung und die Ablauforganisation der wichtigsten Geschäftsprozesse); • die Durchdringung des Unternehmens mit IuK-Technologie (z.B. die zur Unterstützung der Kern-Geschäftsprozesse vorhandenen Informationssysteme). Sind branchen- und unternehmensbezogene Besonderheiten vorhanden und für die Ausschreibung von Bedeutung (z.B. kritische Wettbewerbsfaktoren, Marktstellung, Haupt-Mitbewerber, Exportanteil, strategisch bedeutsame Informationssysteme), soll darauf näher eingegangen werden.

PFUC - Erstellen des Pflichtenhefts

95

Ziele des Projekts Dem Anbieter werden die Sachziele und die Formalziele des Projekts, für das eine Ausschreibung durchgeführt wird, erläutert. Sachziele beschreiben den Zweck des IuK-Projekts, das zu dieser Ausschreibung geführt hat. In Form von Anforderungen werden Aussagen darüber gemacht, welche betrieblichen Aufgaben durch das zu schaffende Informationssystem unterstützt werden sollen, mit anderen Worten: welche Funktionsanforderungen definiert wurden. Mit den Sachzielen werden auch Angaben über die Leistungsanforderungen und über die Schnittstellenanforderungen gemacht (vgl. Lerneinheit SACHZ). Formalziele beschreiben die Qualität oder die Güte, mit der die Sachziele erreicht werden sollen. Durch die Definition von spezifischen Formalzielen (mit Zielinhalt, Ausmaß der Zielerreichung und zeitlichem Bezug) erhält der Anbieter wichtige Hinweise auf die geforderte Produkt- und Prozeßqualität (vgl. Lerneinheit FORMZ). Die Analyse und Bewertung der Angebote wird durch die Definition der Formalziele wesentlich erleichtert (vgl. Lerneinheit TECHM im Band "Informationsmanagement"). Beschreibung der zu unterstützenden Aufgaben Die Sachziele benennen die betrieblichen Aufgaben, die unterstützt werden sollen, geben aber keine Beschreibung im einzelnen. Die betrieblichen Aufgaben wurden als Grundkonzeption in der Vorstudie entworfen (vgl. Lerneinheit GRUND). Die Grundkonzeption beschreibt als optimales Systemkonzept möglichst vollständig das zu schaffende Informationssystem anhand seiner wichtigsten Merkmale auf einer abstrakten Ebene. Darüber hinaus sollen dem Anbieter Hinweise auf die mögliche bzw. notwendige Integration mit anderen betrieblichen Aufgaben und auf die Abstimmung mit vorhandenen oder anzuschaffenden Sachmitteln (Technikbedarf) gegeben werden. Die Wege zur Realisierung sollen aber bewußt offen gehalten werden, unter anderem deshalb, um den Anbieter in seinen Vorschlägen nicht "einzuengen". Es kann sinnvoll sein, dem Anbieter die alternativen Systemkonzepte vorzustellen und die Gründe zu erläutern, die aus der Sicht des Ausschreibers - zur Grundkonzeption geführt haben. Die Frage, wie detailliert die Aufgaben beschrieben werden sollen, ist nur situationsabhängig zu beantworten. So wird für sogenannte "Standardaufgaben" (z.B. Finanzbuchhaltung, Lohn- und Gehaltsabrechnung) die Beschreibung weniger ins Detail gehen müssen, als für Aufgaben, die individuelle oder sogar innovative Konzepte erfordern (z.B. Aufgaben im Fertigungsbereich). Beschreibung der Systementwürfe Ausgehend von der Grundkonzeption, ist es für den Anbieter erforderlich, die Systementwürfe des Ausschreibers zu kennen. Die Systementwürfe sind die Arbeitsergebnisse der Teilprojekte der Grobprojektierung; sie beschreiben das Datensystem (vgl. Lerneinheit WDASY), das Methodensystem (vgl. Lerneinheit WMESY), die Arbeitsorganisation (vgl. Lerneinheit WAORG), das Transportsystem (vgl. Lerneinheit WTRAN) und das Sicherungssystem (vgl. Lerneinheit WSICH).

96

Aufgaben der Grobprojektierung

Die Systementwürfe sollen untereinander und mit der Informationsinfrastruktur so abgestimmt sein, daß das logische Modell des Informationssystems insgesamt erkennbar ist (vgl. Lerneinheit WINTE). Von Vorteil ist es, die Integrationsanforderungen und die zu ihrer Abdeckung benötigten Schnittstellen zu beschreiben, weil der Anbieter damit konkrete Vorstellungen über den geforderten Grad der Integration vermittelt bekommt. Darauf aufbauend sollte der Anbieter in der Lage sein, ein Angebot zur physischen Realisierung der Systementwürfe zu erstellen. Darstellung des Technikbedarfs Unter Technikbedarf werden die vorausschauende Feststellung der Art und der Menge der Techniksysteme (Hardware und Software) sowie die Zeitpunkte ihrer Bereitstellung verstanden (vgl. Lerneinheit BTECH). Für den Anbieter interessant ist nicht nur der Technikbedarf für das zu schaffende Informationssystem, sondern auch der beim Ausschreiber bereits vorhandene Technikbestand (Hardware, Systemsoftware und Anwendungssoftware). Die Kenntnis des Technikbestands ermöglicht es dem Anbieter, Angaben zur Verträglichkeit der angebotenen Techniksysteme mit den vorhandenen Techniksystemen zu machen. Damit können auch Fragen der Wirtschaftlichkeit bzw. der Beeinflussung der Wirtschaftlichkeit durch eventuell notwendige Konsequenzen bei Unverträglichkeiten erkannt und beanwortet werden. Die Notwendigkeit, den Technikbedarf durch den Ausschreiber zu bestimmen, wird in der Praxis häufig nicht akzeptiert. Vielfach wird es - mit der Begründung mangelnder Fachkenntnis - dem Anbieter überlassen, den Bedarf auf Grund der Beschreibung der zu unterstützenden Aufgaben und der Beschreibung der Systementwürfe zu bestimmen. Diesem Vorgehen soll hier nicht gefolgt werden (vgl. Lerneinheit BTECH). Entwickeln des Kriterienkatalogs Im Kriterienkatalog werden die Projektziele als Bewertungskriterien abgebildet. Sein Zweck ist es, eine systematische Grundlage für die Angebotsanalyse (vgl. Lerneinheit TECHM im Band "Informationsmanagement") zu schaffen. Der Kriterienkatalog soll bereits vor dem Durchführen der Ausschreibung vorliegen, • um in der Ausschreibung die Fragen berücksichtigen zu können, deren Beantwortung für die Erfassung der Kriterienerträge erforderlich ist; • um möglichst objektiv, das heißt unabhängig vom einzelnen Angebot, die Angebotsanalyse durchführen zu können; dies schließt nicht aus, daß im Einzelfall Nacherfassungen erforderlich sind. Zwischen Pflichtenheft und Kriterienkatalog besteht also ein enger Zusammenhang; es empfiehlt sich - auch um Manipulationen oder Beeinflussungen bei der Angebotsbewertung vorzubeugen - beide Dokumente parallel zu erstellen. Mit dem Kriterienkatalog legt der Ausschreiber den aus den Projektzielen abgeleiteten Bewertungsrahmen fest, mit dem er die Angebotsanalyse durchführen wird. Der Kriterienkatalog ist also ein vom Ausschreiber und seinen subjektiven Präferenzen abhängiges Instrument und kann nicht verallgemeinert werden.

PFUC - Erstellen des Pflichtenhefts

97

Beim Entwickeln des Kriterienkatalogs wird davon ausgegangen, daß alle Angebote grundsätzlich miteinander vergleichbar sind, also vergleichbare Problemlösungen enthalten. Die Vergleichbarkeit wird durch eine präzise Beschreibung der Systementwürfe im Pflichtenheft zu erreichen versucht. Sollten sich bei der Angebotsanalyse wesentliche Unterschiede in den Problemlösungen zeigen, müssen sie - sofern sie nicht zu einem Ausscheiden der betreffenden Angebote führen - durch Anpassungen (z.B. bei den Anschaffungskosten) berücksichtigt werden. Die Kriterien haben unterschiedliche Zielinhalte und damit auch unterschiedliche Dimensionen; ihr Zielertrag kann teilweise quantitativ, teilweise nur qualitativ bestimmt werden. Der Beitrag der Kriterien zur Erreichung des Gesamtziels ist unterschiedlich hoch ("Präferenzordnung" oder "Gewichtung" der Kriterien). Ein Kriterium kann die Funktion eines M u ß - K r i t e r i u m s oder die eines Wunsch-Kriteriums haben. Voraussetzung für die weitere Bearbeitung eines Angebots ist, daß vorgegebene Zielerträge bezüglich der Muß-Kriterien erreicht sind. Wunsch-Kriterien müssen diese Zielerträge nicht erreichen oder brauchen keinen Zielertrag zu haben; sie beschreiben Eigenschaften, die zur Erreichung der geforderten Funktionen und Leistungen nicht unbedingt erforderlich sind ("nice to have"). Der Kriterienkatalog, in dem die Kriterien mit ihrer Gewichtung festgehalten sind, ist ein internes Dokument für den Ausschreiber; er ist Grundlage für die Ausschreibung, die Angebotsbewertung und die Angebotsauswahl und darf den Anbietern nicht bekanntgegeben werden. Das Pflichtenheft ist ein externes Dokument, das im Zuge der Ausschreibung an die Anbieter weitergegeben wird. Pflichtenheft und Prototyping Das Erstellen von Pflichtenheften ist eine typische Tätigkeit der klassischen (oder: konventionellen) Vorgehensweise in einem IuK-Projekt. Entscheidender Vorteil des Pflichtenhefts ist die klare und für Auftraggeber und Auftragnehmer verbindliche Beschreibung des Auftragsumfangs. Dieser Vorteil kommt wegen der Dynamik der Planungsaufgabe nur selten zur Wirkung. Die potentiellen Auftragnehmer bezeichnen daher in ihren Vertragsklauseln Abweichungen von den im Pflichtenheft beschriebenen Aufgaben als nicht zum Auftragsumfang gehörend; dafür werden Neuverhandlungen gefordert. Derartige Beobachtungen sind Anlaß dafür, daß das Pflichtenheft an Bedeutung verliert und durch systematischen Einsatz von Prototyping (vgl. Lerneinheit PROTY) mit "Stand der Technik-Vereinbarungen" ersetzt wird. Letzteres bedeutet folgendes: Für eine bestimmte, durch ihre Bezeichnung und inhaltliche Beschreibung definierte betriebliche Aufgabe wird die Schaffung eines Informationssystems nach dem "Stand der Technik" vereinbart. Die Dokumentation detaillierter Anforderungen im Pflichtenheft erfolgt nicht. Die Einhaltung der Vereinbarung ist durch Prototyping prozeßabhängig überprüfbar, sodaß bei Abweichungen sofort eingegriffen werden kann. Funktionen und Leistungen, die der Auftraggeber verlangt und die über den "Stand der Technik" hinausgehen, sind mit dem vereinbarten Entgelt nicht abgedeckt. Diese Vorgehensweise bietet sich umso eher an, je mehr es sich um gut strukturierte Aufgaben handelt.

98

Aufgaben der Grobprojektierung

Demonstrationsbeispiel Es wird ein Ausschnitt aus einem Kriterienkatalog gezeigt, in dem jedes Kriterium benummert, bezeichnet und inhaltlich beschrieben ist. Kriterium 1 Bezeichnung: Anschaffungskosten oder Mietkosten/Leasingkosten Inhaltliche Beschreibung: Die mit dem Angebot verbundenen Beschaffungskosten in Geldeinheiten absolut (Anschaffung) bzw. in Geldeinheiten je Zeitabschnitt (z.B. Monat) auf der Basis einer vergleichbaren Konfiguration (falls die angebotene Konfiguration von der geforderten abweicht). Kriterium 2 Bezeichnung: Betriebskosten Inhaltliche Beschreibung: Die bei der Realisierung des Angebots entstehenden "laufenden Kosten" für den Betrieb des Informationssystems, soweit diese vom Angebot ableitbar sind, einschließlich der Wartungskosten auf der Basis einer vergleichbaren Konfiguration (falls die angebotene Konfiguration von der geforderten abweicht). Kriterium 3 Bezeichnung: Anbieterqualifikation Inhaltliche Beschreibung: Die Erfahrung des Anbieters, die Art, die Anzahl und der Umfang gleichartiger Installationen, die Erfahrungen der bisherigen Anwender mit dem Anbieter; der persönliche Eindruck der Mitarbeiter des Ausschreibers über die Qualifikation der Mitarbeiter des Anbieters, der zum Beispiel bei einer Präsentation gewonnen wird; die Marktposition des Anbieters. Kriterium 4 Bezeichnung: Qualitätssicherung Inhaltliche Beschreibung: Die Maßnahmen, mit denen der Anbieter die Erreichung gesetzter Qualitätsziele im Herstellungsprozeß von Software-Produkten unterstützt (z.B. Dokumentation, Reviews, Personalschulung). Kriterium 5 Bezeichnung: Anbieterunterstützung Inhaltliche Beschreibung: Die Art und der Umfang der angebotenen Unterstützung des Ausschreibers durch den Anbieter bei der Einführung und Weiterentwicklung des Informationssystems; die zeitliche Nähe des Anbieters, um bei Störungen unterstützend eingreifen zu können (z.B. auch Fernwartung). Kriterium 6 Bezeichnung: Technologiekonzept Inhaltliche Beschreibung: Der technische Stand der angebotenen Konfiguration, und ob es sich um eine innovative, über Jahre haltbare Technologie bei Hardware und Software handelt. Kriterium 7 Bezeichnung: Sicherungskonzept Inhaltliche Beschreibung: Die Art und der Umfang und damit die Wirkungsweise der Gesamtheit der vom Anbieter vorgesehenen Schutzmaßnahmen.

PFUC - Erstellen des Pflichtenhefts

99

Kriterium 8 Bezeichnung: Nutzenrealisierung Inhaltliche Beschreibung: Die Art und der Umfang des Nutzens, der durch die Reduzierung von Kosten bzw. durch die Erreichung von Zusatznutzen realisiert werden kann, soweit sich bezüglich der Angebote nennenswerte Unterschiede ergeben. Kriterium 9 Bezeichnung: Ergonomie Inhaltliche Beschreibung: Die Art und Weise, wie das Angebot die Probleme der Einordnung der Informations- und Kommunikationstechnologie in die Arbeitsorganisation löst, insbesondere die ergonomische Qualität der Schnittstelle Mensch-Techniksystem (z.B. der Benutzeroberfläche). Methodenverweise Vorgehensweise bei der Grobprojektierung (Lerneinheit VGROB); Prototyporientierte Systemplanung (Lerneinheit PROTY); Bewertungsmethoden (Lerneinheit BEWER im Band "Informationsmanagement"); Benchmarking (Lerneinheit BENCH im Band "Informationsmanagement"). Kontrollfragen 1. 2. 3. 4. 5.

Welchem Zweck dient das Pflichtenheft? Wie ist das Pflichtenheft gegliedert und welchen Inhalt haben seine Teile? Welchem Zweck dient der Kriterienkatalog? Welcher Zusammenhang besteht zwischen Pflichtenheft und Kriterienkatalog? In welchem Verhältnis stehen Pflichtenheft und Prototyping zueinander?

Quellenliteratur Grupp, B.: EDV-Pflichtenheft zur Hardware- und Softwareauswahl. Verlag TÜV Rheinland, Köln 1987 SVD (Hrsg.): EDV-Pflichtenhefte. Wegleitung für die Erstellung von EDV-Pflichtenheften. Schriftenreihe des Instituts für Informatik der Universität Zürich, Bd. 4, 2. A., Verlag Haupt, Bern/Stuttgart 1983 Vertiefungsliteratur Bundesminister des Inneren (Hrsg.): Unterlagen für Ausschreibung und Bewertung von DV-Leistungen (UFAB). Bonn 1985 Mertin, C.-O.: Aktuelle EDV-Musterpflichtenhefte zur präzisen Definition der kompletten Anforderungen an EDV-Lösungen in allen kaufmännischen Bereichen. WEKA Fachverlage, Kissing etal. 1988 Steinmetz, G.: Was ist ein Pflichtenheft? In: Elektronische Rechenanlagen 5/1982, 225 - 229 Normen ÖNORM A2050: Vergebung von Leistungen

VGROB - Vorgehens weise bei der Grobprojektierung Lernziele Sie kennen den Input und den Output der Grobprojektierung. Sie können eine Gliederung des Gesamtsystems, wie es in der Grundkonzeption vorliegt, in Teilprojekte angeben und deren Zweckmäßigkeit begründen. Sie wissen, warum sich der Systementwurf primär am Datensystem orientiert. Sie können den Detaillierungsgrad der Systementwürfe und ihre Abstimmung mit dem Informationssystem-Bestand und untereinander erläutern. Definitionen und Abkürzungen Arbeitsorganisation (work organization) = die Abbildung der betrieblichen Aufgaben in Form von Stellen (Aufbauorganisation) und Arbeitsabläufen (Ablauforganisation). Datenintegration (data integration) = die Form der organisatorischen Integration, bei der die Datenbasis so organisiert wird, daß unterschiedliche Funktionen die gleichen Daten verwenden. Datenstruktur (data structure) = das Ergebnis der Abbildung eines Ausschnitts der Wirklichkeit in ein Datensystem mit einem Datenmodell. Datensystem (data system) = die Abbildung der betrieblichen Aufgaben in Daten und der zwischen den Daten bestehenden Beziehungen. Geschäftsprozeß (business process) = eine Folge von Tätigkeiten, die in einem logischen Zusammenhang zueinander stehen und inhaltlich abgeschlossen sind, sodaß sie von anderen Tätigkeitsfolgen abgrenzbar sind. Geschäftsvorgang (business event) = die durch ein Ereignis (z.B. eine Kundenbestellung) ausgelöste Aktivierung eines Geschäftsprozesses. Komplexität (complexity) = die Eigenschaft eines Systems, die durch die Anzahl seiner Elemente und durch die Anzahl der Beziehungen zwischen den Elementen ("Beziehungsreichtum") gekennzeichnet ist. Methodensystem (method system) = die Abbildung der betrieblichen Aufgaben in Methoden und der zwischen den Methoden bestehenden Beziehungen. Sicherungssystem (backup system) = die Abbildung der betrieblichen Aufgaben in Form von Sicherungsmaßnahmen und der zwischen den Sicherungsmaßnahmen bestehenden Beziehungen. Subsystem (subsystem) = das Ergebnis der Zerlegung eines Systems nach einer bestimmten Zerlegungsprozedur (z.B. ein Teilsystem oder ein Teilprojekt). Systemgliederung (systems structure) = das Ergebnis der Zerlegung eines Systems in Subsysteme (z.B. Teilprojekte). Teilprojekt (part project) = eine Menge von Projektaufgaben, deren Elemente gleichartige Entwurfsarbeiten erfordern (z.B. das Datensystem). Teilsystem (part system) = eine Menge von betrieblichen Aufgaben, deren Elemente bezüglich ihres Sachcharakters gleichartig, bezüglich ihrer Phase unterschiedlich sind (z.B. die Aufgaben des Personalwesens). Transportsystem (communication system) = die Abbildung der betrieblichen Aufgaben in Form von Transportvorgängen und der zwischen den Transportvorgängen bestehenden Beziehungen. Synonym: Kommunikationssystem.

VGROB - Vorgehensweise bei der Grobprojektierung

101

Input und Output der Grobprojektierung Input der Grobprojektierung ist die angepaßte Grundkonzeption des zu schaffenden Informationssystems, die in der Vorstudie als optimales Systemkonzept ermittelt (vgl. Lerneinheit GRUND) und in der Feinstudie gegebenenfalls verändert wurde (vgl. Lerneinheit AFEIN). Die Grundkonzeption beschreibt das System möglichst vollständig, aber nur umrißartig, und läßt die Realisierungswege im einzelnen offen. Sie ist nicht "technikfrei", also kein rein logisches Modell. Damit begrenzt sie nicht nur den logischen Entwurf in der Grobprojektierung, sondern sie steckt auch den Rahmen ab, in dem die physische Realisierung erfolgen soll. Output der Grobprojektierung ist das logische Modell des zu schaffenden Informationssystems. Beim Entwerfen des logischen Modells stellen sich folgende methodische Fragen: • Wie soll das in der Grundkonzeption beschriebene System in Teilprojekte gegliedert werden ("Systemgliederung in Teilprojekte")? • In welcher Reihenfolge soll bei der Bearbeitung der Teilprojekte vorgegangen werden ("Bearbeitungsfolge der Teilprojekte")? • Bis zu welchem Detaillierungsgrad soll der Systementwurf in den Teilprojekten vorangetrieben werden, damit er für die Feinprojektierung geeignet ist ("Detaillierungsgrad der Systementwürfe")? • Wie sind die Systementwürfe der Teilprojekte mit dem vorhandenen Bestand an Informationssystemen und untereinander abzustimmen ("Abstimmen der Systementwürfe")? Systemgliederung in Teilprojekte Die Systemgliederung ist dann erforderlich, wenn das Sachziel der Systemplanung eine umfangreiche Aufgabenstellung in Form eines größeren und komplexen Aufgabensystems beschreibt. Wegen der Größe und der daraus folgenden Komplexität der Planungsaufgabe, ist eine Zerlegung in Teil-Planungsaufgaben notwendig. Die Zerlegung soll für die Grobprojektierung so erfolgen, daß der Systementwurf bestmöglich unterstützt wird. Alternative Vorgehensweisen der Systemgliederung sind die Systemgliederung nach Teilsystemen und die Systemgliederung nach Teilprojekten. Systemgliederung nach Teilsystemen: Bei dieser traditionellen Vorgehensweise wird das Gesamtsystem zunächst in Teilsysteme (also nach funktionalen Gesichtspunkten) gegliedert. In einem zweiten Schritt wird innerhalb der Teilsysteme nach gleichartigen Entwurfsaufgaben gegliedert (z.B. Datenentwurf, Methodenentwurf); die Entwurfsaufgaben werden gegebenenfalls weiter in Komponenten zerlegt (wie z.B. der Datenentwurf in die Komponenten Dateneingabe, Datenspeicherung und Datenausgabe). Diese leicht verständliche Vorgehensweise hat den entscheidenden Nachteil, daß dasselbe Entwurfsobjekt (z.B. Daten) einer Reihe von Entwurfsentscheidungen in unterschiedlichen Teilsystemen, die nur schwer untereinander abgestimmt werden können, unterworfen wird. Abbildung VGROB-1 veranschaulicht die Systemgliederung nach Teilsystemen.

102

Methoden und Techniken der Grobprojektierung

ö SL

5L Personal- E beschaffung E 1

Daten

D xz_

T e i l s y s t e m e

£

Methoden

Personal- = einsatz =

Personal- = E entwicklung = =

Personal- ! abrechnung;

Daten

Daten

Daten

Methoden

Methoden

Methoden

F

Abb. VGROB-1: Systemgliederung nach Teilsystemen

Systemgliederung nach Teilprojekten: Bei dieser Vorgehensweise wird das Gesamtsystem zunächst so gegliedert, daß gleichartige Entwurfsaufgaben zusammengefaßt werden. Innerhalb dieser gleichartigen Entwurfsaufgaben besteht eine Gliederung nach funktionalen Gesichtspunkten, also nach den Teilsystemen. Die Systemgliederung nach Teilprojekten macht die Abstimmung zwischen den Teilprojekten nicht überflüssig, erleichtert sie aber gegenüber der Vorgehensweise nach Teilsystemen. Zudem wird die Verwendung von Methoden und Werkzeugen dadurch erleichtert, daß dasselbe Entwurfsobjekt (z.B. Daten) nur innerhalb eines Teilprojekts einer Reihe von Entwurfsentscheidungen unterworfen wird. Abbildung VGROB-2 veranschaulicht die Systemgliederung nach Teilprojekten. - Personal- = beschaffung = i i

1 1 OJ

1

k k

- Personal- = E einsatz E

— Personal- = = entwicklung e

Date nsy stem

= Personal- = = abrechnung = 5 —

Methodensystem

) i

Abb. VGROB-2: Systemgliederung nach Teilprojekten

Wegen der genannten Vorteile bzw. Nachteile ist die Systemgliederung nach Teilprojekten vorzuziehen. Dabei hat sich die Gliederung in Datensystem, Methodensystem, Arbeitsorganisation, Transportsystem und Sicherungssystem (so

VGROB - Vorgehensweise bei der Grobprojektierung

103

wie sie bereits bei der Systemanalyse eingeführt wurde, vgl. Lerneinheit ANIST) als zweckmäßig erwiesen. Folgende Teilprojekte werden also gebildet: • Teilprojekt Datensystem. Jede Aufgabe benötigt zu ihrer Durchführung aufgabenspezifische Daten, und bei jeder Durchführung einer Aufgabe können aufgabenspezifische Daten erzeugt werden. Die Aufgaben eines Aufgabensystems sind durch Datenbeziehungen gekennzeichnet. Da Aufgaben von Menschen und/oder von Techniksystemen als Aufgabenträger durchgeführt werden, können auch die Beziehungen zwischen den Aufgabenträgern sowie zwischen den Aufgaben und den Aufgabenträgern als Daten beschrieben werden. Integraler Bestandteil des Datensystems ist das Nummernsystem. Lerneinheit WDASY erläutert das Entwerfen des Datensystems. • Teilprojekt Methodensystem. Jede Aufgabendurchführung folgt einer Vorgehensweise, deren Präzisierung primär von der Strukturierbarkeit der Aufgabe abhängt und die von einer Reihe von Entwurfsentscheidungen beeinflußt wird. Entwurfsentscheidungen in einem Teilprojekt müssen Bedingungen berücksichtigen, die durch Entwurfsentscheidungen in anderen Teilprojekten entstanden sind. So erfordern bestimmte Methoden bestimmte Daten, oder bestimmte Methoden werden nicht angewendet, weil sie zu unerwünschten Formen der Arbeitsorganisation führen. Lerneinheit WMESY erläutert das Entwerfen des Methodensystems. • Teilprojekt Arbeitsorganisation. Das Entwerfen der Arbeitsorganisation umfaßt das Gestalten der Arbeitsabläufe (Ablauforganisation) und die Stellenbildung (Strukturorganisation oder Aufbauorganisation). Dabei wird entweder von einer vorhandenen Strukturorganisation ausgegangen, und es wird die raum-zeitliche Ordnung der Arbeitsvorgänge in diese eingefügt, oder es werden die Arbeitsvorgänge zunächst in ihren räumlichen und zeitlichen Bewegungen zu Arbeitabläufen geordnet und dann den Aufgabenträgern und Sachmitteln zugeordnet. Das Entwerfen der Arbeitsorganisation wird in Lerneinheit WAORG gezeigt. • Teilprojekt Transportsystem. Jede betriebliche Tätigkeit wird in einem bestimmten Arbeitsbereich (bei mobilen Arbeitsprozessen) bzw. an einem bestimmten Arbeitsort (bei stationären Arbeitsprozessen) durchgeführt. Das heißt, daß die an der Bearbeitung einer Aufgabe beteiligten Aufgabenträger und Sachmittel örtlich verteilt sind. Zwischen den Aufgabenträgern, zwischen den Sachmitteln sowie zwischen den Aufgabenträgern und den Sachmitteln sind deshalb Transportvorgänge für Daten, Text, Bild und Sprache erforderlich, die in ihrer Gesamtheit das Transportsystem ausmachen. Lerneinheit WTRAN behandelt das Entwerfen des Transportsystems. • Teilprojekt Sicherungssystem. Im Datensystem, im Methodensystem, in der Arbeitsorganisation und im Transportsystem können Störungen durch Fehler, Unzuverlässigkeit und deliktische Handlungen auftreten, die zu Fehlfunktionen führen können. Datenfehler entstehen beispielsweise durch eine nicht korrekte Abbildung von Realitätselementen bei der Datenerfassung. Methodenfehler entstehen beispielsweise durch Verwendung eines Algorithmus, für den die notwendigen Daten nicht vollständig vorliegen. Fehler in der Arbeitsorganisation entstehen beispielsweise durch die Zuordnung von Aufgaben mit hohen Qualifikationsanforderungen auf Aufgabenträger, welche diese Anforderungen nicht erfüllen können. Transportfehler entstehen beispielsweise

104

Methoden und Techniken der Grobprojektierung

durch Störungen auf den Transportwegen. Zur Verhinderung von Störungen oder zur Reduzierung ihrer Auswirkungen werden Sicherungsmaßnahmen entworfen, deren Gesamtheit das Sicherungssystem ist. Lerneinheit WSICH erläutert das Entwerfen des Sicherungssystems. Neuere Ansätze der Systemgliederung versuchen, die eher statische und strukturorientierte Sicht der Teilsysteme und Teilprojekte durch eine stärker dynamische, verhaltensorientierte Sicht abzulösen, indem sie Geschäftsprozesse in den Mittelpunkt rücken. Durch die Modellierung von Geschäftsprozessen wird die Wertschöpfungskette zum Gegenstand expliziter Betrachtung. Da bei der Modellierung eines Geschäftsprozesses letztlich auch Daten, Methoden usw. die Objekte von Entwurfsentscheidungen sind, kann von einer grundlegend unterschiedlichen Vorgehensweise beim Systementwurf nicht die Rede sein. Bearbeitungsfolge der Teilprojekte Anzustreben ist die parallele Bearbeitung aller Teilprojekte, da in der Regel Zwischenergebnisse aus einem Teilprojekt Voraussetzung für die Bearbeitung von Entwurfsaufgaben in einem anderen Teilprojekt sind. Wenn trotzdem von "Bearbeitungsreihenfolge" gesprochen wird, dann ist dies so zu verstehen, daß Entwurfsentscheidungen in einem Teilprojekt in der Regel Entwurfsentscheidungen in den anderen Teilprojekten beeinflussen. Bei der Entscheidung über die Bearbeitungsreihenfolge interessiert insbesondere die Frage, ob das Entwerfen des Datensystems oder das Entwerfen des Methodensystems Priorität hat. Gilt das Primat des Datensystems, dann beeinflussen die Entwurfsentscheidungen im Datensystem die Entwurfsentscheidungen in den anderen Teilprojekten; die Entwürfe in den anderen Teilprojekten - also auch im Teilprojekt Methodensystem - orientieren sich am Datensystem-Entwurf ("datenorientierter Ansatz", "datenzentrierter Ansatz" oder "datengetriebener Ansatz"). Gilt das Primat des Methodensystems, dann beeinflussen die Entwurfsentscheidungen im Methodensystem die Entwurfsentscheidungen in den anderen Teilprojekten; die Entwürfe in den anderen Teilprojekten - also auch im Teilprojekt Datensystem orientieren sich am Methodensystem-Entwurf ("ablauforientierter Ansatz", "funktionsorientierter Ansatz" oder "funktionsgetriebener Ansatz").

Abb. VGROB-3: Vorgehensweise bei der Grobprojektierung

VGROB - Vorgehensweise bei der Grobprojektierung

105

Die beiden Ansätze unterscheiden sich insbesondere darin, daß die Datenorientierung stärker konzeptionell ausgerichtet ist. Sie versucht, die spezifische Projektaufgabe so zu bearbeiten, daß sie in einen allgemeineren Zusammenhang eingeordnet werden kann (insbes. in das unternehmensweite Datenmodell). Bei der Funktionsorientierung steht die schnelle Lösung des Anwendungsproblems im Vordergrund; konzeptionelle und infrastrukturelle Maßnahmen werden "nachgezogen" (oder unterbleiben). "Integrierte Ansätze" müssen die konzeptionell und infrastrukturell ausgerichtete, zeitaufwendige Datenorientierung mit der auf die konkrete Problemlösung abzielenden, eher kurzfristig orientierten Funktionsorientierung verbinden ("Objektorientierung", vgl. Lerneinheit OBOSP). Bei der Konstruktion von Informationssystemen zur Unterstützung betrieblicher Aufgaben gilt in der Regel das Primat des Datensystems. Abbildung VGROB-3 zeigt die Gliederung des Gesamtsystems in Teilprojekte und die Reihenfolge ihrer Bearbeitung (Pfeile) beim datenorientierten Ansatz. Die Anordnung des Sicherungssystems, das für alle anderen Teilprojekte entworfen wird, verdeutlicht dessen Charakter als Querschnittsprojekt. Gründe für die Bevorzugung des datenorientierten Ansatzes sind: • Information als wirtschaftliches Gut. Information ist ein immaterielles wirtschaftliches Gut, das auch bei mehrfacher Nutzung nicht verbraucht wird. Sie ist handlungsbestimmend und beeinflußt damit die Qualität von Entscheidungen. Sie ist kein "freies Gut", sondern verursacht Kosten. Sie ist damit eine Ressource, für die eine gezielte Planung und Nutzung erforderlich sind. Da das wichtigste Instrument zur "Produktion" von Information das Datensystem ist, sollen sich die Entwurfsentscheidungen am Datensystem orientieren. • Datenstrukturen sind stabiler als Funktionen. Datenobjekte und ihre wichtigsten Attribute bleiben in einer Organisation wesentlich länger unverändert als Arbeitsabläufe, die durch Funktionen und ihre Anordnung wesentlich bestimmt sind. So werden durch die Verwendung von IuKTechnologien Arbeitsabläufe drastisch verändert, es werden aber im wesentlichen die gleichen Datenobjekte verwendet, meist mit zusätzlichen Attributen. • Funktionen sind flexibler als Datenstrukturen. Die Entwicklung neuer Anwendungsprogramme ist relativ einfach, wenn eine einheitliche, projektübergreifende Datenstruktur vorhanden ist. Aus dieser Datenstruktur werden die für einzelne Anwendungsaufgaben erforderlichen Datensichten spezifiziert. Erst wenn die Datensicht für eine Anwendungsaufgabe spezifiziert ist, werden die für die Anwendungsaufgabe erforderlichen Funktionen implementiert. • Datenstruktur ist Engpaßfaktor. Funktionen betriebswirtschaftlich oder technisch anspruchsvoller Methoden und Modelle (z.B. in Entscheidungsunterstützungssystemen) können häufig nicht genutzt werden, weil die erforderlichen Daten nicht zur Verfügung stehen. Es ist daher ökonomisch sinnvoll, zunächst die datenmäßigen Voraussetzungen für die Nutzung dieser Methoden und Modelle zu prüfen bzw. zu schaffen. • Dezentralisierung der Software-Entwicklung. Ist ein unternehmensweites Datenmodell implementiert, dann können die Benutzer bei Verwendung leistungsfähiger Endbenutzerwerkzeuge kleinere Anwendungsprogramme schnell selbst entwickeln (vgl. Lerneinheit SVIER). Werden diese Werkzeuge ohne Vorhandensein eines unternehmensweiten Datenmodells verwendet,

106

Methoden und Techniken der Grobprojektierung

besteht die Gefahr des "Wildwuchses im Datensystem" mit unkoordinierten, dezentralen Datenbeständen. • Nutzung von Integrationspotentialen. Ein wichtiges Nutzenpotential der Informationsverarbeitung ist die Schaffung von mehr Integration innerhalb der Komponenten von Informationssystemen und zwischen Informationssystemen (innerbetrieblich und zwischenbetrieblich). Ohne Datenintegration kann dieses Nutzenpotential nicht ausgeschöpft werden; Datenintegration ist Voraussetzung für Systemintegration (insbes. für Funktionsintegration). • Datenorientierung ist verhaltenskonform. Traditionelle Informationssysteme ohne Verwendung von IuK-Technologien (z.B. Finanzbuchhaltung, Rechnungswesen, Lagerbewirtschaftung) basieren auf umfangreichen Datenbeständen und ihrer Interpretation durch die Benutzer (z.B. die Interpretation einer Bilanz, einer G+V-Rechnung und von Kontoauszügen). Die Interpretation erfolgt häufig "ad hoc" mit Prozeduren, die sich im technikgestützen Methodensystem nicht abbilden lassen bzw. deren Abbildung ökonomisch unzweckmäßig ist (vgl. Lerneinheit WMESY). Detaillierungsgrad der Systementwürfe Der Detaillierungsgrad der Systementwürfe wird aus dem Ziel der Grobprojektierung abgeleitet (vgl. Lerneinheit ZAMGP) und in den Teilprojekten präzisiert. Aus der Tatsache, daß die Grundkonzeption nicht technikfrei ist, darf nicht geschlossen werden, daß beim Systementwurf in den Teilprojekten eine Präzisierung der Aussagen zu den verwendeten Techniksystemen erforderlich ist. Dies ist - ganz im Gegenteil - möglichst zu vermeiden. Der Systementwurf in den Teilprojekten befaßt sich konsequent mit dem Entwurf logischer Modelle, allerdings innerhalb des Gestaltungsspielraums, der durch die mit der Grundkonzeption vorgegebenen Techniksysteme gegeben ist (vgl. Lerneinheit GRUND). Abstimmen der Systementwürfe Das Abstimmen der Systementwürfe der Grobprojektierung bedeutet zweierlei, das Abstimmen der Systementwürfe in den einzelnen Teilprojekten mit dem Informationssystem-Bestand und das Abstimmen der Systementwürfe in den einzelnen Teilprojekten untereinander (vgl. Abbildung VGROB-4). Abstimmen der Systementwürfe mit dem Informationssystem-Bestand: Die projektbezogene Planung und Realisierung eines Informationssystems geht von einem unternehmensweiten Rahmenplan aus, der den Bedarf an Informationssystemen beschreibt und der Systemplanung die Planungsziele vorgibt (vgl. Lerneinheit ZAMSP). Bei der Formulierung des Rahmenplans wird einerseits von den strategischen Zielen (vgl. Lerneinheit SZIEL im Band "Informationsmanagement") und andererseits von dem vorhandenen Informationssystem-Bestand ausgegangen. Komponenten des Informationssystem-Bestands sind Datenbasen und Methodenbasen, die bestehende Arbeitsorganisation, vorhandene Transportwege und Sicherungsmaßnahmen. Bei der Erarbeitung der Systementwürfe in den Teilprojekten muß dieser Bestand daraufhin überprüft werden, ob die projektbezogenen Bedarfe durch vorhandene Bestände gedeckt werden können; in diesem Fall sind Neuentwürfe zu vermeiden.

VGROB - Vorgehensweise bei der Grobprojektierung

107

Abstimmen der Systementwürfe untereinander: Durch die Gliederung der Grundkonzeption in Teilprojekte besteht die Gefahr, daß die Zusammenhänge zwischen Daten, Methoden, Arbeitsorganisation, Transportwegen und Sicherungsmaßnahmen verloren gehen. Diese Zusammenhänge bestehen zum Beispiel zwischen Daten und Methoden in der Weise, daß die Verwendung bestimmter Daten bestimmte Methoden erfordert, und daß umgekehrt die Verwendung bestimmter Methoden bestimmte Daten erfordert. Da die Entwurfsmethoden die Beachtung dieser Zusammenhänge im allgemeinen nicht gewährleisten können, muß die Projektplanung entsprechende Abstimmtätigkeiten vorsehen (vgl. Lerneinheit PROPL; nähere Erläuterungen zum Abstimmen der Systementwürfe werden in Lerneinheit WINTE gegeben). ^

Entwurfsbeginn

^

Entwerfen Teilprojekt S777777777777/7//7/S/,

Teilprojekt Abstimmen Systementwurf I Mit InformationssystemBestand abgestimmter Systementwurf Abstimmen Systementwurf y77777777777777777777777777777tfm

j,

Abgestimmter Systementwurf

oo U

Abb. VGROB-4: Abstimmen der Systementwürfe

Demonstrationsbeispiel Gängige Verfahren zur Modellierung von Systementwürfen bestehen vorwiegend aus einer Kombination von Verfahren zum Entwerfen des Datensystems ("Datenmodellierung") und Verfahren zum Entwerfen des Methodensystems ("Funktionsmodellierung"); ein typischer Vertreter ist die Informationsstruktur-Analyse/Funktionsstruktur-Analyse (abgekürzt: ISA/FSA). Es wird gezeigt, wie bei ISA/FSA durch planmäßige Interaktion zwischen Datenmodellierung und Funktionsmodellierung der Zusammenhang zwischen den Teilprojekten gewahrt wird bzw. wie Zwischenergebnisse aufeinander abgestimmt werden. Das Beispiel zeigt auch das Primat des Datensystems.

108

Methoden und Techniken der Grobprojektierung

Das Verfahren beginnt mit z w e i Schritten der Informationsstruktur-Analyse, in denen die Objekttypen der Daten (mit den wichtigsten Attributen) und ihre B e ziehungen festgelegt werden. Darauf folgen sechs Schritte der FunktionsstrukturA n a l y s e , mit denen der Methodenentwurf erfolgt (z.B. werden die aus der Grundkonzeption bekannten Funktionen systematisch zerlegt). Für jede Funktion werden A u s g a b e , Verarbeitung und E i n g a b e festgelegt s o w i e die Querbezüge zum D a t e n m o d e l l untersucht. Mit der Rückkehr zur Informationsstruktur-Analyse f o l g t zunächst ein Abgleich des bislang vorliegenden Datenmodells mit dem soeben entworfenen Funktionsmodell. Anschließend wird das Datenmodell durch A n g a b e weiterer Attribute verfeinert. Ein nochmaliger Abgleich mit d e m Funktionsmodell schließt das Verfahren ab. Zur Verdeutlichung der Integration des datenorientierten Ansatzes mit d e m funktionsorientierten Ansatz kann auch die an anderer Stelle erläuterte Vorgehensweise nach Ferstl/Sinz herangezogen werden (vgl. Lerneinheit OBOSP). Aufgabenverweise Entwerfen des Datensystems (Lerneinheit WDASY); Entwerfen des Methodensystems (Lerneinheit WMESY); Entwerfen der Arbeitsorganisation (Lerneinheit WAORG); Entwerfen des Transportsystems (Lerneinheit WTRAN); Entwerfen des Sicherungssystems (Lerneinheit WSICH); Integration der Systementwürfe (Lerneinheit WINTE); Bestimmen des Technikbedarfs (Lerneinheit BTECH); Erstellen des Pflichtenhefts (Lerneinheit PFLIC). Kontrollfragen 1. 2. 3. 4. 5.

Was ist der Input und was ist der Output der Grobprojektierung? Welche beiden Vorgehensweisen der Systemgliederung können unterschieden werden? In welche fünf Teilprojekte wird das Entwerfen des logischen Modells gegliedert? Welche Gründe sprechen für das Primat des Datensystems beim Systementwurf? Warum wird "Information" im Unternehmen als "wirtschaftliches Gut" bezeichnet?

Quellenliteratur Brenner, W.: Entwurf betrieblicher Datenelemente. Ein Weg zur Integration von Informationssystemen. Springer Verlag, Berlin et al. 1988 Fischer, J.: Datenmanagement - Datenbanken und betriebliche Datenmodellierung. Oldenbourg Verlag, München/Wien 1992 Heinrich, L. J.: Zur Methodik der Systemplanung in der Wirtschaftsinformatik. In: Schult, E. und Siegel, Th. (Hrsg.): Betriebswirtschaftslehre und Unternehmenspraxis. Schmidt Verlag, Berlin 1986, 83 - 99 Vertiefungsliteratur Ferstl, K. und Sinz, E. J.: Geschäftsprozeßmodellierung. In: WIRTSCHAFISINFCRMAIIK 6/1993, 589 - 592 Hage, M. und Lohr, G.: Praktische Erfahrungen mit der Relationalen Datenanalyse bei der Hüls AG. In: Information Management 3/1986, 30 - 39 Mathy, G.: Informatik-Strategie und Relationale Datenbanken. In: Information Management 2/1987, 6 - 17 Mathy, G.: Wettbewerbsinstrument Relationale Datenbanken. Die Anforderungen des Tools an die organisatorische Infrastruktur. AIT Verlagsgesellschaft, Halbergmoos 1987

OBTYP - Objekttypenmethode Lernziele Sie kennen den Zweck der Objekttypenmethode und die Ansätze zur Bildung von Datenobjekttypen. Sie kennen die Bedeutung der Konstruktion von Begriffen auf der fachsprachlichen Ebene der Benutzer für das Entwerfen des semantischen Datenmodells. Sie kennen die Instrumente der Begriffskonstruktion, das sind Inklusion, Konnexion und Aggregation. Sie können das semantische Datenmodell für eine betriebliche Aufgabe entwerfen. Definitionen und Abkürzungen Allgemeinbegriff (general term) = ein Begriff, dessen Extension >1 ist. Aquipollenz (equipollence) = die Tatsache, daß zwei Begriffe gleicher Extension unter verschiedener Intension betrachtet und daher unterschiedlich bezeichnet werden. Aussage (proposition) = ein Satz, der eine erklärende Behauptung enthält und den Anspruch erhebt, wahr zu sein. Aussagensystem (proposition system) = eine Menge von Aussagen über einen bestimmten Aussagenbereich (z.B. eine betriebliche Aufgabe). Begriff (term) = eine Aussageform, deren Wert immer ein Wahrheitswert ist. Bezeichner (marker) = der Name eines Begriffs. Synonym: Begriffswort. Datenobjekttyp (data entity type) = ein konstruierter, aus Benutzersicht gewonnener Fachbegriff im Datenmodell. Synonyme: Entitätsklasse, Entitätsmenge, Entitätstyp. Deduktion (deduction) = die Ableitung von spezifischen Aussagen aus allgemeinen Aussagen. Extension (extension) = der Umfang eines Begriffs; seine Eigenschaft, einem oder mehreren Unterbegriffen übergeordnet zu sein. Fachbegriff (technical term) = ein Begriff, der für eine bestimmte betriebliche Aufgabe konstruiert ist (z.B. "Auftrag" für die Aufgabe "Bestellwesen"). Homonym (homonym) = ein Wort, das gleich geschrieben und gesprochen wird wie ein anderes Wort, aber eine andere Extension und Intension hat. Individualbegriff (individual term) = ein Begriff, dessen Extension 1 ist. Induktion (induction) = die Ableitung von allgemeinen Aussagen aus spezifischen Aussagen. Intension (intension) = die Gesamtheit der inhaltlichen Merkmale eines Begriffs. Objekttyp (entity type) = Synonym für Datenobjekttyp. Satz (clause) = eine Aussage, eine Norm ("normative Aussage") oder eine Regel. Semantik (semantics) = die Lehre von den Inhalten sprachlicher Zeichen, das heißt von den Beziehungen der Zeichen zum gemeinten Gegenstand, semantisches Datenmodell (semantic data model) = das Ergebnis der Konstruktion der begrifflichen Zusammenhänge einer Aufgabe auf der fachsprachlichen Ebene der Benutzer. Synonym (synonym) = ein Wort, das mit einem anderen Wort von gleicher Bedeutung ist (z.B. das Wort Synonym und das Wort Aliasname).

110

Methoden und Techniken der Grobprojektierung

Zweck der Objekttypenmethode Genereller Zweck der Objekttypenmethode ist es, das Entwerfen des Datensystems zu unterstützen. Die Entwurfsunterstützung ist primär heuristisch in der Weise, daß die Entwurfsaufgabe in Teilaufgaben zerlegt und eine zweckmäßige Abfolge der Durchführung der Teilaufgaben angegeben wird ("Arbeitsschritte"). In Lerneinheit WDASY wurde, ausgehend von einer gegebenen Entwurfsaufgabe, eine in fünf Arbeitsschritte gegliederte Vorgehensweise entwickelt und damit eine sehr allgemeine Methode der Datenmodellierung angegeben. Diese Vorgehensweise bedarf der Ergänzung, weil sie keine Unterstützung dafür gibt, aus der gegebenen Entwurfsaufgabe eines bestimmten Ausschnitts der Wirklichkeit (z.B. Finanzbuchhaltung, Personalwesen, Auftragsbearbeitung) die Datenobjekttypen herauszuarbeiten. Jeder Ausschnitt der Wirklichkeit ist in irgendeiner Weise organisiert. Diese Organisiertheit ist auch Folge eines eingeführten Systems von Fachbegriffen. Einzelnen Objekten der Wirklichkeit sind bestimmte Begriffe des Begriffssystems, einzelnen Vorgängen, Ereignissen und Sachverhalten sind ganze Ausschnitte des Begriffssystems zugeordnet. Das Begriffssystem ist Ausdruck der fachlichen Theorie des betrachteten Ausschnitts der Wirklichkeit. Spezieller Zweck der Objekttypenmethode ist es, alle für die betrachtete Aufgabe notwendigen Fachbegriffe eindeutig festzulegen, sie von Störungen und Ungenauigkeiten ihrer Semantik und ihres Aufbaus (insbes. der ihnen zugeordneten Attribute) zu befreien und durch Datenobjekttypen zu ersetzen. Mit anderen Worten: die (Re-)Konstruktion eines semantischen Datenmodells als Voraussetzung für den Entwurf des konzeptionellen Datenmodells in Form eines EntityRelationship-Modells (vgl. Lerneinheit ERMOD). Die Wörter "konstruieren" und "rekonstruieren" werden im folgenden synonym verwendet, weil "neue" Begriffe in der Regel aus bereits vorhandenen Begriffen entwickelt werden (daher die Bezeichnung "rekonstruieren", auch als "(re)konstruieren geschrieben). Konstruieren in Begriffen Einfache Sachverhalte wie "Huber ist ein MITARBEITER", "A 12 ist eine ABTEILUNG" und "Huber ARBEITET IN A 12" können festgestellt und begrifflich erfaßt werden, wenn geregelt ist, was unter MITARBEITER zu verstehen ist, wann von einer ABTEILUNG gesprochen werden kann und welche Bedeutung im Zusammenhang mit MITARBEITER und ABTEILUNG die Bezeichnung ARBEITET IN hat. Die Begriffe MITARBEITER (x), ABTEILUNG (y) und ARBEITET IN (x,y) sind als Aussagefunktionen, die über ihre Argumentevariablen x und y das Begriffssystem zum Einsatz bringen, ausschlaggebend für die Möglichkeit der Feststellung der genannten Sachverhalte. Wahre Sachverhalte werden Tatsachen genannt. Dazu sind die Argumentevariablen der Begriffe oder Aussagefunktionen durch die Namen der Objekte (hier: "Huber" für "x" und "A 12" für "y") zu besetzen, für die die nun vorliegenden Behauptungen ("Sätze") überprüfbar sind. Die benannten Objekte (Huber bzw. A 12) fallen unter die Begriffe (sie gehören zu ihrer Extension), wenn die aufge-

OBTYP - Objekttypenmethode

111

stellten Sätze wahr sind. Die Objekte fallen nicht unter die Begriffe, wenn die Sätze falsch sind. Das Begriffssystem, das im Anwendungsbereich einer bestimmten Entwurfsaufgabe verwendet wird, repräsentiert das Fachwissen, über das die Personen verfügen (müssen), die in diesem Anwendungsbereich tätig sind. Da es der Zweck eins Informationssystems ist, Aufgabenträger bei der Erledigung ihrer Aufgaben zu unterstützen, muß sich das Datensystem an dem bestehenden System von Fachbegriffen orientieren. Mit anderen Worten: Der erste Schritt der Datenmodellierung muß darin bestehen, auf der fachsprachlichen Ebene der potentiellen Benutzer ("Benutzerebene") die Fachbegriffe zu (re)konstruieren, die zur Bearbeitung ihrer Aufgaben erforderlich sind. Aus den Fachbegriffen werden die Datenobjekttypen gebildet, und es werden ihre Attribute festgelegt. Die aus den (re)konstruierten Fachbegriffen gebildeten Datenobjekttypen mit ihren Attributen und den Beziehungen zwischen den Datenobjekttypen sind das semantische Datenmodell. Erst nach Vorliegen des semantischen Datenmodells ist der technologie-orientierte logische Entwurf des Datenmodells möglich. Die Herausarbeitung der Datenobjekttypen ist also eine Aufgabe, deren erfolgreiche Bearbeitung anwendungsspezifisches Wissen der Fachabteilungen erfordert. Deshalb ist die enge Zusammenarbeit des Systemplaners mit den Mitarbeitern der Fachabteilungen unerläßlich. Ansätze zur Bildung von Datenobjekttypen Diese Überlegungen zeigen, daß der Prozeß des Entwerfens des Datensystems primär in Abstraktionsebenen gegliedert ist, wobei von der fachsprachlichen Ebene der Benutzer ausgegangen, mit der logischen Ebene fortgesetzt und schließlich mit der physischen Ebene abgeschlossen wird. Sie zeigen auch, daß der Prozeß des Entwerfens des Datensystems bedarfsorientiert ist, indem von der Informationsnachfrage (Informationsbedarf und Informationsbedürfnis, vgl. Lerneinheit ANFOA) ausgegangen wird. In der Praxis wird häufig eine anwendungsorientierte Vorgehensweise verwendet, die dadurch gekennzeichnet ist, daß von den Datenelementen ausgegangen wird, die im Istzustand des Datensystems (also in bestehenden Dateien und Datenbanken sowie in jeder Form von Dokumenten) vorhanden sind. Sie ist leicht anzuwenden, weil sie sich an den vorhandenen Datenbeständen orientieren kann. Ihr entscheidender Nachteil ist, daß Datenbedarfe, die sich aus einer gegenüber dem Istzustand veränderten Informationsnachfrage ergeben, nicht berücksichtigt werden. Zweckmäßig ist daher eine kombinierte Vorgehensweise, bei der die Bedarfsorientierung eindeutig im Vordergrund steht und die Informationsnachfrage Ausgangspunkt ist; die Bedarfsorientierung wird durch Anwendungsorientierung ergänzt. Ein Beispiel für die kombinierte Vorgehensweise ist die Substantivanalyse (auch: Formularanalyse). Mit ihr werden aufgabenspezifische Dokumente (insbes. Formulare) nach Substantiven durchsucht. Bei jedem gefundenen Substantiv wird geprüft, ob es der Informationsnachfrage entspricht (genauer: ob über das Substantiv Information nachgefragt wird). Wenn ja, wird in einem zweiten Arbeitsschritt geprüft, ob das Substantiv ein Datenobjekttyp ist oder ob es nur Zusatzinformation zu einem Datenobjekttyp liefert, also ein Attribut ist.

112

Methoden und Techniken der Grobprojektierung

Bei der Herausarbeitung der Datenobjekttypen kann deduktiv, induktiv oder kombiniert deduktiv/induktiv vorgegangen werden. Das Vorgehen ist deduktiv, wenn von allgemeinen, bekannten Sätzen ausgegangen und mit Hilfe von Wissen auf spezifische Sätze geschlossen wird ("Top-down-Ansatz"). Zum Beispiel werden mit Hilfe von Wissen über die Teilmärkte der Beschaffung und des Absatzes aus dem allgemeinen Datenobjekttyp ARTIKEL die Datenobjekttypen BESCHAFFUNGSARTIKEL und VERKAUFSARTIKEL, sodann zum Beispiel aus dem Datenobjekttyp VERKAUFSARTIKEL die Datenobjekttypen INLANDSARTIKEL und EXPORTARTIKEL gebildet. Von hier aus wird auf die Eigenschaften der Datenobjekttypen INLANDSARTIKEL und EXPORTARTIKEL geschlossen; es werden also die Attribute der Objekttypen bestimmt. Das Vorgehen ist induktiv, wenn konkrete, bekannte Sätze verallgemeinert werden ("Bottom-up-Ansatz"). Zum Beispiel werden die in der Wirklichkeit beobachteten Eigenschaften KONTINENT, LANDESSPRACHE und WÄHRUNG zum Datenobjekttyp EXPORTMARKT zusammengefaßt. Auch hier ist eine kombinierte, also deduktiv/induktive Vorgehensweise zweckmäßig. Dabei hängt es vom Einzelfall ab, ob deduktives oder induktives Vorgehen im Vordergrund steht. Hat der Entwerfer mehr Wissen in Form allgemeiner Sätze (z.B. Theoriewissen), wird er primär deduktiv vorgehen; hat er dagegen eher Faktenwissen (z.B. aus praktischer Erfahrung), dann wird er primär induktiv vorgehen. Instrumente zur Begriffskonstruktion Die Objekttypenmethode geht primär bedarfsorientiert vor und verwendet sowohl die deduktive als auch die induktive Vorgehensweise. Gegenstand der Konstruktionshandlungen sind fachbezogene Bedeutungssysteme, deren Elemente Begriffe sind. Ein Begriff wird als Aussageform verstanden, deren Wert immer ein Wahrheitswert ist. Er besteht aus einem Begriffswort (Prädikat) und einem Argumentebereich, in den Namen von einzelnen Informationsobjekten ("Prädikation") oder Mengen von Informationsobjekten ("Klassifikation") eingesetzt werden. Alle Gegenstände, die unter einen Begriff fallen, sind im Hinblick auf diesen Begriff partiell nicht unterscheidbar. Die Begriffskonstruktion erfolgt sowohl extensional durch eindeutige Festlegung der Wertebereiche der Attribute als auch intensional durch die Zusammenfassung von Attributen zu Datenobjekttypen. Die Konstruktionshandlungen werden durch grafische Modellierung unterstützt; die verwendete Symbolik zeigt Abbildung OBTYP-1. Dreieck: inklusive Begriffskonstruktion (Inklusion) Raute: konnektive Begriffskonstruktion (Konnexion) ^ ^

Drachen: aggregative Begriffskonstruktion (Aggregation)

Abb. OBTYP-1: Symbolik zur Begriffskonstruktion (Quelle: Ortner)

OBTYP - Objekttypenmethode

113

• Inklusion: Gattungsbegriffe werden aus Artbegriffen (Generalisierung) oder umgekehrt werden Artbegriffe aus Gattungsbegriffen (Spezialisierung) gebildet. Diese Konstruktionshandlung wird durch das mögliche Enthaltensein eines oder mehrerer Begriffe in einem anderen Begriff veranlaßt. Im Hinblick auf den Gattungsbegriff sind die Artbegriffe partiell nicht unterscheidbar. In Abbildung OBTYP-2 (linker Teil) sind die Begriffe KUNDE und LIEFERANT Artbegriffe, GESCHÄFTSPARTNER ist der Gattungsbegriff. • Konnexion: Datenobjekttypen werden zu komplexen Datenobjekttypen verbunden, in denen jeder (einfache) Datenobjekttyp eine spezifische Aufgabe im Hinblick auf das Funktionieren des begrifflichen Ganzen erfüllt; sie stehen in einer bestimmten Wirkbeziehung zueinander. Abbildung OBTYP-2 (mittlerer Teil) zeigt die Begriffe KUNDE, ARTIKEL und ZEIT in ihrer Zusammenfassung zum Begriff KUNDENAUFTRAG. Damit wird das Ereignis "vom Kunden x zum Zeitpunkt y der Artikel z bestellt" erfaßt und in seinen Eigenschaften beschrieben (z.B. Bestellmenge, Liefertermin). • Aggregation: Aggregate entstehen durch Zusammenfassen von gleichen oder verschiedenen Gegenständen zu einem relativ einheitlichen Ganzen. Zwischen den Gegenständen besteht sowohl partielle Gleichheit als auch teilweise Abhängigkeit. Beispielsweise besteht zwischen den in Abbildung OBTYP-2 (rechter Teil) dargestellten Gegenständen ARBEITSPLATZ, die zu einer ABTEILUNG zusammengefaßt sind, partielle Gleichheit dadurch, daß sie dem gleichen Meister unterstellt sind; sie hängen etwa dadurch voneinander ab, daß sie an der Erledigung eines Auftrags in dieser Abteilung beteiligt sind. Die durch ein Beziehungssymbol (Dreieck, Raute und Drachen) in einem semantischen Datenmodell dargestellten Beziehungen werden zusammen mit ihren Objekttypen Beziehungskomplexe genannt. GESCHÄFTSPARTNER

ABTEILUNG

I

KUNDE

LIEFERANT

ARBEITSPLATZ

Abb. OBTYP-2: Inklusion, Konnexion und Aggregation

Methoden zur Begriffskonstruktion Ausgehend von einem Begriffsmodell, das die Repräsentationsebenen Begriffswort (Zeichenebene), Extension (Gegenstandsebene) und Intension (Merkmalsoder Definitionsebene) für Begriffe unterscheidet, lassen sich folgende Methoden nennen, die für die Bedeutungsanalyse verwendet werden: • Beobachtung, Mitarbeit, Exemplaranalyse und Demonstration von Extensionsobjekten ermöglichen die Rekonstruktion eines Begriffs über die unter diesem Begriff subsumierten Gegenstände. Die Methoden sind erfahrungsgemäß sehr wirksam, aber aufwendig und nur bei physischen Objekten verwendbar. Sie

114

Methoden und Techniken der Grobprojektierung

können in die Klasse der exemplarischen Rekonstruktionsverfahren eingeordnet werden. Man hält sich primär an die Extension der Begriffe. • Auswertung von Fragebögen und Protokollen, Dokumentenanalyse und Literaturanalyse verschaffen den Zugang zu den Begriffen (Hermeneutik als Rekonstruktionsmethode). Mit Hermeneutik wird das einem Text zugrundeliegende Begriffssystem des Verfassers rekonstruiert. • Besprechungen, Brainstorming, Interviews, Workshops und Tutorials sind vorwiegend kommunikative, meist ohne anschauliche Extension praktizierte Methoden zur Erarbeitung von Begriffsdefinitionen. Sie sind vornehmlich der intensionalen Ebene zuzuordnen, wobei auch die Zeichenebene (Begriffswörter) und die Extension der Begriffe nicht ausgeschlossen sind. Eine eindeutigere Zuordnung der Methoden ergibt sich, wenn sprachwissenschaftliche und denkpsychologische Kategorien verwendet werden: • Zeichenebene und Extension bilden durch Methoden wie Mitarbeit, Exemplaranalyse, Beobachtung, teilweise auch Dokumentenanalyse und Protokollanalyse einen empraktischen ("mit der Praxis") Zugang zu Begriffen. Das, worüber geredet wird, ist vorhanden, kann gezeigt werden, oder es wird durch eine nicht-sprachliche Handlung vermittelt. Die Sprechhandlung fällt mit der nichtsprachlichen Handlung zusammen und erläutert den Begriff. • Mit Methoden wie Fragebogen, Interview, Brainstorming und Fachgespräch erfolgt sowohl auf Zeichenebene (schriftlich oder mündlich) als auch durch Analyse der Intension der eingesetzten Wörter die Rekonstruktion der Begriffe epipraktisch ("nach der Praxis"). Mit epipraktischer Kommunikation ist die Rede über Gegenstände gemeint, die nicht unmittelbar präsent sind. Eine "Kontrolle" durch Zeigen, Handeln usw. ist nicht möglich. Demonstrationsbeispiel Am Beispiel des Unternehmens DATEV (Datenverarbeitungsorganisation des steuerberatenden Berufes in der Bundesrepublik Deutschland) wird die semantische Datenmodellierung gezeigt (entnommen aus: Ortner 1993). Folgende Arbeitsschritte sind abzuwickeln: • • • •

Sammlung relevanter Aussagen; Klärung und Rekonstruktion der Fachbegriffe; Klassifizierung der Aussagen; grafische Dokumentation.

Erster Arbeitsschritt: Sammlung relevanter Aussagen. Die ersten Ergebnisse der Modellierung sind natürlich-sprachliche Aussagen folgender Form: • MITGLIEDER der DATEV können NATÜRLICHE PERSONEN oder GESELLSCHAFTEN sein. • Nur NATÜRLICHE PERSONEN können sich zu einer SOZIETÄT zusammenschließen. • Die DATEV erkennt SOZIETÄTEN als Nutzer ihrer DIENSTLEISTUNGEN nur an, wenn alle SOZIETÄRE auch MITGLIEDER der DATEV sind.

OBTYP - Objekttypenmethode

115

Solche Aussagen sind noch unscharf, unkorrekt oder widersprüchlich, weil die zugrunde liegenden Begriffe unscharf, unkorrekt oder widersprüchlich sind. Folgende Fragen sind zu klären: • Wie unterscheiden sich im vorliegenden Zusammenhang NATÜRLICHE PERSONEN und GESELLSCHAFTEN voneinander? • Was sind SOZIETÄRE? • Können SOZIUS, SOZIETÄR und SOZIETÄTSPARTNER synonym verwendet werden? • Was sind die DIENSTLEISTUNGEN dieses Unternehmens? • Wie ist DATEV definiert? Zweiter Arbeitsschritt: Klärung und Rekonstruktion der Fachbegriffe. Dazu ist es zweckmäßig, für jeden Begriff ein Arbeitsmodell zu entwickeln, in dem der Bezeichnung des Begriffs ("Begriffswort") seine verbal beschriebene Extension und Intension zugeordnet werden. Abbildung OBTYP-3 zeigt dies für die Begriffe DATEV und MITGLIED. Daran ist erkennbar, daß ein Begriff entweder Individualbegriff (im Beispiel DATEV) oder Allgemeinbegriff (im Beispiel MITGLIED) ist.

Inhalt (Intension)

Zeichenebene

Umfang (Extension)

Datenverarbeitungsorganisation des steuerberatenenden Berufes in der Bundesrepublik Deutschland, eingetragene Genossenschaft

In die Liste der Genossen beim Amtsgericht eingetragene, zur unbeschränkten Hilfeleistung in Steuersachen befugte Person oder Gesellschaft

DATEV e. G.

MITGLIED

diejenige Organisation, die diesen "Namen" trägt

z. Zt. 27.000 der DATEV angeschlossene "Steuerberater"

Abb. OBTYP-3: Intension und Extension von Begriffen (Quelle: Ortner 1993)

Typische Begriffsdefekte, die im zweiten Arbeitsschritt zu untersuchen sind, sind folgende: • Das Vorhandensein von Synonymen (z.B. MITGLIED und GENOSSE bedeuten bei DATEV dasselbe), die kontrolliert werden müssen. • Das Vorhandensein von Homonymen, die beseitigt werden müssen. • Das Vorhandensein von Äquipollenzen (z.B. LAGERBESTAND als mengenmäßige und WARENKONTO als wertmäßige Aussage über den Artikelbestand), die aufgedeckt werden müssen.

116

Methoden und Techniken der Grobprojektierung

• Das Vorhandensein von Vagheiten (z.B. gehört WOHNSITZ - als Ort der Berufsausübung von BERATER - zu KANZLEI?), die geklärt werden müssen. • Das Vorhandensein von falschen Bezeichnern, die ersetzt werden müssen. Mit der Beseitigung aufgefundener Begriffsdefekte wird der Aussagenbestand fortlaufend aktualisiert und komplettiert. Dritter Arbeitsschritt: Klassifizierung der Aussagen. Alle weiteren Ergebnisse der Modellierung, die als Objekttypen, Beziehungskomplexe, Attribute und Integritätsbedingungen im semantischen Datenmodell auftreten, leiten sich systematisch aus dem Aussagenbestand ab. Dazu müssen die Aussagen klassifiziert und zu Gruppen zusammengefaßt werden. Hierbei orientiert man sich an der Struktur und an den Verbindungswörtern in den Aussagen. Folgende Gliederung der Aussagenbasis bietet sich an: • • • •

Aussagen Aussagen Aussagen Aussagen

über Objekte und Objekteigenschaften; über Operationen mit den Objekten; über Ereignisse, die Operationen in den Datenbeständen auslösen; über Integritätsbedingungen.

Aussagen der Form "Ein MITGLIED ist eine NATÜRLICHE PERSON oder eine GESELLSCHAFT", "Sowohl NATÜRLICHE PERSONEN als auch GESELLSCHAFTEN sind MITGLIEDER", "Alle GESELLSCHAFTEN sind MITGLIEDER" begründen inklusive Begriffsbeziehungen im semantischen Datenmodell. Es ist derselbe Objektbereich, nämlich DATEV-MITGLIEDER, der aus drei verschiedenen Sichten gesehen wird, und dessen begriffliche Ordnung sich als Inklusion aus der Analyse der Verbindungswörter in den Aussagen ergibt. Kennzeichnend für inklusive Beziehungen sind Verbindungswörter in den Aussagen wie "und", "oder", "sowohl als auch". Aussagen der Form "Ein MITGLIED kann mehrere DIENSTLEISTUNGEN nutzen", "Eine DIENSTLEISTUNG kann von mehreren MITGLIEDERN genutzt werden", "Die Nutzungsmöglichkeit einer DIENSTLEISTUNG durch ein MITGLIED wird NUTZUNGSRECHT genannt" führen zu konnektiven Begriffsbeziehungen im semantischen Datenmodell. Die festgestellten Beziehungen zwischen den Objektbereichen der Begriffe MITGLIED und DIENSTLEISTUNG werden selbst zu Objekten und unter dem neu gebildeten Begriff NUTZUNGSRECHT zusammengefaßt. Aussagen der Form "Eine SOZIETÄT besteht aus mehreren NATÜRLICHEN PERSONEN", "EINE NATÜRLICHE PERSON gehört (höchstens) einer SOZIETÄT an", "Es gibt NATÜRLICHE PERSONEN, die nicht einer SOZIETÄT angehören" basieren auf aggregativen Begriffsbeziehungen im semantischen Datenmodell. Objekte eines Begriffs (NATÜRLICHE PERSON) werden unter den Objekten eines anderen Begriffs (SOZIETÄT) zusammengefaßt. Kennzeichnend für aggregative Beziehungen sind Verbindungswörter in den Aussagen wie "gehört zu", "besteht aus", "wird zugeordnet". Vierter Arbeitsschritt: Grafische Dokumentation. Abbildung OBTYP-4 zeigt das semantische Datenmodell als Ergebnis der durchgeführten Konstruktions-

OBTYP - Objekttypenmethode

117

handlungen. Diese Darstellung allein reicht als Kommunikationsmittel zwischen den an der Modellierung Beteiligten nicht aus; die natürliche Sprache ist ergänzend einzusetzen (z.B. indem die Konstruktionshandlungen und ihr Ergebnis umgangssprachlich beschrieben werden). Bei Vorlage (nur) grafisch dokumentierter Ergebnisse werden in der Regel keine klaren gemeinsamen Begriffsdefinitionen erreicht. Bei Vorlage von normierten Aussagesammlungen ergeben sich oft Hinweise für die Verbesserung der Ergebnisse oder für ihre Bestätigung.

Abb. OBTYP-4: Teilschema des semantischen Datenmodells (Quelle: Ortner 1993) Aufgabenverweise Entwerfen des Datensystems (Lerneinheit WDASY). Kontrollfragen 1. Welcher spezielle Zweck wird mit der semantischen Datenmodellierung verfolgt? 2. Welche Ansätze zur Bildung von Objekttypen werden unterschieden? 3. Wodurch unterscheiden sich die Konstruktionshandlungen Inklusion, Konnexion und Aggregation? 4. Mit welchen Methoden werden die Konstruktionshandlungen unterstützt? 5. In welche Arbeitsschritte kann der Konstruktionsprozeß gegliedert werden? Quellenliteratur Brenner, W.: Entwurf betrieblicher Datenelemente - Ein Weg zur Integration von Informationssystemen. Springer Verlag, Berlin et al. 1988 Ortner, E.: Semantische Modellierung - Datenbankentwurf auf der Ebene der Benutzer. In: Informatik Spektrum 8/1985, 20 - 28 Ortner, E.: Unternehmensweite Datenmodellierung als Basis für integrierte Informationsverarbeitung in Wirtschaft und Verwaltung. In: WnmCHAFISINFCRMAnK4/1991, 269 - 280 Ortner, E.: Informationsverarbeitung und Sprachkritik - Ein komplementärer Integrationsbereich für Benutzer, Management und Systeme. Institutsbericht 17/93, Universität Konstanz - Informationswissenschaft, Konstanz 1993 Ortner, E. und Söllner, B.: Semantische Datenmodellierung nach der Objekttypenmethode. In: Informatik Spektrum 1/1989, 31 - 4 2

118

Methoden und Techniken der Grobprojektierung

Vertiefungsliteratur Bechtel, M. et al.: Datenmodellierung bei der Bühler AG, Uzwil (Schweiz) Pensionskasse. Institutsbericht 3/92, Universität Konstanz - InformationsWissenschaft, Konstanz 1993 Benyon, D.: Information and Data Modelling. Blackwell Scientific Publications, Oxford et al. 1990 Bühler, K.: Sprachtheorie. Die Darstellungsfunktion der Sprache. Fischer Verlag, Stuttgart 1978 Lorenzen, P.: Konstruktivismus und Hermeneutik. In: Lorenzen, P. (Hrsg.): Konstruktive Wissenschaftstheorie. Suhrkamp Verlag, Frankfurt 1974, 113- 118 Ortner, E.: Aspekte einer Konstruktionssprache für den Datenbankentwurf. Toeche-Mittler Verlag, Darmstadt 1983 Wedekind, H. und Ortner, E.: Systematisches Konstruieren von Datenbankanwendungen - Zur Methodologie der Angewandten Informatik. Hanser Verlag, München 1980

ERMOD - Entity-Relationship-Modell Lernziele Sie kennen den Zweck des als Entity-Relationship-Modell bezeichneten, generellen Beschreibungsmittels für logische Datenstrukturen und einige Weiterentwicklungen des Grundmodells. Sie erkennen, daß die wesentlichen Konstruktoperatoren der Objekttypenmethode im Entity-Relationship-Modell berücksichtigt werden können. Sie kennen die als Schlüsselkonzept bezeichnete Vorgehensweise bei der Datenmodellierung im Entity-Relationship-Modell. Definitionen und Abkürzungen Beschreibungsmittel (description means) = eine Methode zur Abbildung eines Systems mit seinen wesentlichen Eigenschaften, mit einem bestimmten Grad der Formalisierung und mit einer bestimmten Art der Darstellung. Synonym: B eschreibungssprache. Beziehungstyp (relation type) = die Zusammenfassung gleichartiger Beziehungen zwischen zwei Entitätstypen, die im ERM als Raute dargestellt oder als Rollenname angeschrieben wird. Synonym: Assoziationstyp. Datenstruktur (data structure) = das Ergebnis der Abbildung eines Ausschnitts der Realität in ein Datensystem mit einem Datenmodell. Domäne (domain) = der Wertebereich eines Attributs. Entitätstyp (entity type) = die Verallgemeinerung gleichartiger Entitäten; sie werden im ERM als Rechteck dargestellt. Synonym: Entitätsmenge. ERM = Akronym für Entity-Relationship-Modell. Synonyme: ER-Diagramm, Chen-Diagramm. Kardinalität (cardinality) = die Anzahl der Beziehungsausprägungen zwischen zwei Entitätstypen, die angibt, wieviele Entitäten eines Entitätstyps mit einer Entität eines anderen Entitätstyps in Beziehung stehen (können). Komplexitätsgrad (degree of complexity) = eine Notation, welche die Oberund Untergrenze der Anzahl der Beziehungsausprägungen angibt. Konstruktoperator (construct operator) = eine Vorschrift, die angibt, wie aus einem Entitätstyp andere Entitätstypen abgeleitet werden können. Modell (model) = die vereinfachende Abbildung eines Ausschnitts der Wirklichkeit und ihre Darstellung mit einem bestimmten Beschreibungsmittel. RDBMS = Abkürzung für relationales Datenbank(management)system. rekursive Beziehung (recursive relationship) = die Tatsache, daß an einem Beziehungstyp mehrere Entitäten desselben Typs beteiligt sein können. Relationenmodell (relation model) = ein Beschreibungsmittel für logische Datenstrukturen, das die Tabelle als Darstellungsmittel verwendet und auf die explizite Darstellung von Beziehungen zwischen den Entitätstypen verzichtet. Synonym: Relationenschema. Schlüssel (key) = ein Attribut oder eine Kombination von Attributen, das bzw. die ein Element (z.B. eine Entität) in einer Menge von Elementen (z.B. einer Relation) auszeichnet. Synonym: Schlüsselattribut. Transformation (transformation) = die Überführung eines logischen Datenmodells in das Schema eines Datenbanksystems.

120

Methoden und Techniken der Grobprojektierung

Zweck des Entity-Relationship-Modells Das Entity-Relationship-Modell (abgekürzt: ERM) ist ein grafisch orientiertes B e s c h r e i b u n g s m i t t e l für logische Datenstrukturen (auch als Beschreibungssprache oder als Entwurfs- und Beschreibungssprache bezeichnet, da es entwurfsunterstützende Eigenschaften hat). Bei der Erläuterung der Objekttypenmethode (vgl. Lerneinheit OBTYP) wurden bestimmte grafische Beschreibungselemente benutzt; diese werden im allgemeinen nicht als Beschreibungssprache oder als Teile einer Beschreibungssprache verwendet. Vielmehr hat sich das ERM als grafisches Beschreibungsmittel für logische Datenstrukturen durchgesetzt. Es kann jedoch gezeigt werden, daß das ERM einige Konstruktionshandlungen der Objekttypenmethode wirkungsvoll unterstützt. Die Grundlagen für das ERM wurden 1976 von P. P.S. Cheti geschaffen. Obwohl er diesen Ansatz ausdrücklich neben andere Ansätze (Hierarchiemodell, Netz(werk)modell und Relationenmodell) stellte, gilt das ERM heute als das generelle Beschreibungsmittel für logische Datenstrukturen, das in Details immer wieder durch Weiterentwicklungen ergänzt wird. Methodische Basis ist das Relationenmodell. In der Praxis hat das ERM weite Verbreitung gefunden. Das wichtigste Instrument zur Implementierung von Entity-Relationship-Modellen sind relationale Datenbank(management)systeme (abgekürzt: RDBMS); CASE-Werkzeuge erlauben die weitgehend automatische Transformation eines ERM in das Schema eines RDBMS. Einschränkungen bestehen, da die Semantik eines ERM nicht immer vollständig im RDBMS abgebildet werden kann (z.B. die Kardinalität der Beziehungen und die Definition von Wertebereichen der Attribute). Dieser Verlust an Semantik macht die Rücktransformation eines ERM aus einem RDBMS unmöglich. Die Relationen im RDBMS haben eine andere Struktur als die Relationen im ERM. Der Bruch zwischen ERM und RDBMS kann durch Normalisierung (vgl. Lerneinheit NORMA) vergrößert werden. Grundmodell des ERM Im ERM wird zwischen den Elementen Entität, Attribut und Beziehung unterschieden. Eine Entität ist ein individuelles Exemplar der realen Welt oder der Vorstellungswelt des Menschen oder eine Beziehung zwischen zwei Entitäten, wenn diese eine Bedeutung hat. Entitäten mit gleichen Attributen werden zum Entitätstyp (auch: Entitätsmenge) verallgemeinert. Ein Attribut ist die Beschreibung einer Eigenschaft eines Entitätstyps; ein Attribut definiert auch die Funktion, die ihr Wertebereich in der Beschreibung des Entitätstyps hat. Unter Wertebereich wird die Menge der Werte ("Attributwert"), die ein Attribut annehmen kann (z.B. alle Wochentage beim Attribut Wochentag), verstanden. Ein Attribut kann einfaches Attribut oder zusammengesetztes Attribut sein. Ein zusammengesetztes Attribut besteht aus mehreren einfachen Attributen (z.B. ist das Attribut "Fremdsprachenkenntnisse" ein zusammengesetztes Attribut, wenn es aus den einfachen Attributen "Fremdsprachen" und "Kenntnisstand" besteht). Die Entscheidung, ob ein bestimmtes Phänomen des modellierten Ausschnitts der Wirklichkeit Entität oder Attribut ist, hängt von der konkreten Anwendungsaufgabe ab. Ein bestimmtes Phänomen kann also im Zusammenhang mit einer be-

ERMOD - Entity-Relationship-Modell

121

stimmten Anwendungsaufgabe Entität, im Zusammenhang mit einer anderen Anwendungsaufgabe Attribut sein. Folgende Regeln sollten beachtet werden: • Ein Phänomen, für das nur ein identifizierendes Merkmal bekannt ist, wird als Attribut modelliert; sind weitere beschreibende Merkmale bekannt, wird es als Entität bzw. Entitätstyp dargestellt. Beispiel: Werden zu Städten neben ihrem Namen weitere Merkmale benötigt, dann ist STADT ein eigener Entitätstyp. • Gibt es zu einem beschreibenden Merkmal mehrere Werte, dann wird es als Entitätstyp modelliert, auch wenn dieser keine weiteren Merkmale aufweist. Beispiel: Ein EINZELHÄNDLER hat in mehreren Städten Filialen; das Merkmal STADT wird als Entitätstyp modelliert, und ein Beziehungstyp zwischen den Entitätstypen EINZELHÄNDLER und STADT wird eingeführt. • Weist ein beschreibendes Merkmal eine n:l- bzw. eine 1 :n-Beziehung zu einem Entitätstyp auf, so wird es als Entitätstyp modelliert, auch wenn dieser keine weiteren Merkmale aufweist. Beispiel: Es werden die Entitätstypen BUNDESLAND und EINZELHÄNDLER modelliert, und das Merkmal Stadt des Entitätstyps EINZELHÄNDLER weist eine n:l-Beziehung zum Entitätstyp BUNDESLAND auf. STADT wird daher als Entitätstyp modelliert. • Merkmale werden dem Objekttyp zugeordnet, den sie am zutreffendsten beschreiben. Beispiel: Es werden die Entitätstypen ABTEILUNG und ANGESTELLTE modelliert; das Merkmal Gebäude wird dem Entitätstyp ABTEILUNG und nicht dem Entitätstyp ANGESTELLTE zugeordnet. • Aus mehreren Merkmalen zusammengesetzte Schlüssel sind möglichst zu vermeiden. Eine Beziehung ist die logische Verbindung zwischen mehreren Entitätstypen; sie wird auch als Beziehungstyp (auch: Assoziationstyp) bezeichnet. Anhaltspunkt dafür, was Entitätstyp und was Beziehungstyp ist, ist die Verwendung von Substantiven bzw. von Verben in der fachsprachlichen Beschreibung der Anwendungsaufgabe. Entitätstypen werden in der Regel mit Substantiven (z.B. Lieferant, Kunde, Mitarbeiter), Beziehungstypen mit Verben (z.B. liefert, bestellt, ist zugeordnet) bezeichnet. Einem Entitätstyp müssen, einem Beziehungstyp können Attribute zugeordnet sein. Jedes Attribut wird genau einem Entitätstyp oder einem Beziehungstyp zugeordnet. Folgende Regeln sollten beachtet werden: • Redundante Beziehungen werden eliminiert; transitive Beziehungen sind redundante Beziehungen. Beispiel: Es werden die Entitätstypen STUDENT und FAKULTÄT mit der Beziehung ist _Hörer sowie FAKULTÄT und UNIVERSITÄT mit der Beziehung gehört _zu modelliert; die Beziehung besucht zwischen STUDENT und UNIVERSITÄT ist redundant unter der Voraussetzung, daß die beiden anderen Beziehungen zwingend sind. • Ternäre Beziehungen werden nur dann modelliert, wenn binäre Beziehungen nicht möglich sind. Die Darstellung eines Entitätstyps im ERM erfolgt durch ein Rechteck, die eines Beziehungstyps durch eine Raute. Die Bezeichnung von Entitätstyp und Beziehungstyp wird GROSS geschrieben und in die grafischen Symbole gesetzt. Entitätstypen werden durch Linien verbunden, in welche die Beziehungstypen eingefügt werden. Angenommen, LIEFERANT und ARTIKEL sind Entitätstypen; ein Beziehungstyp könnte dann LIEFERN heißen. Abbildung ERMOD-1 zeigt diese

122

Methoden und Techniken der Grobprojektierung

Datenstruktur als ERM. Bei der Interpretation einer derartigen Abbildung wird eine bestimmte "Leserichtung" als richtig vorausgesetzt, im Beispiel: "Lieferanten liefern Artikel" und nicht "Artikel liefern Lieferanten".

Abb. ERMOD-1: Darstellung der Datenstruktur im ERM

Beziehungen von der folgenden Art können im ERM dargestelllt werden: 1:1-, l:n-, m:l- und m:n-Beziehung (auch: elementare Kardinalitäten). • l:l-Beziehung: Jeder Entität der Entitätsmenge EMI wird genau eine Entität der Entitätsmenge EM2 zugeordnet ("eins-zu-eins"). • l:n-Beziehung: Jeder Entität der Entitätsmenge EMI werden n Entitäten der Entitätsmenge EM2 zugeordnet; jeder Entität der Entitätsmenge EM2 wird genau eine Entität der Entitätsmenge EMI zugeordnet ("eins-zu-viele"). • m:l-Beziehung: wie 1 :n-Beziehung, aber in umgekehrter Richtung. • m:n-Beziehung: Einer Entität der Entitätsmenge EMI werden mehrere Entitäten der Entitätsmenge EM2 zugeordnet und umgekehrt ("viele-zu-viele").

® EMI

== j.J

l:n

®

EM2

Abbildung ERMOD-2 veranschaulicht die Beziehungstypen grafisch (die m:l-Beziehung ist aus der 1 :n-Beziehung ersichtlich und daher nicht dargestellt). Die Beziehungen werden an die Kanten des ERM geschrieben. Einer Kante kann alternativ zur Raute - ein Rollenname zugeordnet sein, der die Funktion des Entitätstyps in bezug auf den Beziehungstyp beschreibt (vgl. die Abbildungen ERMOD-5 und ERMOD-6). Den Entitätstypen und den Beziehungstypen werden Attribute zugeordnet. Die Wertebereiche der Attribute ("Domänen") sind Mengen; sie werden im ERM durch Kreise (oder Ellipsen) dargestellt. Die Bezeichnung der Elemente einer Domäne wird in den Kreis geschrieben. Die Zuordnung zwischen einem Entitätstyp bzw. einem Beziehungstyp einerseits und den Domänen andererseits wird im ERM als Linie (als ungerichtete Kante) dargestellt; die Bezeichnung des Attributs wird an die Linie geschrieben. Parallele Kanten zwischen einem Entitätstyp und einem Beziehungstyp sind zulässig; sie symbolisieren eine rekursive Beziehung (z.B. bei einer Stückliste zwischen dem Entitätstyp

ERMOD - Entity-Relationship-Modell

123

TEIL und dem Beziehungstyp STRUKTUR, weil die Struktur aus Teilen besteht und die Teile in der Struktur verwendet werden). Abbildung ERMOD-3 zeigt die in Abbildung ERMOD-1 verwendete Datenstruktur, verfeinert durch die Angabe der Attribute und ihrer Domänen sowie der Beziehungstypen. Zwischen einem Entitätstyp und mindestens einer Domäne muß eine kl-Beziehung bestehen, da jeder Wert der Domäne genau eine Entität identifizieren muß ("Schlüsselattribut"). In Abbildung ERMOD-3 sind die Lieferantennummer und die Artikelnummer die beiden Schlüsselattribute. Das Identifizieren der Beziehungstypen erfolgt durch ein komplexes Schlüsselattribut, das aus zwei (einfachen) Schlüsselattributen zusammengesetzt ist, im Beispiel der Abbildung ERMOD-3 durch Lieferantennummer und Artikelnummer.

Abb. ERMOD-3: Zuordnung von Attributen und Domänen im ERM

Das ERM unterstützt einen Top-down-Ansatz bei der Datenmodellierung. Zunächst werden die Entitätstypen modelliert und dann in Beziehung gesetzt; nichthierarchische Beziehungen werden in hierarchische Beziehungen aufgelöst. Im nächsten Schritt werden den Entitätstypen und den Beziehungstypen die Attribute zugeordnet. In großen ER-Diagrammen wird aus Gründen der Übersichtlichkeit auf die Darstellung der Attribute verzichtet. Dieses Vorgehen führt im allgemeinen zu einem Schema in der dritten Normalform (vgl. Lerneinheit NORMA). Erweiterungen des Grundmodells Das Grundmodell des ERM unterstützt von den Konstruktoperatoren des Begriffskalküls (vgl. Lerneinheit OBTYP) lediglich die Aggregation durch die Bildung des 1 :n-Beziehungstyps. Die Inklusion (Generalisierung und Spezialisierung) wird durch eine neue Art von Beziehungstyp berücksichtigt. Im Unterschied zum normalen Beziehungstyp, der als Raute dargestellt wird, wird er als Dreieck modelliert. Abbildung ERMOD-4 (linker Teil) zeigt eine Erweiterung der in Abbildung ERMOD-3 dargestellten Datenstruktur durch Einführung des neuen Beziehungstyps. Die Inklusion wird im Beispiel durch die Typ-Unterscheidung von GESCHÄFTSPARTNER als KUNDE und LIEFERANT ausgedrückt. Aus Gründen der Übersichtlichkeit kann für die Inklusion eine Darstellungsform verwendet werden, wie sie in Abbildung ERMOD-4 (rechter Teil) gezeigt wird ("IS_A"-Darstellung). Es ist also möglich, drei Konstruktoperatoren (Aggregation, Generalisierung und Spezialisierung) im ERM zu berücksichtigen.

124

Methoden und Techniken der Grobprojektierung

Abb. ERMOD-4: Inklusion im ERM

Eine l:n-Beziehung - wie die zwischen Lieferant und Artikel in Abbildung ERMOD-3 - sagt nichts darüber aus, ob jeder Lieferant wenigstens einen Artikel liefert. Umgekehrt ist aus der Darstellung nicht ersichtlich, ob Artikel, die bei keinem Lieferanten bestellt sind, auftreten können. Durch Angabe von Ober- und Untergrenzen der Anzahl der Beziehungsausprägungen ("Komplexitätsgrad") kann ein Beziehungstyp präzisiert werden. Beispielsweise wird durch das Buchstabenpaar (a,b), das an einen Beziehungstyp AB angeschrieben wird, angegeben, daß jede Entität der Entitätsmenge A an mindestens a, höchstens b Beziehungsausprägungen vom Beziehungstyp AB beteiligt ist. Ist der Komplexitätsgrad zwischen LIEFERANT und ARTIKEL (l,n), werden Lieferantendaten nur dann gespeichert, wenn beim Lieferanten mindestens ein Artikel bestellt ist. Sollen Lieferantendaten auch dann gespeichert werden, wenn keine Bestellung vorliegt, ist der Komplexitätsgrad (0,n). Diese Notation heißt (min,max)-Notation. Demonstrationsbeispiel Am Beispiel des Schlüsselkonzepts wird eine mögliche Erweiterung des ERM gezeigt. Die allgemeine Bedeutung von "Schlüssel" ist, daß er eine Entität eindeutig identifiziert. Eine darüber hinausgehende Bedeutung hat "Schlüssel" bei der Konstruktion von Entitätstypen, indem er hilft, deutlich zu machen, welche semantische Bedeutung ein Entitätstyp hat. Die Bezeichnung des Entitätstyps reicht dazu im allgemeinen nicht aus. Eine verbale Erläuterung führt nicht weiter, weil sie mehrdeutig sein kann und nicht Bestandteil des ERM wäre (sondern nur einer "Dokumentation am Rande"). Häufig wird die Bedeutung eines Entitätstyps erst in Verbindung mit anderen Entitätstypen klar. Schlüssel, die Beziehungen zu anderen Entitätstypen enthalten dürfen, helfen, die semantische Bedeutung von Entitätstypen zu klären. Dies schließt nicht aus, daß eindeutige Entitätstypen im ERM vorhanden sind, deren Schlüssel keine Beziehungen enthalten (z.B. identifizierende Nummern wie PERSONAL-# und ARTIKEL-#). Schlüssel dürfen, müssen aber keine Beziehungen enthalten. Gegeben sei das in Abbildung ERMOD-5 gezeigte Beispiel. Die Information darüber, an welchem Wochentag und um welche Uhrzeit ein Kurs in welchem Raum stattfindet, soll zusätzlich modelliert werden. Da es sich dabei zunächst um nicht sichtbare Attribute handelt, muß die m:n-Beziehung zwischen KURS und RAUM aufgelöst werden; dies zeigt im Ergebnis Abbildung ERMOD-6. Die Attribute "Wochentag" und "Uhrzeit" sind nun beschreibende Attribute des neuen Entitäts-

ERMOD - Entity-Relationship-Madelt 125 typs KURS-TERMIN, dessen Schlüssel aus den beiden Beziehungen "gehört zu Kurs" und "findet statt in - Raum" besteht.

Abb. ERMOD-5: Erster ERM-Entwurf

Die Überprüfung des neuen Entitätstyps zeigt, daß die Wirklichkeit nicht richtig abgebildet wurde: Der Zeitpunkt (Wochentag und Uhrzeit) von KURS-TERMIN hängt nicht vom Kurs und vom Raum ab, sondern umgekehrt: Vom Kurs und vom Zeitpunkt hängt es ab, in welchem Raum ein KURS-TERMIN stattfindet. Beispiel: Der Kurs "Controlling" kann im Raum "Hörsaal MZ 17" dienstags um 11 Uhr und freitags um 13 Uhr beginnen. Umgekehrt, will jemand den Kurs "Controlling" besuchen und es ist Freitag 13 Uhr, so erfahrt er eindeutig, daß er in den Raum "Hörsaal MZ 17" gehen muß. Ein Schlüssel für KURS-TERMIN, der dies abbildet, lautet: "... gehört zu - Kurs", "Wochentag" und "Uhrzeit"; er enthält eine Beziehung und zwei Attribute. Die Beziehung "Kurs-Termin - findet statt in - Raum" wird zur Nicht-Schlüssel-Beziehung.

Abb. ERMOD-6: Verbesserter ERM-Entwurf

Statt "... gehört zu - Kurs", "Wochentag" und "Uhrzeit" hätte auch "... findet statt in - Raum", "Wochentag" und "Uhrzeit" als Schlüssel für KURS-TERMIN gewählt werden können. Dies zeigt, daß es für die Abbildung eines bestimmten Sachverhalts mehrere Attribut/Beziehung-Kombinationen geben kann. Im Beispiel ist die erste Variante aussagefahiger, wenn die Information über Kurse im Vordergrund stehen soll; soll die Information über Räume im Vordergrund stehen, ist die zweite Variante aussagefähiger. Das Beispiel zeigt auch, daß die zunächst verwendete m:n-Beziehung zwischen KURS und RAUM den in der Wirklichkeit bestehenden Zusammenhang zwischen Kursen, Räumen, Zeitpunkten und Kursterminen nicht zum Ausdruck bringen konnte. Aufgabenverweise Entwerfen des Datensystems (Lerneinheit WDASY).

126

Methoden und Techniken der Grobprojektierung

Kontrollfragen 1. Welchem Zweck dient das Entity-Relationship-Modell? 2. Welche Darstellungsmittel werden im Entity-Relationship-Modell verwendet? 3. Welche Konstruktoperatoren des Begriffskalküls können im Entity-Relationship-Modell berücksichtigt werden? 4. Was wird durch den "Komplexitätsgrad" im Entity-Relationship-Modell abgebildet? 5. Welchen Nutzen hat das erweiterte Schlüsselkonzept?

Quellenliteratur Chen, P. P.-S.: The Entity-Relationship Model: Towards a Unified View of Data. In: ACM Transactions on Database-Systems, 1/1976,9-36 Rauh, O.: Überlegungen zur Behandlung ableitbarer Daten im Entity-Relationship-Modell (ERM). In: WIRTSCHAFTSINFORMATIK 3/1992, 294 - 306 Schrefl, M.: Grundlagen von Datenbanksystemen. Vorlesungsunterlagen WS 1993/94, Institut für Wirtschaftsinformatik/Data & Knowledge Engineering, Linz 1993

Vertiefungsliteratur Chen, P. P.-S. (Ed.): Entity-Relationship Approach to Information Modeling and Analysis. Proc. of the 2nd International Conference on Entity-Relationship Approach (1981). Amsterdam et al. 1983 Ritterbach, B.: Ein Schlüsselkonzept für das ER-Modell - Praktische Konsequenzen für die Modellierung und Toolunterstützung. Unveröffentlichtes Manuskript, Hamburg 1993 Sinz, E. J.: Das Entity-Relationship-Modell (ERM) und seine Erweiterungen. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 152/1990, 17 - 29

NORMA - Normalformenlehre Lernziele Sie kennen die als Normalformenlehre oder als Normalisierung bezeichnete Vorgehensweise, mit der Datenredundanz in logischen Datenmodellen beseitigt werden kann. Sie können die erste, die zweite und die dritte Normalform mit eigenen Worten erläutern. Sie kennen den Zusammenhang, der zwischen der Normalisierung und dem logischen Datenentwurf mit dem Entity-Relationship-Modell besteht. Sie können die Normalformenlehre auf praktische Beispiele anwenden. Definitionen und Abkürzungen INF = Akronym für erste Normalform. 2NF - Akronym für zweite Normalform. 3NF = Akronym für dritte Normalform. Anomalie (anomaly) = ein durch die Speicheroperationen Löschen, Ändern, und/oder Einfügen bewirkter Zustand einer Relation, der mit der Wirklichkeit nicht übereinstimmt. Synonym: Speicheranomalie. Datenredundanz (data redundancy) = das mehrmalige Vorhandensein eines Attributs in einer Relation oder in mehreren Relationen einer Datenbasis. Fremdschlüssel (alteraate key) = ein Attribut oder eine Kombination von Attributen, das bzw. die in wenigstens einer anderen Relation ein Primärschlüssel ist. Synonym: Sekundärschlüssel. Mutationsanomalie (update anomaly) = das Nicht-Mutieren von redundant gespeicherten Daten bei einer Mutation. Normalform (normal form) = ein definierter Zustand einer Relation im Normalisierungsprozeß bezüglich ihrer Eigenschaft, Datenredundanz zu enthalten und zu Speicheranomalie zu führen. Normalformenlehre (normal form procedure) = die systematische, bestimmten "Gesetzmäßigkeiten" ("Normalisierungsregeln") folgende Vorgehensweise bei der Beseitigung von Datenredundanz in einem logischen Datenmodell. Synonym: Normalisierung. Normalisierungsregel (normalizing rule) = eine Regel, die angibt, durch welche Maßnahmen eine Ausgangsrelation in eine INF-Relation, eine 1 NF-Relation in eine 2NF-Relation usw. überführt werden. Primärschlüssel (primary key) = ein Attribut oder die minimale Kombination von Attributen, dessen bzw. deren Wert jedes Tupel einer Relation eindeutig identifiziert. Synonym: Identifikationsschlüssel. Relation (relation) = eine Menge von Entitäten (Tupeln), für die gilt, daß jede Entität (jedes Tupel) aus der gleichen Menge von Attributen besteht. Relationenmodell (relation model) = ein Beschreibungsmittel für logische Datenstrukturen, das die Tabelle als Darstellungsmittel verwendet. Schlüsselattribut (key attribute) = ein Attribut, das in einer Relation als Schlüssel verwendet wird; sonst ist es Nichtschlüssel-Attribut. Tabelle (table) = die Darstellung von Daten in Zeilen und Spalten, transitiv (transitive) = eine Beziehung, die auf jeden Fall zwischen x und z besteht, wenn sie zwischen x und y sowie zwischen y und z besteht.

128

Methoden und Techniken der Grobprojektierung

Zweck der Normalformenlehre Zweck der Normalisierung ist es, die in einem logischen Datenmodell (vgl. Lerneinheit WDASY) formulierten Relationen so zu überarbeiten, daß Datenredundanz beseitigt wird und Mutationsanomalien vermieden werden. Der Prozeß der Überarbeitung soll gewissen "Gesetzmäßigkeiten" ("Normalisierungsregeln") folgen, die in der Normalformenlehre formuliert sind. Die Normalformenlehre geht auf E. F. Codd zurück und ist eng mit dem von ihm entwickelten Relationenmodell verbunden. Unterschieden werden zumindest drei Zustände im Normalisierungsprozeß ("Normalformen"), die erste Normalform (abgekürzt: INF), die zweite Normalform (abgekürzt: 2NF) und die dritte Normalform (abgekürzt: 3NF). Erweiterungen hinsichtlich optimaler dritter Normalformen und weitere Normalformen (4NF und 5NF) wurden vorgeschlagen, sind aber nur von geringer praktischer Bedeutung. Im folgenden wird daher nur auf die INF, 2NF und 3NF eingegangen. Der Zusammenhang zwischen den Normalformen kann grafisch, wie in Abbildung NORMA-1 gezeigt, als sich umschließende Rechtecke veranschaulicht werden. Damit kommt zum Ausdruck, daß jede betrachtete Normalform die Eigenschaften aller unteren Normalformen einschließt bzw. daß die Relationen eines logischen Datenmodells, welche die Bedingungen einer bestimmten Normalform erfüllen, auch alle Bedingungen der unteren Normalformen erfüllen. usw. 3 NF Relation 2NF Relation INF Relation Abb. NORMA-1: Zusammenhang zwischen den Normalformen

Wenn bei der Definition einer Relation alle Normalisierungsregeln beachtet wurden, wird sie als voll normalisierte Relation bezeichnet. Da sich die Praxis mit der 3NF zufrieden gibt, werden Relationen in der 3NF als voll normalisiert bezeichnet. Bei einer korrekten Durchführung des Normalisierungsprozesses hat eine Relation immer den gleichen Informationsgehalt, unabhängig davon, in welcher Normalform sie sich befindet. Volle Normalisierung versus teilweise Normalisierung Gegen eine volle Normalisierung wird erstens eingewendet, daß sie im internen Schema mehr Speicherplatz erfordert als eine teilweise Normalisierung; eine logische oder empirische Bestätigung dieser Aussage liegt nicht vor. Zweitens wird behauptet, daß der Aufwand für die Datenmanipulation bei voller Normalisierung höher ist als bei teilweiser Normalisierung. Diese Aussage ist dann zutreffend, wenn von der Annahme ausgegangen wird, daß das verwendete Datenverwaltungssystem nicht über Funktionen verfügt, welche die Zusammenfassung mehrerer Relationen zu einer Benutzersicht ermöglichen. Verfügt das Datenverwaltungssystem über derartige Funktionen, dann kann der Benutzer mit

NORMA- Normalformenlehre

129

einer INF-Relation arbeiten, während für die physische Speicherung der Daten im internen Schema voll normalisierte Relationen verwendet werden. Drittens wird behauptet, daß die Verwendung voll normalisierter Relationen zu einem höheren Betriebsmittelverbrauch führt. Diese Behauptung ist zutreffend, da die Bereitstellung einer Benutzersicht zur Ausführungszeit erfolgt und dafür Betriebsmittel erforderlich sind. Angesichts der Vorteile einer vollen Normalisierung (insbes. Redundanzfreiheit und damit die Vermeidung von Speicheranomalien) ist dieses Argument ohne praktische Bedeutung. Nicht-normalisierte

Relationen

Kennzeichen einer nicht-normalisierten (auch: unnormalisierten) Relation ist, daß Mengen als Attributwerte zulässig sind; am Kreuzungspunkt zwischen einer Zeile (Tupel) und einer Spalte (Attribut) einer Relation kann es also zwei und mehr Attributwerte geben. Umgekehrt formuliert: Enthält eine Relation mindestens ein Tupel mit zwei oder mehr Werten zu einem Attribut, dann handelt es sich um eine nicht-normalisierte Relation. Die Nachteile einer nicht-normalisierten Relation sind: • Ihre Manipulation ist umständlicher als die einer normalisierten Relation; die erforderliche Datenmanipulationssprache ist komplizierter. • Sie ist in der Regel redundant; Datenredundanz verursacht mehr Speicherbedarf und kann zu Anomalien durch Speicheroperationen führen. Anomalien durch Speicheroperationen bei nicht-normalisierten Relationen können durch aufwendige Prüfprogramme verhindert werden. Es ist einfacher, statt der Prüfprogramme normalisierte Relationen zu verwenden. Anmerkung: Genau genommen sind die Bezeichnungen nicht-normalisierte Relation und unnormalisierte Relation unzutreffend, weil die Darstellung eines Datenobjekts in Form einer Tabelle voraussetzt, daß die Relation normalisiert ist. Im folgenden werden daher diese Bezeichnungen in "..." geschrieben. Erste Normalform Kennzeichen einer in der ersten Normalform befindlichen Relation ist, daß sie nur einfache Attributwerte enthält (auch als "atomare Werte" bezeichnet); am Kreuzungspunkt zwischen einer Zeile (Tupel) und einer Spalte (Attribut) einer Relation gibt es nur ein Element (Attributwert). Die Attribute einer lNF-Relation dürfen also selbst keine Relationen, das heißt keine mehrwertigen Mengen sein. Zur Herstellung der ersten Normalform wird jede Zeile, die mehrwertige Mengen enthält, in so viele Zeilen transformiert, daß jede Zeile nur einwertige Mengen enthält. Mit der ersten Normalform werden zwar variable Satzlängen vermieden, nicht jedoch Anomalien bei Speicheroperationen. Zweite Normalform Kennzeichen einer in der zweiten Normalform befindlichen Relation ist, daß neben den Bedingungen der ersten Normalform alle Nichtschlüssel-Attribute vom Primärschlüssel voll funktional abhängig sind. "Voll funktional abhängig" ist dabei wie folgt definiert: Ein Attribut B ist von einem Primärschlüssel (Attri-

130

Methoden und Techniken der Grobprojektierung

but A) voll funktional abhängig, wenn von jedem Attributwert A direkt auf den Attributwert B geschlossen werden kann. Mit anderen Worten: Es darf in einer 2NF-Relation keine Nichtschlüssel-Attribute geben, die von anderen Attributen als dem Primärschlüssel voll funktional abhängig sind. Solche Abhängigkeiten werden am besten dadurch erkannt, daß die 1 NF-Relation grafisch dargestellt wird, wobei die funktionalen Beziehungen zwischen den Attributen durch einfache gerichtete Pfeile dargestellt werden, die (zulässige) volle funktionale Abhängigkeit zwischen dem Primärschlüssel und den von ihm abhängigen Nichtschlüssel-Attributen durch Doppelpfeile. Die zweite Normalform wird dadurch hergestellt, daß die INF-Relation in mehrere Relationen zerlegt wird; die Attribute, die von Teilschlüsseln funktional abhängig sind, werden zusammen mit diesen Teilschlüsseln in eigenen Relationen zusammengefaßt. Eine 2NF-Relation stellt, bezüglich der möglichen Anomalien, gegenüber einer INF-Relation eine wesentliche Verbesserung dar. Die entstehenden (zwei oder mehr) 2NF-Relationen haben den gleichen Informationsgehalt wie die INF-Relation, aus der sie gebildet wurden. Das heißt unter anderem, daß die ursprüngliche INF-Relation aus den entstandenen Relationen durch Verbundoperationen wiederhergestellt werden kann. Verbundoperationen sind möglich, weil in den entstandenen 2NF-Relationen gleiche Attribute wie in der INF-Relation als Schlüssel bzw. als Teilschlüssel verwendet werden. Dies führt zur Unterscheidung zwischen Primärschlüssel und Fremdschlüssel. Ein Schlüsselattribut ist ein Fremdschlüssel (auch: Sekundärschlüssel) einer Relation, wenn es in dieser Relation kein Primärschlüssel ist, in einer anderen Relation aber als Primärschlüssel auftritt. Die Tupel einer Relation mit einem Fremdschlüssel stehen also mit (in der Regel mehreren) Tupeln einer Relation mit dem Primärschlüssel in einer l:n-Beziehung; die einfache Assoziation (Typ 1) zeigt von der Relation mit dem Fremdschlüssel zur Relation mit dem Primärschlüssel, während von der Relation mit dem Primärschlüssel zur Relation mit dem Fremdschlüssel eine komplexe Assoziation (Typ n) vorliegt. Dritte Normalform Kennzeichen einer in der dritten Normalform befindlichen Relation ist, daß sie sich in der zweiten Normalform befindet und daß zwischen den Attributen, die nicht Primärschlüssel-Attribute sind, keine funktionalen Abhängigkeiten bestehen. Mit anderen Worten: Eine Relation ist in der dritten Normalform, wenn sie in der zweiten Normalform ist und keine transitiven Abhängigkeiten enthält. Attribut C ist transitiv abhängig von Attribut A, wenn Attribut B von Attribut A funktional abhängig ist und Attribut C funktional abhängig ist von Attribut B. Die dritte Normalform kann nur dann verletzt werden, wenn eine Relation neben dem Primärschlüssel mindestens zwei weitere Attribute enthält. Verletzt eine Relation die dritte Normalform, dann muß das transitiv abhängige Attribut aus der Relation entfernt werden; die 2NF-Relation wird dadurch in zwei oder mehr 3NF-Relationen aufgespalten. Bei diesem Vorgang ist darauf zu achten, daß keine Relationen mit Attributen entstehen, die in der ursprünglichen Relation transitiv voneinander abhängig sind. Im allgemeinen kann davon ausgegangen werden, daß

NORMA- Normalformenlehre

131

eine 3NF-Relation keine Datenredundanz aufweist und damit keine Anomalien bei Speicheroperationen auftreten. Grundsätzlich ist es aber möglich, Relationen zu definieren, die sich in der dritten Normalform befinden und trotzdem zu Anomalien bei Speicheroperationen führen. Dies führt - durch Optimierung der dritten Normalform - zur vierten Normalform und von dort gegebenenfalls weiter zur fünften Normalform (die hier nicht betrachtet werden). Kritische Würdigung Wesentlicher Kritikpunkt an der Normalisierung ist, daß lediglich bei der Formulierung der Ausgangsrelationen der dem zu modellierenden Ausschnitt der Wirklichkeit zugrundeliegende Informationsgehalt berücksichtigt wird. Dieser Ausschnitt der Wirklichkeit wird einem formalen Verfahren unterworfen, das lediglich die Erhaltung des Informationsgehalts sichert. Die Zwischenergebnisse und das Ergebnis des Normalisierungsprozesses werden nicht an der Wirklichkeit überprüft. Deshalb ist eine Kombination des Normalisierungsverfahrens mit dem ERM-Ansatz (vgl. Lerneinheit ERMOD) erforderlich, die wie folgt aussieht: Es wird zunächst eine Datenstruktur mit dem ERM-Ansatz entworfen. Dabei stehen die Entitätstypen und die Beziehungstypen im Vordergrund. Die Attribute werden anfangs nur pauschal betrachtet, das heißt, es werden nur die wichtigsten Attribute festgehalten. Bei der anschließenden Verfeinerung der Attribute können "nicht-normalisierte" Relationen auftreten. Zu ihrer Aufdeckung wird das Normalisierungsverfahren angewendet. Dadurch können neue Relationen (Entitätstypen und Beziehungstypen) entstehen, die in das ERM eingebaut werden. Relation DOZENT DOZ_#

DOZ_NAME DOZ_ORT

INST_#

INST_NAME

2345

Sammer

Linz

3020

WIN

2747

Maier

Wien

3711

BWL

2876

Schulz

Linz

3020

WIN

HÖR_#

HÖR_NAME HÖR_ORT

KUR_NAME KUR_DAUER

4523

Schober

Enns

Buchhaltung

4

4727

Heinrich

Linz

4876

Mayr

Salzburg

Controlling, Buchhaltung Marketing

4, 4 2

Abb. NORMA-2: Ausgangsrelation ("nicht-normalisierte" Relation)

132

Methoden und Techniken der Grobprojektierung

Demonstrationsbeispiel Gegeben ist die in Abbildung NORMA-2 gezeigte Relation DOZENT mit den Attributen DOZ #. DOZ_NAME, DOZ_ORT, INST_#, INST_NAME, HÖR_#, HÖR_NAME, HÖR_ORT, KUR.NAME, KUR_DAUER (sie wurde nur aus Platzgründen in zwei Teilen untereinander geschrieben). Relation DOZENT beschreibt folgenden Ausschnitt der Wirklichkeit: Ein Dozent wird durch eine Nummer (DOZ_#) identifiziert und hat die Attribute Name (DOZ_NAME) und Wohnort (DOZ_ORT). Jeder Dozent ist an genau einem Institut tätig. Ein Institut wird durch die Attribute Institutsnummer (INST_#) und Institutsname (INST_NAME) beschrieben. Jeder Dozent unterrichtet in mehreren Kursen (KUR_NAME) mit einer bestimmten Kursdauer (KUR_DAUER) Hörer, die durch die Attribute Nummer (HÖR_#), Name (HÖR_NAME) und Wohnort (HÖR_ORT) beschrieben sind. Die Relation ist "unnormalisiert", weil das Tupel 2747 bezüglich der Attribute KUR_NAME und KUR_DAUER jeweils zwei Werte (Buchhaltung und Controlling bzw. 4 und 4) besitzt. Die Überführung der Relation DOZENT in eine INF-Relation erfolgt dadurch, daß die mehrfachen Werte des Tupels 2747 bezüglich der genannten Attribute in einfache Werte in zwei Tupeln überführt werden. Im Beispiel entsteht durch diese Transformation ein zweites Tupel 2747 (die eingefügten Werte sind in Abbildung NORMA-3 fett gedruckt). DOZ_# ist nun kein Primärschlüssel mehr, sodaß ein neuer, aus mehreren Attributen zusammengesetzter Primärschlüssel gebildet werden muß. Mit DOZ_#, HÖR_# und KUR_NAME kann jedes Tupel der Relation DOZENT INF identifiziert werden. Relation DOZENT INF DOZ_# 2345 2747 2747 2876 HÖR_# 4523 4727 4727 4876

DOZ_NAME DOZ_ORT Sammer Maier Maier Schulz HÖR_NAME Schober Heinrich Heinrich Mayr

Linz Wien Wien Linz

INST_# 3020 3711 3711 3020

INSTJSTAME WIN BWL BWL WIN

HÖR_ORT KUR_NAME KURJDAUER Enns Linz Linz Salzburg

Buchhaltung Controlling Buchhaltung Marketing

4 4 4 2

Abb. NORMA-3: Relation in INF

Mit der Relation DOZENT INF werden Speichersätze unterschiedlicher Länge vermieden, nicht jedoch Speicheranomalien. Eine Änderungsanomalie kann z.B. dadurch entstehen, daß der Wohnort "Wien" des Dozenten "Maier" zweimal vorkommt. Ändert sich der Wohnort des Dozenten Maier, muß die gesamte Relation durchsucht und der Wert zweimal geändert werden. Eine Einfügeanomalie kann sich z.B. dadurch ergeben, daß in die Relation DOZENT INF kein

NORMA-Normalformenlehre

133

Hörer aufgenommen werden kann, solange kein Dozent für ihn bekannt ist. Eine Löschanomalie ergibt sich z.B. dann, wenn Hörer Heinrich den Kurs Buchhaltung beendet hat, da beim Löschen des Tupels 2876 auch sämtliche Daten über den Dozenten Schulz entfernt werden, was offenbar nicht der Wirklichkeit entspricht und daher nicht beabsichtigt sein kann. Zur Transformation der Relation DOZENT INF in die zweite Normalform wird zunächst untersucht, welche Nichtschlüssel-Attribute von welchen Teilen des Primärschlüssels voll funktional abhängig sind. In der Relation DOZENT INF: • sind die Nichtschlüssel-Attribute DOZ_NAME, DOZ_ORT, INST_# und INST_NAME voll funktional abhängig vom Teilschlüssel-Attribut DOZ_#; • sind die Nichtschlüssel-Attribute HÖR_NAME und HÖR_ORT voll funktional abhängig vom Teilschlüssel-Attribut HÖR_#; • ist das Nichtschlüssel-Attribut KUR_DAUER voll funktional abhängig vom Teilschlüssel-Attribut KUR_NAME. Relation DOZENT 2NF DOZ_#

DOZ_NAME DOZ_ORT

INST_#

INST_NAME

2345

Sammer

Linz

3020

WIN

2747

Maier

Wien

3711

BWL

2876

Schulz

Linz

3020

WIN

Relation KURS

Relation HÖRER HÖR_#

HÖR_NAME

HÖR_ORT

KUR_NAME KUR_DAUER

4523

Schober

Enns

Buchhaltung

4

4727

Heinrich

Linz

Controlling

4

4876

Mayr

Salzburg

Marketing

2

Relation DOZENT_HÖRER_KURS HÖRER_#

KURS_NAME

2345

4523

Buchhaltung

2747

4727

Controlling

2747

4876

Marketing

2876

4727

Buchhaltung

DOZ_#

Abb. NORMA-4: Relationen in 2NF

Die Relation DOZENT INF wird daher in die drei Relationen DOZENT 2NF, HÖRER und KURS aufgespalten, wobei die Attribute, die von den TeilschlüsselAttributen voll funktional abhängig sind, zusammen mit diesen Teilschlüsseln jeweils eine Relation bilden. Die Teilschlüssel werden in den neuen Relationen zu Primärschlüsseln. Die Teilschlüssel-Attribute verbleiben in der ursprünglichen, nun als DOZENT_HÖRER_KURS bezeichneten Relation als "Verbindungsglie-

134

Methoden und Techniken der Grobprojektierung

der" zu den abgespaltenen Relationen; sie werden als Fremdschlüssel bezeichnet. Abbildung NORMA-4 zeigt die Relation(en) in der zweiten Normalform. Die zweite Normalform zeigt im Vergleich zur ersten Normalform gegenüber möglichen Speicheranomalien eine wesentliche Verbesserung, vermag jedoch nicht alle Speicheranomalien auszuschließen. Auch in der Relation DOZENT 2NF können Anomalien durch Löschen auftreten, und bezüglich der Attributekombination INST_# und INST_NAME sind Anomalien durch Ändern und Einfügen möglich. So können z.B. Institutsnummern mit unterschiedlichen Institutsnamen in die Relation eingefügt werden. Zur Erreichung der dritten Normalform müssen die transitiven Abhängigkeiten zwischen Attributen einer Relation beseitigt werden. In der Relation DOZENT 2NF ist INST_NAME (Attribut C) transitiv abhängig von DOZ_# (Attribut A), weil INST_# (Attribut B) von DOZ_# funktional abhängig ist und INST_NAME von INST_# funktional abhängig ist. Transitiv abhängige Attribute müssen aus der Relation entfernt und zusammen mit den Attributen, von denen sie funktional abhängig sind, in eine eigene Relation aufgenommen werden, deren Primärschlüssel das die Transitivität determinierende Attribut (Attribut B, im Beispiel INST_#) wird. Dieses Attribut verbleibt auch in der ursprünglichen Relation und ist dort Fremdschlüssel. Im Beispiel wird daher die Relation INSTITUT gebildet (vgl. Abbildung NORMA-5; gegenüber Abbildung NORMA-4 sind die Relationen HÖRER, KURS und DOZENT_HÖRER_KURS unverändert und werden daher nicht noch einmal dargestellt). Relation DOZENT 3NF DOZ_#

Relation INSTITUT

DOZ_NAME DOZ.ORT

INST_#

INST_#

INST_NAME

2345

Sammer

Linz

3020

3020

WIN

2747

Maier

Wien

3711

3711

BWL

2876

Schulz

Linz

3020

Abb. NORMA-5: Relationen in 3NF

Aufgabenverweise Entwerfen des Datensystems (Lerneinheit WDASY).

Kontrollfragen 1. 2. 3. 4. 5.

Welcher Zweck wird mit der Normalisierung verfolgt? Welcher Zusammenhang besteht zwischen den Normalformen? Welche Nachteile haben nicht-normalisierte Relationen? Welche grundsätzliche Kritik kann gegen die Normalisierung vorgebracht werden? Wie werden Entity-Relationship-Modell und Normalformenlehre beim Entwerfen des Datensystems gemeinsam verwendet?

NORMA-Normalformenlehre

135

Quellenliteratur Vetter, M.: Aufbau betrieblicher Informationssysteme mittels konzeptioneller Datenmodellierung. 6. A„ Verlag Teubner, Stuttgart 1990 Schlageten G. und Stucky, W.: Datenbanksysteme. Konzepte und Modelle. 2. A., Verlag Teubner, Stuttgart 1983 Vertiefungsliteratur Codd, E. F.: A Relational Model for Large Shared Data Banks. In: Communications of the ACM 6/1970, 377 - 387 Codd, E. F.: Further normalization of the relational model. In: Rustin, R. (Ed.): Data Base Systems, Courant Computer Science Symposium. Prentice Hall, Englewood Cliffs, N. J. 1972

NUMSY - Nummernsysteme Lernziele Sie kennen den Zweck von Nummernsystemen und die Vorgehensweise beim Entwerfen von Nummernsystemen. Sie kennen die Bedeutung und die verschiedenen Arten von Begriffssystemen. Sie wissen, welches Nummernsystem sich für welche Art der Informationsverarbeitung eignet. Sie erkennen die Bedeutung von Nummernsystemen für das Entwerfen des Datensystems. Definitionen und Abkürzungen Benummern (encoding) = das Zuordnen von Nummern auf Nummerungsobjekte. Identifizieren (identifying) = ein Nummerungsobjekt innerhalb eines Geltungsbereichs eindeutig und unverwechselbar erkennen, bezeichnen oder ansprechen. Identifizierungsnummer (identifying number) = eine Nummer, welche die Eigenschaft hat, ein Nummerungsobjekt zu identifizieren. Synonyme: Identifikationsnummer, Identnummer. Klassifizieren (classifying) = ein Nummerungsobjekt in Gruppen (Klassen), die nach bestimmten Merkmalen gebildet worden sind, einordnen. Klassifizierungsnummer (classifying number) = eine Nummer, welche die Eigenschaft hat, ein Nummerungsobjekt zu klassifizieren. Synonym: Ordnungsnummer. Mnemo (mnemo) = eine das Gedächtnis unterstützende Bezeichnung für ein Objekt. Nummer (number) = eine festgelegte Folge von Zeichen (Buchstaben, Ziffern und Sonderzeichen); im Sinn der Datenmodellierung: ein Wert des Schlüsselattributs. Synonym: Schlüssel. Nummernbereich (ränge of numbers) = eine Folge von Nummern, deren erste und letzte festgelegt sind. Nummernplan (numbering plan) = eine Übersicht über die im voraus festgelegten Bedeutungen von klassifizierenden Nummernteilen oder die Zuordnung von Nummernbereichen zu ihren Anwendungsgebieten. Nummernschlüssel (numbering code) = ein Verzeichnis, das belegten Nummern oder Nummernteilen die ihnen zugeordneten Bedeutungen oder Bezeichnungen gegenüberstellt. Nummerung (numbering) = das Wissen und alle Tätigkeiten im Zusammenhang mit dem Bilden, Erteilen, Verwalten und Anwenden von Nummern. Synonym: Verschlüsselung. Nummerungsobjekt (numbering entity) = ein Datenobjekt, dem eine Nummer zugeordnet ist oder zugeordnet werden soll. Prüfziffer (check digit) = eine Ziffer, die aus einer Nummer errechnet und zur Kontrolle der formalen Richtigkeit dieser Nummer an diese angefügt wird. Suchcode (match code) = eine Zeichenfolge, die aus Teilen der Attributewerte gebildet wird und zum Auffinden eines Datensatzes in einem Datenbestand dient, wenn die Identnummer nicht bekannt ist. Synonym: Abgleichcode.

NUMSY - Nummernsysteme

137

Zweck des Nummernsystems Ein Nummernsystem ist "eine nach bestimmten Gesichtspunkten gegliederte Zusammenfassung von Nummern oder Nummernteilen mit Erläuterung ihres Aufbaus" (DIN 6763). Mit einem Nummernsystem wird festgelegt, auf Grund welcher Kriterien ein Nummerungsobjekt eine bestimmte Nummer erhält. Zweck eines Nummerungssystems ist es, Nummerungsobjekte eindeutig und unverwechselbar zu identifizieren und - wo notwendig und sinnvoll - in eine Gruppe einzuordnen, also zu klassifizieren. Zur Darstellung des formalen Aufbaus von Nummern ist ein Nummernschema erforderlich, aus dem die Anzahl der Nummernstellen, die Nummernteile sowie deren Schreibweise hervorgehen. Eine Nummernstelle ist (nach DIN 6763) der Ort (Lage, Stelle) in einer Nummer für ein zugelassenes Zeichen oder für Leerstellen. Nummernstellen können aus Datenstellen (Ziffern und Buchstaben) oder Gliederungsstellen (Leerstellen und Sonderzeichen) bestehen. Ein Nummernteil ist eine einzelne Datenstelle, oder es sind mehrere zusammengehörige Datenstellen. Abbildung NUMSY-1 zeigt den Aufbau des Nummernschemas. 1

A

2

3

4

5

i

i

'

i

i

i

i

i

i Nummernstellen

i

i

i

'

'

i

i

i

i Datenstellen

l

l

l

l

l

I

l

l

l i

Gliederungsstellen l Nummernteile i Nummer

Abb. NUMSY-1: Aufbau des Nummernschemas (Quelle: Grupp)

Identifizieren Jede größere Datenbasis braucht einen Mechanismus, der einen schnellen und sicheren Zugriff zu einer Teilmenge der Datenbasis, die für einen bestimmten Arbeitsvorgang benötigt wird, ermöglicht. Namen und Bezeichnungen der Nummerungsobjekte reichen dafür nicht aus, weil sie häufig nicht eindeutig sind (insbes. bei einer größeren Anzahl von Nummerungsobjekten). Je größer die Anzahl der Nummerungsobjekte ist, desto mehrdeutiger ist der Name bzw. die Bezeichnung und desto länger muß die verbale Beschreibung sein. Dies führt zu unrationeller Verarbeitung oder macht die Verarbeitung unmöglich. Deshalb wird der Name durch eine Nummer ersetzt, welche die Aufgabe hat, das Nummerungsobjekt zu identifizieren. Sie wird als Identifizierungsnummer (kurz: Identnummer) bezeichnet und ist "nicht sprechend", was bedeutet, daß sie keine Information über das Nummerungsobjekt enthält. Diese Feststellung schließt nicht aus, daß die Identnummer klassifizierende Nummernteile enthalten kann. Anforderungen an eine Identnummer sind Eindeutigkeit, Beständigkeit (Unveränderlichkeit), konstante Stellenanzahl und Gliederung; die Stellenanzahl soll so klein wie möglich sein.

138

Methoden und Techniken der Grobprojektierung

• Eindeutigkeit: Jedes Nummerungsobjekt muß eine Identnummer haben, jedes Nummerungsobjekt darf nur eine Identnummer haben. • Beständigkeit: Eine Nummer soll so lange unverändert bleiben, wie das Nummerungsobjekt existiert. Da die Nummern innerhalb eines Nummernsystems nicht nur einmal, sondern - nach Freiwerden - immer wieder vergeben werden, muß das Nummernsystem solange "leben", bis das letzte Nummerungsobjekt wegfällt. • Konstante Stellenanzahl und Gliederung: Um Erfassungs-, Verarbeitungs- und Übertragungsfehler zu reduzieren, sollen alle Nummern innerhalb eines Nummernsystems die gleiche Stellenanzahl und Gliederung haben. • Kleine Stellenanzahl: Die Anzahl der fehlerhaft erfaßten oder übertragenen Nummern steigt überproportional mit der Länge der Nummern; die Stellenanzahl soll daher so klein wie möglich sein. Diese Anforderungen werden am besten von der Zählnummer erfüllt. Sie ist die kürzest mögliche Identnummer, hat eine konstante Stellenanzahl und Gliederung und ist eindeutig. Da sie keine zeitabhängigen Bestandteile enthält (also keine Eigenschaften des Nummerungsobjekts, die sich verändern), hat sie eine unbegrenzte Lebensdauer. Eine Zählnummer wird durch - nicht unbedingt lückenloses - Zählen und Zuordnen zu einem Nummerungsobjekt gebildet. Klassifizieren Mit der Anzahl der Nummerungsobjekte steigt die Notwendigkeit, diese in Gruppen zu ordnen ("Gruppenbildung"). Eine Gruppe ist die Basis für verdichtete Auswertungen (z.B. für eine Umsatzstatistik nach Artikelgruppen) und wird auch für die Steuerung der Verarbeitung im Anwendungsprogramm verwendet (z.B. die Lohngruppe bei der Ermittlung des Bruttolohns). Je detaillierter die Gruppenbildung erfolgt, desto schwieriger wird es, die Merkmale einer Gruppe verbal zu beschreiben, um die Gruppenzugehörigkeit darzustellen. Wenn die Gruppe nicht mit einer quantitativen Größe, die als Nummer verwendbar ist (z.B. die Länge eines Materials oder das Alter einer Person), bezeichnet werden kann, benötigt sie eine Nummer, welche die Gruppe identifiziert, das einzelne Nummerungsobjekt der Gruppe aber klassifiziert. Die Klassifizierungsnummer ordnet Nummerungsobjekte nach bestimmten Merkmalen in Gruppen (Klassen) ein. Sie wird auch als "sprechende" Nummer bezeichnet, womit ausgedrückt wird, daß aus der Nummer auf Eigenschaften des Nummerungsobjekts geschlossen werden kann. Anforderungen an die Klassifizierungsnummer sind Ausschließlichkeit der Gruppenzugehörigkeit, Feinheit der Gliederung, Anpassungsfähigkeit, Systematik und Übersichtlichkeit sowie konstante Gliederung und Stellenanzahl. • Ausschließlichkeit der Gruppenzugehörigkeit: Die Gruppen müssen so gebildet und benummert werden, daß jedes Nummerungsobjekt eindeutig einer (und nur einer) Gruppe zugeordnet werden kann. • Feinheit der Gliederung: Je feiner die Gliederung des Nummernsystems ist, desto schwieriger ist es, eine eindeutige Gruppenzuordnung zu erreichen.

NUMSY - Nummernsysteme

139

• Anpassungsfähigkeit: Auch die Klassifizierungsnummer soll eine möglichst lange Lebensdauer haben, um über einen längeren Zeitraum vergleichbare Auswertungen zu ermöglichen. • Systematik und Übersichtlichkeit: Die Klassifizierungsnummer muß - im Unterschied zur Identifizierungsnummer - einen systematischen Aufbau haben, der die Gliederung der Merkmale widerspiegelt. • Konstante Gliederung und Stellenanzahl: So wie bei der Identifizierungsnummer ist es bei der Klassifizierungsnummer nicht zweckmäßig, mit einer variablen Stellenanzahl oder Gliederung zu arbeiten. Entwerfen von Nummernsystemen Das Entwerfen von Nummernsystemen bedeutet das Festlegen von Begriffssystemen, die zur Benummerung verwendet werden. Ein Nummernsystem, das mehrere betriebliche Aufgabenbereiche (z.B. Einkauf, Arbeitsvorbereitung, Fertigung und Montage) und verschiedene Arbeitsabläufe (z.B. Bestandsführung, Bedarfsermittlung und Bestellabwicklung) berührt, kann nur mit Rücksicht auf die bestehende Arbeitsorganisation und mit Rücksicht auf bestehende Nummernsysteme bzw. in Abstimmung mit der geplanten Arbeitsorganisation entwickelt werden. Die Wahl des Nummernsystems muß in Abhängigkeit von der Anzahl der Nummerungsobjekte, der Anzahl und dem Detaillierungsgrad der Klassifizierungsmerkmale und der Verwendung des Nummernsystems im Arbeitsablauf erfolgen. Das Entwerfen eines Nummernsystems ist ein Vorgang, der eine detaillierte sachliche und terminliche Planung erfordert und von den Ergebnissen einer Strukturanalyse des Istzustands ausgeht (vgl. Lerneinheit ANIST). Begriffssysteme Vom Ergebnis der Strukturanalyse ausgehend, werden die Begriffssysteme der Nummerungsobjekte geklärt und mit allen Merkmalen übersichtlich dargestellt. Folgende Begriffssysteme werden unterschieden: Begriffssystem ohne Systematik, Begriffssystem mit hierarchischer Gliederung, Begriffssystem mit nebengeordneter Gliederung, Begriffssystem mit bereichsweiser Gliederung und Begriffssystem mit kombinierter Gliederung. Begriffssystem ohne Systematik. Die Nummerungsobjekte haben keine Eigenschaften, die eine Klassifizierung erlauben oder auf deren Abbildung durch eine Nummer Wert gelegt werden soll (z.B. Begriffssysteme für Maßeinheiten und Währungen). Bei den meisten dieser Begriffssysteme empfiehlt sich die Verwendung mnemotechnischer Schlüssel (z.B. für Kilogramm "kg" und nicht "Ol", für die Kennzeichnung eines Artikels als Auslaufartikel "A" und nicht "9"). Begriffssystem mit hierarchischer (untergeordneter, serieller) Gliederung ("Begriffsleiter"). Die Begriffe der unteren Stufe sind durch Vermehrung der einschränkenden Eigenschaften aus den Begriffen der höheren Stufe abgeleitet (Nummernstelle oder Nummernteil sind von der vorhergehenden Stelle eindeutig abhängig). Charakteristisch für den hierarchischen Aufbau ist folgendes:

140

Methoden und Techniken der Grobprojektierung

• Eine Eigenschaft eines Nummerungsobjekts wird durch eine Nummernstelle nur dann eindeutig gekennzeichnet, wenn alle vorhergehenden Nummernsteilen bzw. Nummernteile mit angeführt werden (Aufbau der Nummer immer von links nach rechts). • Auswertungen sind nur in der durch den Aufbau vorgegebenen Reihenfolge sinnvoll. Abbildung NUMSY-2 zeigt schematisch den Aufbau einer Begriffsleiter. Der Nummernteil der Hierarchiestufe 3 (Nummernstellen 3 und 4) kann nur im Zusammenhang mit den links von ihm stehenden Oberbegriffen (zunächst 2 und dann 1) verstanden werden; die Bedeutung des Nummernteils 3 ist von der des Nummernteils 2, und die Bedeutung des Nummernteils 2 ist von der des Nummernteils 1 abhängig. 12

3 4 Hierarchiestufe 1 (Nummernteil 1) Hierarchiestufe 2 (Nummernteil 2) Hierarchiestufe 3 (Nummernteil 3)

Abb. NUMSY-2: Begriffssystem mit hierarchischer Gliederung (Quelle: Grupp)

Begriffssystem mit nebengeordneter (unabhängiger, paralleler) Gliederung ("Koordinierung"). Die Eigenschaften der Nummerungsobjekte können in voneinander unabhängige Klassen geordnet werden; sie sind gleichrangig. Jede Nummernstelle bzw. jeder Nummernteil hat eine eigene, nicht von der vorhergehenden Nummernstelle bzw. von dem vorhergehenden Nummernteil abgeleitete Bedeutung. Abbildung NUMSY-3 zeigt den Aufbau eines Begriffssystems mit nebengeordneter Gliederung. Typisch für diesen Nummernaufbau ist folgendes: • Die Gruppenkennzeichnung der Nummernstelle bzw. des Nummernteils ist auch ohne Angabe der vorhergehenden Nummernstelle bzw. des vorhergehenden Nummernteils eindeutig. • Die Reihenfolge der Nummernstellen bzw. der Nummernteile kann ohne Auswirkungen auf ihre Bedeutung verändert werden. • Auswertungen können in beliebiger Reihenfolge oder selbständig für jede Nummernstelle oder jeden Nummernteil erfolgen. • Es sind Kombinationen der einzelnen Nummernstellen oder Nummernteile untereinander möglich, aber nicht immer sinnvoll und daher nicht zulässig. >

Schuhnummer

^

Selbständige Modellnummer Farbton odell 1982

17.16.12.105

Abb. NUMSY-3: Begriffssystem mit nebengeordneter Gliederung (Quelle: Grupp)

NUMSY - Nummernsysteme

141

Begriffssystem mit bereichsweiser Gliederung. Eine Zählnummer hat keinen Aufbau in dem Sinn, daß einer Nummernstelle eine bestimmte Bedeutung zukommt. Trotzdem kann sie durch die Bildung von Nummernbereichen zur Gruppenkennzeichnung herangezogen werden (z.B. Belegnummern 00001 bis 09999 für Ausgangsrechnungen Inland, Belegnummern 10000 bis 29999 für Ausgangsrechnungen Export). Davon ist jedoch abzuraten, weil meist - auch bei bester Planung - ein Nummernbereich nach einer begrenzten Zeit "erschöpft" ist ("Platzen" des Nummernbereichs) und durch einen zweiten Nummernbereich ergänzt werden muß. Begriffssystem mit kombinierter Gliederung. Ein Nummernsystem wird selten mit nur einem Begriffssystem, sondern meist unter Verwendung aller drei Begriffssysteme - hierarchischer, nebengeordneter und bereichsweiser Aufbau gestaltet. Entscheidend für die Eigenschaften eines Nummernsystems ist die Verbindung zwischen den beiden Funktionen Identifizieren und Klassifizieren im Aufbau der Nummer. Dabei gibt es zwei Möglichkeiten, das Verbund-Nummernsystem und das Parallel-Nummernsystem (vgl. auch das Demonstrationsbeispiel). Verbund-Nummernsystem: Die Identifizierung des Nummerungsobjekts erfolgt zunächst durch den Klassifizierungsteil und dann zusätzlich durch den Zählteil (Abbildung NUMSY-4). Dabei ist der Zählteil vom Klassifizierungsteil abhängig. In jeder Klasse wird mit einer eigenen Zählnummer begonnen. Es empfiehlt sich daher, den Klassifizierungsteil vor den Zählteil zu setzen. Das Verbund-Nummernsystem ist sinnvoll, wenn folgende Bedingungen erfüllt sind: • Die Anzahl der zur Klassifizierung verwendeten Eigenschaften der Nummerungsobjekte ("Klassifizierungsmerkmale") ist gering. • Die Klassifizierungsmerkmale sind für alle oder zumindest für die meisten am Arbeitsablauf beteiligten Benutzer von Interesse. • Die Klassifizierungsmerkmale werden für alle oder zumindest für die meisten Auswertungen benötigt. • Die Klassifizierungsmerkmale sind langfristig stabil; das Nummernsystem ist daher weder schnell überholt noch kann es "platzen". • Der Klassifizierungsteil ist so einfach aufgebaut, daß er nach kurzer Einarbeitungszeit von den Benutzern ohne Benutzung des Nummernplans verstanden wird. XXX

• XX - XXX • Hauptgruppe - Untergruppe

Klassifizierungsteil Zählteil

Verbundnummer

Abb. NUMSY-4: Aufbau eines Verbund-Nummernsystems

Parallel-Nummernsystem: Identifizierung und Klassifizierung erfolgen unabhängig voneinander, der Identifizierungsteil (mit dem im wesentlichen gearbeitet wird) enthält keine klassifizierenden Nummernteile. Wie Abbildung NUMSY-5 zeigt, folgt dem Identifizierungsteil der Klassifizierungsteil, der hierarchisch

142

Methoden und Techniken der Grobprojektierung

oder nebengeordnet aufgebaut ist. Bei Dialogverarbeitung ist das Parallel-Nummernsystem am zweckmäßigsten, weil zur Eingabe am Bildschirm nur der Identifizierungsteil (der in der Regel eine geringe Stellenanzahl hat) erforderlich ist; alle Eigenschaften des Nummerungsobjekts werden im Datensystem geführt und bei Bedarf am Bildschirm angezeigt. Das Parallel-Nummemsystem ist sinnvoll, wenn folgende Bedingungen erfüllt sind: • Es sind viele Klassifizierungsmerkmale zu berücksichtigen. • Benutzer mit unterschiedlichen Anforderungen verwenden das Nummernsystem. • Die Klassifizierungsmerkmale ändern sich kurz- oder mittelfristig. • Die Nummerungsobjekte haben eine lange Lebensdauer. • Die Anzahl der Nummerungsobjekte ist groß (eine kurze Identnummer reduziert den Datenerfassungsaufwand und erhöht die Sicherheit). • Es stehen noch nicht alle für eine vollständige Klassifizierung benötigten Merkmale fest. XXXX || XXX

XX

I

Identifizierungsteil Klassifizierungsteil (hierarchisch oder nebengeordnet aufgebaut)

Parallelnummer

Abb. NUMSY-5: Aufbau eines Parallel-Nummernsystems

Grundsätzlich eignet sich das Verbundnummern-System eher für die manuelle Verarbeitung, während das Parallel-Nummernsystem der maschinellen Verarbeitung besser gerecht wird. Eine Verbundnummer kommt bei maschineller Verarbeitung in Betracht, wenn die Nummerungsobjekte nach einem langfristig stabilen und im Wachstum überschaubaren Merkmal klassifiziert werden (wie es bei der Kostensteilen-Nummer der Fall ist), oder wenn besondere Anforderungen an die Merkfähigkeit der Nummer gestellt werden. Andererseits ist die Verwendung von Identifizierung und Klassifizierung in einem Nummernsystem von Vorteil, weil für beide Funktionen ein optimaler Nummernaufbau gewählt werden kann. Verwendung von Suchcodes Der Zugriff auf Datenbestände erfolgt im Dialogbetrieb durch den Benutzer, in der Regel über eine Identnummer. Die Identnummer ist auch der Schlüssel, unter dem das Nummerungsobjekt in der Datenbank gespeichert ist. Für den Benutzer ist die Identnummer ein "Umweg", wenn er weiß, welches Datenobjekt er bearbeiten will; sie ist häufig aus den Bearbeitungsunterlagen nicht ersichtlich und dem Benutzer nicht bekannt. Statt die Identnummer zu suchen (z.B. in einer Liste, in der die Datenobjekte nach einer bekannten Bezeichnung alphabetisch geordnet sind), wird ein Suchcode verwendet. Ein Suchcode besteht meist aus mehreren Teilen von Werten mehrerer Attribute (z.B. aus mehreren "Adreßbestandteilen", wie die ersten vier Stellen des Nach-

NUMSY - Nummernsysteme

143

namens und die erste Stelle des Vornamens). Suchcodes können auf unterschiedliche Weise gebildet werden: • durch den Benutzer bei der Pflege der Stammdaten, indem er sie in einem Eingabefeld am Bildschirm angibt; • durch automatische Generierung durch das Datenverwaltungssystem bei jeder Veränderung des Datenbestands. Der Suchcode wird in einer Suchcode-Datei abgelegt. Das Datenverwaltungssystem findet über den eingegebenen Suchcode die Identnummer im Datenbestand. Entspricht einem gespeicherten Suchcode nur eine Identnummer des Datenbestands, kann unmittelbar auf den gespeicherten Datensatz zugegriffen werden. Ist der Suchcode nicht eindeutig, so erhält der Benutzer zuerst eine Aufzählung der in Betracht kommenden Datensätze ("Mehrfachanzeige"). Aus dieser Liste kann er durch "Ankreuzen", durch "Anklicken" mit einem Zeigeinstrument oder durch Eingeben einer Zeilennummer den gewünschten Datensatz auswählen. Dokumentation des Nummernsystems Die Benutzer eines Nummernsystems sind normalerweise nicht mit den Personen identisch, die das Nummernsystem ausgearbeitet haben. Sie brauchen daher eine Arbeitsanweisung mit folgenden Bestandteilen: • Beschreibung der Nummerungsobjekte (welche Objekte gehören zum Nummernsystem?); • Verzeichnis der Nummern (Identnummern und Klassifizierungsnummern); • Darstellung des Nummernaufbaus (Nummernschema, Nummernplan); • Zuständigkeit für die Nummernvergabe; • Vorgehensweise und Hilfsmittel bei der Nummernvergabe; • Führung der Nummernverzeichnisse; • Kontrolle gegen Doppelbenummerungen und ihre Bereinigung; • Löschung frei gewordener Nummern; • Wiederverwendung frei gewordener Nummern; • Benummerungsbeispiele. Demonstrationsbeispiel Es wird am Beispiel der Europäischen Artikelnummer (EAN) der Aufbau eines Begriffssystems mit kombinierter Gliederung gezeigt. Abbildung NUMSY6 zeigt das Nummernschema der EAN an einem Beispiel. Die Nummer besteht aus 13 Stellen. Die beiden ersten Stellen sind für das zweistellige Länderkennzeichen reserviert. Die folgenden fünf Stellen sind ein ländereinheitliches Betriebsnummernsystem (bbn). Die bbn werden von zentralen Verbänden der Länder vergeben (z.B. von der EAN AUSTRIA in Österreich). Für die Artikelnumerierung stehen weitere fünf Stellen zur Verfügung. Innerhalb dieses Nummernteils kann das Herstellerunternehmen die Artikelnummer frei vergeben. Mit der Prüfziffer (13. Stelle) werden bis zu 97% der Fehler bei der Datenerfassung erkannt. Nicht erkannt werden Doppeldrehfehler. Daher besteht die Bedeutung der Prüfziffer überwiegend in der Absicherung des maschinellen Lesepro-

144

Methoden und Techniken der Grobprojektierung

zesses (Strichcode) durch ein opto-elektronisches Lesegerät ("Scanner"), insbesondere am Verkaufspunkt im Einzelhandel (vgl. dazu die Forschungsbefunde). Läntierkernlzeic len

Betriebsnummer Zenti•ale Vergabestelle EAN AUSTRIA

Individuelle Artikelnummer des Herstellers

Prüfziffer

9 0 1 2 3 4 6 0 0 7 1 2 5 EAN HANS SCHUSTER KG AUSTRIA Hauptstraße 8 5200 Salzburg

Salzburger Edelmarzipan Geschenkpackung 100g

97% Sicherheit

Abb. NUMSY-6: Nummernschema Europäische Artikelnummer (Beispiel)

Forschungsbefunde Ziel einer repräsentativen empirischen Studie, die Ende 1989 von der Centrale für Coorganisation bei A. C. Nielson in Auftrag gegeben wurde, war es, die Fehlerquoten beim Kassiervorgang auf der Basis einer landesweiten Untersuchung von Scanning- und Nicht-Scanning-Geschäften zu ermitteln. In 80 Geschäften (je 40 mit und ohne Scanning) kauften Tester an fünf aufeinander folgenden Tagen je einen Warenkorb mit 50 Einzelartikeln, die aus 70 Warenklassen ausgewählt wurden. Insgesamt ergab dies 400 Warenkörbe mit 20.000 Artikeln. Es wurde eine Fehlerquote von insgesamt 3,2% festgestellt, 3,4% in Scanning-Geschäften und 2,9% in Nicht-Scanning-Geschäften. Als häufigste Fehlerursachen wurden Abweichungen zwischen Regalpreis und Scanning-Preis sowie die Eingabe falscher Multiplikatoren (Anzahl gleicher Artikel) durch das Bedienungspersonal festgestellt. Daraus kann folgender Schluß gezogen werden: Unabhängig vom Kassensystem (Scanning oder Nicht-Scanning) unterlaufen den beteiligten Personen Fehler in ähnlichen Größenordnungen; das Scanning kann als sicher angesehen werden. Aufgabenverweise Entwerfen des Datensystems (Lerneinheit WDASY).

Kontrollfragen 1. 2. 3. 4. 5.

Welcher Unterschied besteht zwischen Identifizieren und Klassifizieren? Was wird unter hierarchischem Aufbau, was unter nebengeordnetem Aufbau eines Begriffssystems verstanden? Welche Vorteile hat ein Verbund-Nummernsystem gegenüber einem Parallel-Nummemsystem? Wer ist für die Vergabe der EAN-Nummer zuständig? Um welche Nummernsysteme handelt es sich bei Postleitzahlen, Kfz-Kennzeichen, Kontonummern einer Buchhaltung, Hausnummern und Papierformaten?

NUMSY - Nummernsysteme

145

Quellenliteratur Grupp, B.: Optimale Verschlüsselung bei Online-Datenverarbeitung - Aufbau moderner Nummernsysteme für Sachnummern jeder Art, Personennummern und Auftragsnummein. Verlag TÜV Rheinland, Köln 1987 Kunerth, W.: EDV-gerechte Verschlüsselung: Grundlagen und Anwendung moderner Nummernsysteme. 2. A., Forkel Verlag, Stuttgart/Wiesbaden 1981 Werner, G. und Bernhardt, R.: Die Nummer als Schlüssel in der Datenverarbeitung. Grundlagen und Anwendung moderner Nummemsysteme. 3. A., Forkel Verlag, Wiesbaden 1991 Vertiefungsliteratur EAN AUSTRIA, Gesellschaft für kooperative Logistik GesmbH., Wien (Hrsg.): INFO EAN, Fachzeitschrift für Artikelnumerierung, Warenwirtschaft und elektronischen Datenaustausch 2/1991,4-6 Schlaffer, P.: Systemfreie Benummerung. DIN-Mitteilungen 12/ 1983, 601 -609 VDI-Richtlinie 3320: Werkzeugnummerung - Werkzeugordnung. VDI-Verlag, Düsseldorf 1973 Normen DIN 6763 - Nummerung. Allgemeine Begriffe

OPMOD - Optimierungsmodelle Lernziele Sie kennen die Bedeutung von Optimierungsmodellen des Operations Research, also der mathematischen Modellierung und Lösungsfindung, für den Entwurf des Methodensystems. Sie können Gründe für die geringe Verbreitung von Optimierungsmodellen in der Praxis nennen und den Einfluß der Weiterentwicklung der Hardware- und Softwaretechnologie auf die Modellanwendung beurteilen. Sie kennen die Arbeitsschritte zum Entwerfen von Optimierungsmodellen. Definitionen und Abkürzungen deterministisch (deterministic) = die Eigenschaft eines Prozesses, daß die zukünftigen Zustände im Prozeßablauf eindeutig festliegen und daher mit Sicherheit vorhersagbar sind. Formalproblem (formal problem) = die in einem Optimierungsmodell dargestellte Aufgabe, die wegen der vereinfachten Abbildung der Wirklichkeit mit dem Realproblem in der Regel nicht voll übereinstimmt. Isomorphismus (isomorphism) = die Form der Abbildung der Wirklichkeit in einem Modell, bei der jedem Element und jeder Beziehung der Wirklichkeit eindeutig ein Element und eine Beziehung des Modells zugeordnet sind. Synonym: Strukturgleichheit. Lineare Optimierung (linear optimization) = die Form der Optimierung, deren mathematisches Modell ausschließlich lineare Funktionen enthält; im Unterschied dazu: Nichtlineare Optimierung. Synonym: Lineare Programmierung, mathematisches Modell (mathematical model) = ein Modelltyp, mit dem die Wirklichkeit durch mathematische Gleichungen abgebildet wird. Synonyme: abstraktes Modell, formales Modell. Modell (model) = die vereinfachende Abbildung eines Ausschnitts der Wirklichkeit mit einem bestimmten Beschreibungsmittel. Nebenbedingung (side condition) = eine Bedingung, die den Lösungsraum eines Entscheidungsmodells abgrenzt. Synonym: Restriktion (constraint). Realproblem (real problem) = die einem Sachziel der Systemplanung entsprechende betriebliche Aufgabe, für die ein Optimierungsmodell als Lösungsmethode konstruiert wird, stochastisch (stochastic) = die Eigenschaft eines Prozesses, nicht streng deterministisch, sondern vom Zufall abhängig zu sein. Validität (validity) = das Ausmaß, mit dem ein Modell das, was es abbilden soll, auch tatsächlich abbildet. Synonym: Gültigkeit. Wahrscheinlichkeitstheorie (probability theory) = die Gesamtheit der logischen und mathematischen Verfahren, die sich damit befassen, die Wahrscheinlichkeit zufalliger Ereignisse zu berechnen. Zielfunktion (objective function) = eine mathematische Funktion der Entscheidungsvariablen in einem mathematischen Modell, mit dem die Wirksamkeit einer jeden Maßnahme für ein im Modell abgebildetes Ziel oder mehrere im Modell abgebildete Ziele mit einem quantitativen Maß erfaßt wird.

OPMOD - Optimierungsmodelle

147

Zweck von Optimierungsmodellen Die Konstruktion von Optimierungsmodellen ist primär Gegenstand einer wissenschaftlichen Disziplin, die - dem amerikanischen Sprachgebrauch folgend - als Operations Research (kurz: OR) bezeichnet wird. Operations Research hat viele historische Wurzeln. Im allgemeinen wird sein Ursprung auf das Jahr 1937 datiert, als sich eine Arbeitsgruppe der Royal Air Force mit der interdisziplinären Planung militärischer Operationen befaßte. Nach 1945 verlagerte sich der Anwendungsbereich des OR auf betriebliche und volkswirtschaftliche Aufgaben. Im ursprünglichen Sinn ist OR die Vorgehensweise, eine "... bestimmte komplexe Problemstellung ... mit Hilfe von mathematisch-naturwissenschaftlichen Methoden einer Lösung zu(zu)führen ... Der Zweck ... besteht darin, diejenigen zu unterstützen, die Systeme der genannten Art gestalten und leiten." (Stafford Beer, 1957). Heute wird unter OR die Anwendung von mathematischen Methoden zur Vorbereitung optimaler Entscheidungen verstanden. Dieser Erklärung folgend, wird synonym für Operations Research die Bezeichnung "Optimalplanung" verwendet. Die Merkmale der Optimalplanung sind: • Es werden Entscheidungen vorbereitet. • Es handelt sich um optimale Entscheidungen. • Es werden mathematische Methoden verwendet. Die Konstruktion von Optimierungsmodellen setzt voraus, daß das zu lösende Problem ("Realproblem") in ein mathematisches Problem ("Formalproblem") übertragen werden kann. Auf dieses Formalproblem lassen sich verschiedene mathematische Methoden zur Problemlösung anwenden, das heißt, es läßt sich ein mathematisches Modell entwickeln, welches das Formalproblem etwa wie folgt definiert: Wähle die Werte der Entscheidungsvariablen so, daß die Zielfunktion unter Einhaltung der angegebenen Nebenbedingungen maximiert bzw. minimiert wird. Das Ergebnis der Lösung des Formalproblems im mathematischen Modell wird auf die Wirklichkeit übertragen, und es ergibt sich - unter bestimmten Voraussetzungen - die Lösung des Realproblems. Diese hat den Charakter eines Entscheidungsvorschlags. Der wesentliche Vorteil von Optimierungsmodellen gegenüber anderen Problemlösungsmethoden (vgl. Lerneinheit WMESY) besteht in der Möglichkeit, das Problem sehr präzis zu beschreiben. Ein mathematisches Modell offenbart die Struktur des Problems besser als andere Beschreibungsmittel und läßt Ursache/Wirkung-Beziehungen leichter erkennen. Ein wesentlicher Nachteil ist, daß die Entstehung von Modellgrößen, aus den ursprünglichen Daten bis hin zu den Zielgrößen, vom Anwender nicht verfolgt werden kann (im Unterschied z.B. zu Planungssprachen, vgl. Lerneinheit SPLAN). Schwächen traditioneller Optimierungsmodelle In der Theorie gibt es eine große Anzahl von OR-Methoden und OR-Modellen (im folgenden kurz: Optimierungsmodelle). Die meisten Optimierungsmodelle wurden (und werden) nach den Methoden der Linearen Optimierung entwickelt (andere Methoden sind: Dynamische Optimierung, Ganzzahlige Optimie-

148

Methoden und Techniken der Grobprojektierung

rung und Nichtlineare Optimierung). Aus folgenden Gründen haben diese Optimierungsmodelle nur eine geringe Verbreitung in der Praxis gefunden: • der nicht vorhandene Isomorphismus zwischen Wirklichkeit und Modell; • der Versuch, große Ausschnitte der Wirklichkeit in einem Optimierungsmodell zu erfassen ("Gesamtmodell"); • der hohe Betriebsmittelbedarf, vor allem der Bedarf an schneller Hardware; • die langen Durchlaufzeiten (vor allem Rechenzeiten) bei der Abarbeitung der Anwendungsprogramme; • die geringen OR-Kenntnisse der Systemplaner; • die für den Benutzer ohne OR-Kenntnisse schwer verständliche, zeichenorientierte Benutzeroberfläche; • die Theoriedefizite, die sich vor allem durch mangelhafte Berücksichtigung stochastischer, dynamischer und unscharfer Eigenschaften der Wirklichkeit bemerkbar machen; • die relativ lange Entwicklungszeit. Die größte Schwierigkeit bei der mathematischen Modellierung bereitet das oft gleichzeitige Auftreten stochastischer, dynamischer und unscharfer Eigenschaften der betrieblichen Wirklichkeit. Die Optimierungsmodelle enthalten meist bedeutende deterministische Komponenten; ihre Aussagen können daher zur Wirklichkeit im Widerspruch stehen. Die Optimierungsmodelle sind zumeist statisch; ihre Aussagen sind daher nur für kurze Zeit gültig, und es ist ein hoher Wartungsaufwand erforderlich. Fast alle Optimierungsmodelle grenzen den zulässigen vom unzulässigen Handlungsspielraum exakt ab, obwohl der Übergang zwischen beiden in der Wirklichkeit fließend ist. Diese Schwierigkeiten haben zur Folge, daß der Praktiker ein Optimierungsproblem "aus Erfahrung" oft besser (und das heißt meist auch: schneller) löst als ein Optimierungsmodell. Weiterentwicklung der Optimierungsmodelle Zur Verbesserung dieser Situation sind folgende Vorgehensweisen denkbar: • Eine drastische Erhöhung des Aufwands für den Methodenentwurf in jedem einzelnen Anwendungsfall, um mehr Daten über die Eigenschaften der Wirklichkeit zu erfassen und bei der Modellierung berücksichtigen zu können. • Die Weiterentwicklung der Theorie, insbesondere in der Richtung, daß sich Optimierungsmodelle nicht auf eine fixe Optimallösung beschränken, sondern im optimumverdächtigen Bereich alle möglichen Lösungen bearbeiten, um die Optimallösung zu finden, die den Anforderungen der Wirklichkeit entspricht. • Die Verwendung einer "Dialogmethode", bei der zunächst durch das Optimierungsmodell eine Optimallösung als Näherungslösung bestimmt wird, die dann mit Hilfe des Fachwissens des Benutzers verändert und deren Auswirkungen im Dialog untersucht wird. Der Vorteil der Dialogmethode besteht darin, daß es möglich ist, mit unvollständigen Bedingungen und groben Ausgangsdaten das Optimierungsmodell zu formulieren und - darauf aufbauend - eine erste Problemlösung zu ermitteln. Davon ausgehend, kann die für die Verbesserung und Bestätigung notwendige Datenerhebung gezielt vorgenommen werden. Entscheidender Nachteil der Dia-

OPMOD - Optimierungsmodelle

149

logmethode ist, daß nach Vorliegen der ersten Problemlösung im wesentlichen nach der Methode "Versuch und Irrtum" fortgefahren wird. Die Komplexmethode ist ein Versuch, (zunächst) auf dem Gebiet der Produktionsprogrammplanung die Vorteile der Dialogmethode zu nutzen und ihre Nachteile zu vermeiden. Das Neue an der Komplexmethode besteht darin, daß der bei einer traditionellen Planoptimierung als konstant angenommene Ausgangszustand in seinem veränderbaren Teil mit variablen Größen beschrieben wird, sodaß bei der Optimierung nicht nur Veränderungen bei den Stückzahlen erfolgen, sondern daß alle im Optimierungsmodell enthaltenen betriebswirtschaftlichen Größen in ihrem beeinflußbaren Bereich als Variable definiert und im nächstfolgenden Optimierungsschritt die bestmöglichen Veränderungen für diese Größen ermittelt werden. Damit kann im Prozeß der Optimierung das Optimalitätskriterium gewechselt werden (z.B. wird zunächst nach dem Kriterium "maximaler Durchsatz", und bei Erreichen dieses Wertes weiter nach dem Kriterium "minimaler Personaleinsatz" optimiert). Theoretische Ansätze zur Verringerung des Abstands zwischen Realproblem und Formalproblem sind die stärkere Berücksichtigung der Wahrscheinlichkeitstheorie sowie die Entwicklung der Theorie unscharfer Mengen (auch: Unschärfe-Theorie). Die Unschärfe-Theorie ist ein von L. A. Zadeh begründeter Zweig der Mathematik, der statt der klassischen Mengentheorie "unscharfe Mengen" verwendet. Es wird angenommen, daß in vielen Situationen der Wirklichkeit keine exakten Angaben über die Zugehörigkeit oder die Nicht-Zugehörigkeit eines Elements zu einer Menge gemacht werden können. Der Übergang erfolgt nicht sprunghaft, sondern stetig. Im Mittelpunkt der Unschärfe-Theorie steht die Definition des Übergangsbereichs von völliger Zugehörigkeit zu völliger NichtZugehörigkeit. Im Übergangsbereich hat jedes Element einen bestimmten Grad der Zugehörigkeit. Jeder Übergangsbereich ist durch eine Zugehörigkeitsfunktion darstellbar, welche die Abstufung des Elementseins zwischen den Binärvariablen 0 und 1 ausdrückt. Die Unschärfe-Theorie ist Grundlage für die Entwicklung unscharfer Regelsprachen und - mit deren Anwendung - unscharfer Regelsysteme. Daraus resultierende Anwendungen sind in den letzten Jahren stark gestiegen. Eine weiter steigende Bedeutung der Unschärfe-Theorie wird vorausgesagt (z.B. in der Robotik und bei der Verkehrssteuerung). Die geringe Verbreitung der Optimierungsmodelle in der Praxis steht nicht im Gegensatz zu der Aussage, daß zahlreiche Anwender mit deren Nutzung sehr gute Resultate erzielt haben. Erfolgreiche Anwendungen sind die Versuchs- und Rezepturplanung in der pharmazeutischen Industrie, die Verschnittoptimierung in der Möbelindustrie, der Textilindustrie und der Glasindustrie, die Produktionsplanung in der Chemischen Industrie und die Transportplanung in verschiedenen Wirtschaftszweigen. Auswahl der Optimierungsaufgaben Grundvoraussetzung für die Anwendung und weitere Verbreitung des OR ist, neben der methodischen Weiterentwicklung der mathematischen Modellierung, die zweckmäßige Auswahl der Aufgaben, die mit Optimierungsmodellen bearbeitet werden. Folgende Merkmale sollen die Aufgaben erfüllen:

150

Methoden und Techniken der Grobprojektierung

• große Häufigkeit der Anwendung, um den Aufwand für den Entwurf der Optimierungsmodelle amortisieren zu können; • hohe Komplexität der Aufgabe und großer Spielraum bezüglich der Variablen, um im Vergleich zu manuellen Erfahrungslösungen große Optimierungseffekte erzielen zu können; • Stabilität der Aufgabe (d.h. geringe Veränderlichkeit); • hohe Anforderungen an die Echtzeitverarbeitung. Voraussetzung für die erfolgreiche Anwendung von Optimierungsmodellen ist eine gründliche Analyse des Realproblems ("Aufgabenanalyse"), die gute fachliche Kenntnisse über die Aufgabe erfordert. Der Vorteil des Modellierens, das heißt auch: des Abstrahierens von der Wirklichkeit (wie bessere Überschaubarkeit des Realproblems, mögliche Quantifizierbarkeit, Möglichkeit der exakten mathematischen Formulierung und Aussagefähigkeit des Modells), ist mit dem Nachteil eines Verlusts an Wirklichkeit verbunden; infolge der vereinfachenden Abbildung stimmt das Modell mit der Wirklichkeit nicht überein. Die Optimallösung ist immer nur optimal in bezug auf das Formalproblem, nicht in bezug auf das Realproblem. Es gehört daher zur Aufgabenanalyse, sich über die möglichen Abweichungen der Modellaussagen von der Wirklichkeit Klarheit zu verschaffen, um diese bei der Übertragung der Optimallösung (für das Formalproblem) auf das Realproblem angemessen berücksichtigen zu können. Modellierungsgrundsätze Mit "Modellierungsgrundsätze" werden die Arbeitsphasen bezeichnet, die zum Durchführen einer OR-Studie zu durchlaufen sind. Dazu gehören Aufgabenanalyse (auch: Problemformulierung), Modellierung und Algorithmierung, Ermittlung einer Lösung und Überprüfung des Modells (Validitätsprüfung, Gültigkeitsprüfung). Die Aufgabenanalyse wird mit den folgenden Arbeitsschritten durchgeführt: Durchführen der allgemeinen Abstraktion, Festlegen der Optimierungsziele, Erfassen der Bedingungen, unter denen das Optimum zu suchen ist und Durchführen einer Kosten/Nutzen-Analyse. • Ausgehend vom Realproblem, erfolgt beim Durchführen der allgemeinen Abstraktion eine umfassende Systembetrachtung. Dabei werden alle Beziehungen und Einflußgrößen in bezug auf das Realproblem untersucht, die wesentlichen Parameter erfaßt und die unwesentlichen für die weitere Bearbeitung vernachlässigt. Danach werden die wesentlichen Parameter auf ihren Grad der Beeinflußbarkeit hin untersucht, um für die Modellierung die Eingangsdaten bereitstellen und die beeinflußbaren Größen, deren Optimalwerte gesucht werden, für den Variablenvektor angeben zu können. • Die Optimierungsziele ergeben sich aus der Aufgabe; im allgemeinen werden sie bei der Aufgabenanalyse in der Vorstudie festgelegt (vgl. Lerneinheit FORMZ). Darüber hinausgehende Einsichten ergeben sich aus der Aufgabenanalyse in der Feinstudie (vgl. Lerneinheit ANIST). • Im dritten Arbeitsschritt der Aufgabenanalyse werden die Bedingungen ermittelt, die den Lösungsraum des Optimierungsmodells abgrenzen ("Nebenbedingungen" oder "Restriktionen"). Dabei müssen die wesentlichen Bedingungen vollständig erfaßt, Widersprüche zwischen Bedingungen beseitigt und

OPMOD - Optimierungsmodelle

151

überflüssige Bedingungen eliminiert werden. Danach können sämtliche Daten, die - neben den Daten des bestehenden Datensystems - für die Optimierung erforderlich sind, bereitgestellt werden. • Mit der abschließenden Kosten/Nutzen-Analyse soll überprüft werden, ob die Implementierung des entworfenen Optimierungsmodells wirtschaftlich vertretbar ist, ob eine grundlegende Änderung des Modellentwurfs zweckmäßig ist oder ob nicht andere Methoden - statt der zunächst beabsichtigten Optimierung - angemessener sind. Durch die Abstraktion erhält das Modell einen die Wirklichkeit idealisierenden Charakter, weil unwesentliche Bedingungen vernachlässigt werden. Außerdem müssen bewußt Vereinfachungen vorgenommen werden, um die Implementierung und Nutzung des Modells zu ermöglichen bzw. den dafür erforderlichen Aufwand zu reduzieren (typische Entscheidungsprobleme bei der Modellierung der Produktionsprogrammplanung sind etwa: Welche Arbeitssysteme können zu einer Gruppe zusammengefaßt werden? Welche Erzeugnisse können zu Erzeugnisgruppen geordnet werden?). Dadurch tritt ein Verlust an Wirklichkeit ein. Da sich zudem die Wirklichkeit laufend verändert, ist es erforderlich, das Modell ständig zu überprüfen, um den "Abstand" zur Wirklichkeit kontrollieren zu können. Welches das richtige Abstraktionsmaß ist, kann nicht allgemein angegeben werden; dies muß aus der Erfahrung gewonnen werden. Bei der Modellierung ist es zunächst erforderlich, die Modellform zu bestimmen, mit der sich das Realproblem ausreichend genau abbilden läßt. Grundsätzlich kann es sich um ein lineares oder nicht-lineares Modell, ein statisches oder dynamisches Modell, ein deterministisches oder stochastisches Modell handeln. Bei der Modellierung wird möglichst auf Modellformen zurückgegriffen, die bekannt sind und für die Nutzungserfahrungen vorliegen (insbes. bezüglich der Optimierungsalgorithmen). Optimierungsalgorithmen sind Lösungsverfahren, die - bei Vorgabe einer Zielfunktion - aus der Menge möglicher Lösungsalternativen diejenige bestimmen, die der Zielfunktion am besten entspricht. Sie werden nach den folgenden Merkmalen systematisiert: • • • •

primale versus duale Algorithmen; ganzzahlige versus nicht-ganzzahlige Algorithmen; mathematisch exakte Algorithmen versus heuristische Lösungsverfahren; Eröffnungsverfahren versus suboptimale Korrekturverfahren.

Für die Auswahl von Optimierungsalgorithmen spielt auch die Frage eine Rolle, ob sie als Software-Produkte (z.B. in einem Methodenbanksystem, vgl. Lerneinheit SMEB A) vorliegen, oder ob sie in jedem Einzelfall der Entwicklung eines Optimierungsmodells implementiert werden müssen. Auf die Arbeitsphase "Ermittlung der Lösung" wird hier nicht eingegangen, weil es sich nicht um eine Entwurfsaufgabe handelt. Sie hat aber insofern Bedeutung, als exemplarische Lösungen zur Uberprüfung des Modells verwendet werden. Bevor ausgefeilte Tests durchführt werden, ist es zweckmäßig, die Modellierung und Algorithmierung durch Vergleich des Realproblems mit dem Modell zu überpüfen. Eine weitere Uberprüfung bezieht sich auf die mathematischen Ausdrücke (insbes. darauf, ob sie hinsichtlich der verwendeten Dimensionen konsistent sind).

152

Methoden und Techniken der Grobprojektierung

Ein systematischer Ansatz zur Überprüfung ist ein retrospektiver Test. Dafür werden Daten aus der Vergangenheit, für die eine Lösung bekannt ist, verwendet, und es wird überprüft, ob das Optimierungsmodell - bei Verwendung der gleichen Daten - zu einer besseren Lösung kommt. Damit kann auch der prognostizierte Nutzen der Modellanwendung präzisiert werden. Nachteil des retrospektiven Tests ist es, daß die Vergangenheit oft für die Zukunft nicht repräsentativ ist. Dieser Nachteil kann nur durch Parallelumstellung (vgl. Lerneinheit VINST) vermieden werden. Demonstrationsbeispiel Bräunling/Bodenschatz haben am Beispiel einer Fertigungs- und Montagedisposition in der Wälzlagerproduktion die Zweckmäßigkeit klassischer Optimierungsverfahren im Vergleich zu einem Expertensystem (XPS) untersucht. Im wesentlichen handelt es sich dabei um die Aufgabe, aus einer Vielzahl von Handlungsalternativen die optimale Alternative auszuwählen. Sie kommen zu folgendem Ergebnis: Mit einem XPS kann das Problem zwar schnell gelöst werden, doch verbessert sich die Qualität der Ergebnisse gegenüber dem bisherigen, manuellen Verfahren nicht. Kennt der menschliche Experte den Weg zum Optimum nicht, dann kann auch ein XPS die optimale Lösung nicht erreichen. Kann das Entscheidungsproblem als Lineares Programm (LP) modelliert werden, dann kann es mit Hilfe von Standard-LP-Software gelöst werden. Das LP-Modell zeichnet sich gegenüber dem XPS also dadurch aus, daß die ermittelte Lösung ein Optimum ist. Durch Verwendung von Standardsoftware entstehen gegenüber dem XPS-Ansatz auch geringere Entwicklungskosten. Darüber hinaus lassen sich mit dem LP-Modell mehrere Zielkriterien abbilden. Die Laufzeit für die Modellausführung ist auch auf Mikrocomputern akzeptabel. Leistungsfähige Standardsoftware ist verfügbar (z.B. XPRESS-MP von Dash Associates Inc.); die Lizenzkosten betragen bei einer Erstinstallation rd. 5.000.- DM. Aufgabenverweise Entwerfen des Methodensystems (Lerneinheit WMESY). Kontrollfragen 1. Was ist der Unterschied zwischen Realproblem und Formalproblem? 2. Welche Schwierigkeiten treten bei der Anwendung von Optimierungsmodellen auf? 3. In welche vier Arbeitsphasen kann der Entwurf des Methodensystems mit Optimierungsmodellen gegliedert werden? 4. Wie kann die Durchführung der Aufgabenanalyse in Arbeitsschritte gegliedert werden? 5. Welchen Zweck hat ein retrospektiver Test? Quellenliteratur Bräunling, P. und Bodenschatz, K.: Fertigungs- und Montagedisposition in der Wälzlagerproduktion mit Hilfe der Linearen Programmierung. In: WKISCHAFTSINFCRMAnK 1/1992, 3 8 - 5 1 Hillier, F. S. und Lieberman, G. J.: Operations Research - Einführung. 4. A., Oldenbourg Verlag, München/Wien 1988 Lassmann, W. und Schilar, H.: Ökonomie und Optimierung. Akademie-Verlag, Berlin 1985 Meyer, M. und Hanken, K.: Planungsverfahren des Operations Research. 3. A., Verlag Vahlen, München 1985 Müller-Merbach, H.: Die ungenutzte Synergie zwischen Operations Research und Wirtschaftsinformatik. In: WIRTSCHAFISINFORMATIK 3/1992, 334 - 339

PAORG - Prinzipien der Arbeitsorganisation Lernziele Sie kennen den Zweck der Prinzipien zum Gestalten der Arbeitsorganisation, insbesondere die Prinzipien soziotechnischer Systemgestaltung, das Prinzip der Partizipation, die Prinzipien der Aufgabengestaltung, das Prinzip der Aufgabenstrukturierung und das Prinzip des Handlungsspielraums. Sie kennen Erweiterungen bzw. Differenzierungen der Prinzipien soziotechnischer Systemgestaltung. Sie können die Prinzipien beim Entwerfen und Entwickeln der Arbeitsorganisation anwenden. Definitionen und Abkürzungen Aufgabenorientierung (task orientation) = das Gestalten der Arbeitsorganisation so, daß sie den Aufgabenträger bei der Aufgabendurchführung wirkungsvoll unterstützt. Einzelarbeit (single work) = die Bearbeitung einer Aufgabe durch einen einzelnen Aufgabenträger. Entscheidungsspielraum (décision scope) = der organisationstheoretische Aspekt des Handlungsspielraums, der das Ausmaß des Freiseins von organisatorischen Regelungen beschreibt. Synonym: Entscheidungskompetenz. Freiheitsspielraum (scope of freedom) = der sozial-psychologische Aspekt des Handlungsspielraums, der das Ausmaß des Freiseins von betrieblichen Normen beschreibt. Gruppenarbeit (group work) = die Bearbeitung einer Aufgabe durch mehrere Aufgabenträger. Handlungsspielraum (action scope) = das Konstrukt aus Entscheidungsspielraum, Freiheitsspielraum und Tätigkeitsspielraum; es beschreibt den Spielraum, den der Aufgabenträger beim Aufgabenvollzug hat. kognitiv (cognitive) = das Denken und Handeln des Menschen betreffend. MAT-System = Abkürzung für Mensch/Aufgabe/Technik-System. Partizipation (participation) = ein umfassender Begriff zur Bezeichnung der verschiedenen Ansätze der Teilnahme der Betroffenen an gesamt- und einzelwirtschaftlichen Entscheidungen. Prinzip (principie) = eine Regel oder eine Richtschnur für das Denken, Handeln und/oder Verhalten. soziotecbnisch (socio-technical) = die Eigenschaft eines Systems, neben betriebswirtschaftlichen und technischen auch soziale Ziele zu berücksichtigen. Tätigkeitsspielraum (activity scope) = der technische Aspekt des Handlungsspielraums, der das Ausmaß des Freiseins von technisch bedingten Regelungen oder von repetitiven Verrichtungen von Tätigkeiten beschreibt, vorgegebene Arbeitsorganisation (given work Organization) = die vom Management gewollte und implementierte Arbeitsorganisation. Synonym: objektive Arbeitsorganisation, wahrgenommene Arbeitsorganisation (percepted work Organization) = die von den Aufgabenträgern erlebte Arbeitsorganisation. Synonym: subjektive Arbeitsorganisation.

154

Methoden und Techniken der Grobprojektierung

Zweck der Prinzipien zum Gestalten der Arbeitsorganisation Zweck der Prinzipien zum Gestalten der Arbeitsorganisation ist es, generelle Handlungsanweisungen zu geben, welche das Entwerfen der Arbeitsorganisation (vgl. Lerneinheit WAORG) unterstützen. Sie gehen davon aus, daß das zu schaffende Informationssystem ein soziotechnisches System ("MAT-System") ist. Deshalb stehen die Prinzipien soziotechnischer Systemgestaltung und das Prinzip der Partizipation im Vordergrund. Darüber hinaus sind verschiedene Prinzipien der Aufgabengestaltung, das Prinzip der Aufgabenstrukturierung und das Prinzip des Handlungsspielraums von Bedeutung. Einige der Prinzipien scheinen trivial zu sein. Die Schwierigkeit liegt nicht darin, sie zu verstehen, sondern darin, sie anzuwenden. Zum Teil sind die Prinzipien wechselseitig miteinander verbunden und sich gegenseitig voraussetzend; teilweise überschneiden sie sich in ihren Aussagen. Da sie (noch) nicht als Methoden präzisiert sind, können sie den Systemplaner bestenfalls leiten. Sie sagen nichts darüber aus, wie man - bezogen auf eine konkrete Entwurfsaufgabe - zu einer guten Problemlösung gelangt. Prinzipien soziotechnischer Systemgestaltung Die Systemgestaltung ist soziotechnisch, wenn sie neben organisatorischen (betriebswirtschaftlichen und technischen) Zielen auch soziale und sozial-psychologische Ziele berücksichtigt. Im Ergebnis soll sie zu einem soziotechnischen System führen, das an die Anforderungen der Aufgabenträger angepaßt ist und das Entstehen von "Sachzwängen" vermeidet. Soziale und sozial-psychologische Ziele werden bei der Systemgestaltung mit berücksichtigt, wenn folgende Prinzipien beachtet werden: Relative Unabhängigkeit der Organisationseinheit, Übereinstimmung von Organisationseinheit und Arbeitsergebnis, Aufgabenzusammenhang in der Organisationseinheit, Selbstregulation der Organisationseinheit und Grenzregulation der Organisationseinheit durch den Vorgesetzten. • Relative Unabhängigkeit der Organisationseinheit: Arbeitsgruppen werden so gebildet, daß kleine soziale Einheiten entstehen, denen in Form der Gruppenzuordnung Aufgaben zugeordnet werden ("teilautonome Gruppen"); die Einzelzuordnung erfolgt durch Entscheidungen der Gruppenmitglieder (siehe auch "Prinzip der Aufgabenstrukturierung"). Zu vor- und nachgelagerten Organisationseinheiten sollen möglichst geringe Abhängigkeiten bestehen. Der Arbeitsprozeß (z.B. der Produktionsprozeß) muß daher in relativ unabhängige Teilprozesse zerlegt werden, die nicht streng verkettet, sondern modulartig vernetzt sind. • Übereinstimmung von Organisationseinheit und Arbeitsergebnis: Der Arbeitsablauf wird so gestaltet, daß das Arbeitsergebnis quantitativ und qualitativ der Organisationseinheit zugeordnet und daß dies für deren Mitglieder erkennbar ist. Inputs und Störfaktoren, die von anderen Organisationseinheiten kommen, müssen als solche erkennbar sein. • Aufgabenzusammenhang in der Organisationseinheit: Die in der Organisationseinheit zu verrichtenden Tätigkeiten weisen einen inhaltlichen Zusammenhang auf, der eine gegenseitige Unterstützung der Mitglieder der Organisationseinheit bei der Aufgabenerfüllung ermöglicht.

PAORG - Prinzipien der Arbeitsorganisation

155

• Selbstregulation der Organisationseinheit: Schwankungen und Störungen der Aufgabendurchführung werden in der Organisationseinheit, in der sie entstehen, aufgefangen; sie werden nicht unkontrolliert an andere Organisationseinheiten weitergegeben. Ungewißheiten über mögliche Schwankungen und Störungen werden dadurch weitgehend ausgeschaltet. • Grenzregulation durch den Vorgesetzten: Die Hauptaufgabe des Vorgesetzten besteht darin, die Unabhängigkeit der Organisationseinheit zu gewährleisten und die Beziehungen mit anderen Organisationseinheiten sicherzustellen. Direkte Eingriffe des Vorgesetzten in die Arbeit des Einzelnen sind dadurch nicht mehr nötig. Prinzip der Partizipation Partizipation ist nicht nur ein Prinzip zum Gestalten der Arbeitsorganisation, sondern auch ein Prinzip zum Gestalten der Informationsinfrastruktur insgesamt (vgl. Lerneinheit BEBET im Band "Informationsmanagement"). Die Bedeutung der Partizipation für das Gestalten der Arbeitsorganisation besteht insbesondere darin, soziale Ziele und sozial-psychologische Ziele in den Gestaltungsprozeß einzubringen und damit die Anwendung der Prinzipien soziotechnischer Systemgestaltung zu unterstützen. Im Ergebnis soll Partizipation beim Gestalten der Arbeitsorganisation helfen, Abweichungen zwischen vorgegebener Arbeitsorganisation und wahrgenommener Arbeitsorganisation zu vermeiden. Deshalb müssen beim Entwerfen der Arbeitsorganisation - so wie bereits beim Analysieren (vgl. Lerneinheit ZAMFS) beide Sichten auf die Arbeitsorganisation berücksichtigt werden. Die Nichtberücksichtigung der wahrgenommenen Arbeitsorganisation kann dazu führen, daß bei der Istzustandsanalyse erkannte Stärken nicht erhalten oder verbessert und erkannte Schwächen nicht beseitigt oder verringert werden. Prinzipien der Aufgabengestaltung Durch die Anwendung der Prinzipien der Aufgabengestaltung soll die Aufgabenorientierung der Arbeitsorganisation unterstützt werden. Die Berücksichtigung der Gestaltungsmerkmale Ganzheitlichkeit, Anforderungsvielfalt, Möglichkeit der sozialen Interaktion, Autonomie sowie Lern- und Entwicklungsmöglichkeiten kann die Aufgabenorientierung begünstigen. • Ganzheitlichkeit: Jeder Aufgabenträger soll die Bedeutung seiner Aufgabe im betrieblichen Aufgabensystem erkennen können. Es soll für ihn sichtbar werden, welchen Stellenwert seine Aufgabe für die Erreichung der Unternehmensziele hat. • Anforderungsvielfalt: Die Aufgabe soll dem Aufgabenträger die Möglichkeit geben, unterschiedliche Kenntnisse, Fähigkeiten und Fertigkeiten einzubringen. Dies wird am besten durch eine Durchmischung der Aufgabe mit planenden, durchführenden und kontrollierenden Tätigkeiten erreicht. • Soziale Interaktion: Durch soziale Interaktion soll den Aufgabenträgern die Möglichkeit gegeben werden, Erfahrungen auszutauschen und sich gegenseitig bei der Aufgabenerfüllung zu unterstützen. Durch soziale Interaktion werden

156

Methoden und Techniken der Grobprojektierung

auch Streßsituationen reduziert und Versuche zum Abbau potentieller Streßsituationen gefördert. • Autonomie: Jeder Aufgabenträger soll die Möglichkeit zur Selbstregulation von Schwankungen und Störungen, die im Prozeß der Aufgabenerfüllung auftreten können, haben. Die Autonomie soll nicht durch unnötige, nicht begründbare Regelungen und technische "Sachzwänge" eingeschränkt werden. • Lern- und Entwicklungsmöglichkeiten: Die Aufgabe soll es jedem Aufgabenträger ermöglichen, mit der Aufgabenerfüllung zu lernen und sich weiter zu entwickeln. Alle zuvor genannten Gestaltungsmerkmale wirken auf die Lern- und Entwicklungsmöglichkeiten ein. Über die Beachtung der genannten Merkmale hinausgehend, sollen die folgenden Prinzipien der Aufgabengestaltung beachtet werden: • Prinzip der flexiblen Aufgabengestaltung: Erfahrungsgemäß gibt es für die gleiche Aufgabe interindividuell (verschiedene Aufgabenträger) und häufig auch intraindividuell (verschiedene Situationen des gleichen Aufgabenträgers) unterschiedliche, nach betriebswirtschaftlichen und technischen Zielen (z.B. Wirtschaftlichkeit und Wirksamkeit) nicht notwendigerweise schlechter zu bewertende Vorgehensweisen bei der Aufgabenerfüllung. Das strikte Vorschreiben einer bestimmten, als optimal angesehenen Arbeitsorganisation kann zu unwirtschaftlicher bzw. unwirksamer Arbeitsweise führen. Die Arbeitsorganisation soll daher so flexibel sein, daß sie Raum für unterschiedliche Arbeitsweisen bietet. • Prinzip der differentiellen Aufgabengestaltung: Die Aufgabengestaltung ist differentiell, wenn mehrere, vom Aufgabenträger alternativ verwendbare Arbeitsweisen für die Aufgabenerfüllung vorgegeben werden. Alternative Arbeitsweisen sollen der Entwicklung der Persönlichkeit des Aufgabenträgers und der Auseinandersetzung mit der Arbeitsaufgabe dienen. Die interindividuellen und intraindividuellen Unterschiede führen zu der Forderung nach differentiell-dynamischer Gestaltung der Arbeitsorganisation. Prinzip der Arbeitsstrukturierung Die Anwendung des Prinzips der Arbeitsstrukturierung zielt darauf ab, die Arbeitsorganisation unter Berücksichtigung der kognitiven Mechanismen der Aufgabenträger, die zur erfolgreichen Aufgabenerfüllung eingesetzt werden, zu gestalten und die Auswirkungen des tayloristischen Prinzips der Trennung von regulativen und ausführenden Tätigkeiten aufzuheben oder zumindest zu reduzieren. Maßnahmen der Arbeitsstrukturierung sind: Aufgabenerweiterung (auch: Arbeitserweiterung), Aufgabenbereicherung (auch: Aufgabenanreicherung oder Arbeitsbereicherung), Aufgabenwechsel (auch: Tätigkeitswechsel) und teilautonome Gruppe (auch: selbststeuernde oder selbstverwaltende Gruppe). • Aufgabenerweiterung: Der Aufgabeninhalt wird aus mehreren gleichartigen oder ähnlichen (z.B. durchführenden) Tätigkeiten gebildet und dem Aufgabenträger zugeordnet (horizontale Dimension des Aufgabeninhalts). Durch Aufgabenerweiterung wird nur die Ablauforganisation verändert, während die Aufbauorganisation (Stellenbildung) im wesentlichen unverändert bleibt.

PAORG - Prinzipien der Arbeitsorganisation

157

• Aufgabenbereicherung: Der Aufgabeninhalt wird aus mehreren verschiedenartigen (z.B. durchführende und planende) Tätigkeiten gebildet und dem Aufgabenträger zugeordnet (vertikale Dimension des Aufgabeninhalts). Die Aufgabe soll auch kognitive Tätigkeiten im Sinn von Denkleistungen mit antizipatorischen Anforderungen umfassen. Aufgabenbereicherung verändert die Ablauforganisation und die Aufbauorganisation (Stellenbildung). • Aufgabenwechsel: Arbeitserweiterung und Arbeitsbereicherung können mit unterschiedlichen Varianten des Aufgabenwechsels, bei dem die Aufgabenzuordnung verändert wird, kombiniert werden. Der Aufgabenwechsel kann auf Grund vorgegebener organisatorischer Regelungen oder - in teilautonomen Gruppen - durch Entscheidungen der Aufgabenträger selbst erfolgen. • Teilautonome Gruppe: Das Prinzip Einzelzuordnung "one man, one task" wird durch das Prinzip der Gruppenzuordnung ersetzt, und die Einzelzuordnung erfolgt innerhalb der Gruppe nach den Bedürfnissen der Gruppenmitglieder.

Tätigkeitsspielraum

Freiheitsspielraum

Abb. PAORG-1: Handlungsspielraum als Konstrukt (Quelle: Müller-Böling)

Prinzip des Handlungsspielraums Der Handlungsspielraum ist ein mehrdimensionales Konstrukt, das aus Entscheidungsspielraum, Tätigkeitsspielraum und Freiheitsspielraum besteht (Abbildung PAORG-1). • Entscheidungsspielraum: Unter organisationstheoretischen Gesichtspunkten ist der Handlungsspielraum Entscheidungsspielraum und meint das Ausmaß des Freiseins des Aufgabenträgers von organisatorischen Regelungen oder die Möglichkeit des Aufgabenträgers, nicht vorhandene organisatorische Regelungen durch eigene Entscheidungen zu ersetzen. Damit beschreibt der Entscheidungsspielraum das Ausmaß an Autonomie, das ein Aufgabenträger zum Gestalten der Aufgabendurchführung besitzt. • Tätigkeitsspielraum: Unter technischen Gesichtspunkten ist der Handlungsspielraum Tätigkeitsspielraum und meint das Ausmaß des Freiseins des Aufgabenträgers von technisch bedingten Regelungen oder von repetitiven Verrichtungen von Tätigkeiten. Er beschreibt die Möglichkeiten des Aufgabenträgers

158

Methoden und Techniken der Grobprojektierung

zu unterschiedlichem aufgabenbezogenen Handeln in bezug auf die Arbeitsverfahren (z.B. die Wahl zwischen alternativen Tätigkeitsfolgen), den Einsatz von Arbeitsmitteln (z.B. die Wahl zwischen alternativen Kommunikationsmitteln) und die zeitliche Anordnung der Tätigkeiten. • Freiheitsspielraum: Unter sozial-psychologischen Aspekten ist der Handlungsspielraum Freiheitsspielraum und meint das Ausmaß des Freiseins des Aufgabenträgers von betrieblichen sozialen Normen. So wie beim Prinzip der Partizipation, kommt es beim Prinzip des Handlungsspielraums letztlich nicht auf den vorgegebenen Handlungsspielraum ("objektiver Handlungsspielraum"), sondern auf den vom Aufgabenträger wahrgenommenen Handlungsspielraum ("subjektiver Handlungsspielraum") an. Beim Gestalten der Arbeitsorganisation soll - in Abhängigkeit von der Aufgabe und vom Aufgabenträger - ein ausreichender Umfang an wahrgenommenem Handlungsspielraum vorhanden sein, der sowohl die Aufgabenorientierung sicherstellt, als auch zur Aufgabenerfüllung motiviert. Dabei soll der Handlungsspielraum sowohl beim Gestalten der Interaktionsaufgabe (z.B. durch verschiedene Dialogformen), als auch beim Gestalten der Sachaufgabe (z.B. durch verschiedene Vorhersagemethoden bei der Sachaufgabe "Bedarfsvorhersage") berücksichtigt werden. Bedeutung hat der Handlungsspielraum auch für die Entwicklung der Persönlichkeit des Aufgabenträgers. Erweiterung soziotechnischer Prinzipien Cummings/Blumberg erweitern bzw. differenzieren die soziotechnischen Prinzipien durch die Formulierung von technik-, umweit- und personbezogenen Kontingenzen. Die zwei technologischen Schlüsselmerkmale, die den Erfolg der Arbeitsgestaltung beeinflussen können, werden als technische Verkopplung ("technical interdependence") und technische Ungewißheit ("technical uncertainty") bezeichnet. Technische Verkopplung meint das Ausmaß, in dem die Technologie zur Erstellung eines Produkts oder einer Dienstleistung Kooperation zwischen den Aufgabenträgern erfordert. Das Ausmaß an technischer Verkopplung bestimmt, ob Arbeit als Einzelarbeit oder als Gruppenarbeit gestaltet werden soll. Wenn der Grad der technischen Verkopplung niedrig ist und wenig Notwendigkeit zur Kooperation besteht, sollen die Arbeitsaufgaben als Einzelarbeit gestaltet werden. Weist dagegen die technische Verkopplung einen hohen Grad auf, sollen die Arbeitsaufgaben als Gruppenarbeit gestaltet werden. Technische Ungewißheit bezeichnet das Ausmaß von Anforderungen zur Verarbeitung von Information und zum Treffen von Entscheidungen, die für die Aufgabenträger im Prozeß der Aufgabenerfüllung entstehen. Der Grad an technischer Ungewißheit entscheidet darüber, ob die Wahrnehmung von Kontrollfunktionen Bestandteil der Aufgabe ist oder von außen (z.B. durch Vorgesetzte) erfolgt. Wenn der Grad der technischen Ungewißheit niedrig ist und kaum Informationsverarbeitung erfordert, soll externe Kontrolle vorgesehen werden. Ist der Grad der technischen Ungewißheit dagegen hoch, sollen Kontroll- und Entscheidungsfunktionen den Aufgabenträgern übertragen werden. Das für die Arbeitsgestaltung relevante Umweltmerkmal betrifft den Grad der Umweltstabilität bzw. Umweltlabilität; es wird als Umweltdynamik ("environmental dynamics") bezeichnet. Jedes soziotechnische System unterhält Austausch-

PAORG - Prinzipien der Arbeitsorganisation

159

beziehungen zu seiner Umwelt. Die Dynamik der Umwelt ist mitbestimmend dafür, wie Arbeit gestaltet werden soll, um die Austauschbeziehungen adäquat regulieren zu können. Wenn die Umwelt relativ stabil ist, kann der Austausch in standardisierter Weise erfolgen. Arbeitsabläufe können dann routinisiert sein. Ist die Umwelt eher labil und sind ihre Veränderungen nur schlecht vorhersehbar, erfordert die Abwicklung der Austauschbeziehungen eine flexible Anpassung an wechselnde Anforderungen. In diesem Fall muß ein hohes Ausmaß an Informations- und Entscheidungsprozessen Bestandteil der Aufgabe sein. Zu den für die Arbeitsgestaltung relevanten Personenmerkmalen zählen das Bedürfnis nach lohnenden sozialen Beziehungen ("desire for significant social relationship") und das Bedürfnis nach persönlicher Entfaltung ("desire for personal accomplishment, learning, and development"). Das Ausmaß an sozialen Bedürfnissen ist für die Beantwortung der Frage bedeutsam, ob Aufgaben als Einzelarbeit oder als Gruppenarbeit gestaltet werden sollen. Das Ausmaß an Entfaltungsbedürfnissen entscheidet über den Grad der Arbeitsteilung bzw. der Ganzheitlichkeit von Arbeitsaufgaben. Technische Verkop plung GestaltungsNiedrig Hoch konzepte Traditionelle X Einzelarbeit Traditionelle X Gruppenarbeit Individuelle AufgabenX erweitemng SelbstX regulierende Gruppe

Technische Ungewißheit Niedrig Hoch

Umweltdynamik Niedrig

Hoch

Entfaltungsbedürfnisse Niedrig Hoch

X

X

X

X

X

X

Soziale Bedürfnisse Niedrig Hoch X X

X

X

X

X

X

X

X X

Abb. PAORG-2: Gestaltungskonzepte und ihre Kontingenzen (Quelle: nach Cummings/Blumberg)

Abbildung PAORG-2 zeigt die Beziehungen der erläuterten Merkmale zu vier "reinen" Formen der Arbeitsgestaltung. Folgende Aussagen lassen sich daraus ableiten: • Die Aufgabengestaltung im Sinn traditioneller Einzelarbeit kann zum Erfolg führen, wenn sowohl technische Verkopplung und technische Ungewißheit als auch Entfaltungsbedürfnisse und soziale Bedürfnisse eine schwache Ausprägung haben und die Umweltdynamik eher niedrig ist. • Traditionelle Gruppenarbeit mit weitgehender Arbeitsteilung ist besonders effektiv, wenn der Grad der technischen Verkopplung hoch, aber die technische Ungewißheit niedrig ist, und zwar bei stabiler Umwelt, geringem Wunsch nach persönlicher Entfaltung, aber stark ausgeprägten sozialen Bedürfnissen. • Das Konzept der individuellen Aufgabenerweiterung mit hoher Anforderungsvielfalt, Autonomie und Rückkopplung verspricht dort Erfolg, wo geringe technische Verkopplung bei hoher technischer Ungewißheit und hoher Umweltdynamik vorliegt, und zwar bei starkem Wunsch nach persönlicher Entfaltung, aber gering ausgeprägten sozialen Bedürfnissen.

160

Methoden und Techniken der Grobprojektierung

• Selbstregulierende Gruppen sind dann besonders erfolgreich, wenn technische Verkopplung und technische Ungewißheit eine hohe Ausprägung haben, starke Bedürfnisse nach persönlicher Entfaltung und sozialer Interaktion vorliegen und die Umwelt nur wenig stabil ist. Strategien beim Anwenden der Prinzipien Die Prinzipien zum Gestalten der Arbeitsorganisation können mit drei alternativen Strategien angewendet werden: Korrigierende Strategie, vorbeugende Strategie und vorhersehende Strategie. • Die korrigierende Strategie geht davon aus, daß die bestehende Arbeitsorganisation soziotechnische Defizite aufweist, die im Sinn einer Reorganisation beseitigt werden. • Die vorbeugende Strategie berücksichtigt die soziotechnischen Gestaltungsprinzipien bereits beim Entwerfen der Arbeitsorganisation und versucht, mögliche soziotechnische Defizite zu vermeiden. Sie erfordert die Berücksichtigung interindividueller Unterschiede zwischen den Aufgabenträgern. • Die vorhersehende Strategie geht über die vorbeugende Strategie hinaus, indem sie versucht, die Arbeitsorganisation so zu gestalten, daß neben der Vermeidung von soziotechnischen Defiziten die Entwicklung der Persönlichkeit der Aufgabenträger gefördert wird. Sie erfordert die Berücksichtigung interindividueller Unterschiede zwischen den Aufgabenträgern und die Berücksichtigung intraindividueller Unterschiede der Aufgabenträger. Forschungsbefunde Frese/Zapf stellen auf Grund einer Längsschnittuntersuchung (Untersuchungszeitraum 1977 bis 1985) fest, daß durch die Einführung neuer Technologien der Handlungsspielraum (sowie die Qualifikationsanforderungen und Stressoren) kaum verändert wird. Untersucht wurden die Arbeitsplätze von fünf Personengruppen, und zwar: 1) Arbeitsplätze, die keine neue Technologie verwenden; 2) Arbeitsplätze, an denen mit Computerunterstützung gearbeitet wird, an denen die Mitarbeiter aber nicht selbst programmieren; 3) Arbeitsplätze, an denen mit Computerunterstützung gearbeitet wird und an denen die Mitarbeiter einen Einfluß auf die Programmierung haben; 4) Arbeitsplätze, an denen mit Computerunterstützung gearbeitet wird und an denen die Mitarbeiter selbst programmieren; 5) Arbeitsplätze, die mit Industrierobotern ausgestattet sind. Alle Arbeitsplätze befinden sich im Fertigungsbereich. Die von den Autoren festgestellten, nur geringen Veränderungen widersprechen fast allen bisherigen Befunden. Dabei sind die Aussagen insofern nicht einheitlich, als teilweise über positive, teilweise über negative Auswirkungen des Computereinsatzes auf den Handlungsspielraum berichtet wird. Nach Frese/Zapf hatten z.B. die Mitarbeiter an Roboterarbeitsplätzen mit einem geringen Handlungsspielraum vorher auch Arbeitsplätze mit einem geringen Handlungsspielraum. Umgekehrt hatten die Mitarbeiter mit einem relativ großen Handlungsspielraum an technologieunterstützten Arbeitsplätzen, bereits vorher Arbeitsplätze mit einem relativ großen Handlungsspielraum. So wie es also vor der Einführung neuer Technologien Arbeitsplätze mit geringem und Arbeitsplätze mit großem Handlungsspielraum gab, gibt es diese auch nach der Einführung neuer Technologien. Die Autoren weisen darauf

PAORG - Prinzipien der Arbeitsorganisation

161

hin, daß ihre Ergebnisse lediglich den Istzustand wiedergeben; sie können also nicht als Argument dafür benutzt werden, daß Alternativen nicht möglich und technisch nicht realisierbar sind. Cummings/Blumberg zeigen anhand von Fallstudien, daß durch moderne Technologien sowohl der Grad der technischen Verkopplung als auch die technische Ungewißheit und die Umweltdynamik beträchtlich erhöht werden. Daraus leiten die Autoren die Empfehlung ab, Arbeit als selbstregulierende Gruppe zu organisieren. Die Gruppe soll aus Mitarbeitern mit vielfältigen Fähigkeiten bestehen, welche die technischen und umweltbedingten Veränderungen erfolgreich steuern können. Daraus wird die Schlußfolgerung gezogen, daß nachhaltige Veränderungen bei der Personalauswahl, der Personalschulung, den Entlohnungssystemen und anderen Einflußfaktoren erforderlich sein werden. Aufgabenverweise Entwerfen des Methodensystems (Lerneinheit WMESY); Entwerfen der Arbeitsorganisation (Lerneinheit WAORG). Kontrollfragen 1. 2. 3. 4. 5.

Welchem Zweck dienen die Prinzipien zum Gestalten der Arbeitsorganisation? Welche Prinzipien soziotechnischer Systemgestaltung gibt es? Welche Bedeutung hat die Partizipation beim Gestalten der Arbeitsorganisation? Worin bestehen die Unterschiede zwischen den Maßnahmen der Arbeitsstrukturierung? Mit welchen Strategien können die Prinzipien zum Gestalten der Arbeitsorganisation umgesetzt werden?

Quellenliteratur Bartölke, K.: Teilautonome Arbeitsgruppen. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Poeschel Verlag, Stuttgart 1992, 2384 - 2399 Spinas, P. et al.: Leitfaden zur Einführung und Gestaltung von Arbeit mit Bildschirmsystemen. Verlag CW-Publikationen und Verlag Industrielle Organisation, München und Zürich 1983 Ulich, E.: Arbeitspsychologie. 2. A., Verlag der Fachvereine und Poeschel Verlag, Zürich bzw. Stuttgart 1992 Ulich, E.: Arbeits- und organisationspsychologische Aspekte. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988,49 - 66 Vertiefungsliteratur Ackermann, D.: Handlungsspielraum, mentale Repräsentation und Handlungsregulation am Beispiel der Mensch-Computer-Interaktion. Dissertation Universität Bern, Bern 1987 Alioth, A.: Entwicklung und Einführung alternativer Arbeitsformen. Schriften zur Arbeitspsychologie Bd. 27, Verlag Huber, Bern 1980 Bullinger, H.-J. (Hrsg.): Software-Ergonomie '85 - Mensch-Computer-Interaktion. Berichte des German Chapter of the ACM Bd. 24, Verlag Teubner, Stuttgart 1985 Cummings and Blumberg: Advanced Manufacturing Technology and Work Design. In: Clegg, T. W. and Kemps, M.: Human Fight of Advanced Manufacturing Technology, 37 - 60; zitiert nach Ulich, E.: Arbeitspsychologie. 2. A., Verlag der Fachvereine und Poeschel Verlag, Zürich bzw. Stuttgart 1992, 205 (bibliographische Angaben unvollständig) Frese, M. und Zapf, D.: Die Einführung von neuen Techniken verändert Qualifikationsanforderungen, Handlungsspielraum und Stressoren kaum. In: Zeitschrift für Arbeitswissenschaft 1/1987, 7 - 14 Ulich, E.: Différentielle Arbeitsgestaltung. In: Zeitschrift für Arbeitswissenschaft 1/1983,12- 15

PINTE - Integrationsprinzipien Lernziele Sie erkennen den Umfang und die Bedeutung der Integration in einzelwirtschaftlicher und in gesamtwirtschaftlicher Hinsicht. Sie können die Integration in Integrationsformen gliedern und den Integrationsformen geeignete Integrationsmaßnahmen zuordnen. Sie erkennen den noch unbefriedigenden Stand der Forschung auf diesem Gebiet, der deuüich macht, daß die explizite Angabe von Integrationsprinzipien nicht möglich ist. Definitionen und Abkürzungen Arbeitszufriedenheit (job satisfaction) = ein emotional erlebter Zustand des Bewußtseins, der mit der Erfüllung von Erwartungen bzw. mit der Hoffnung auf deren Erfüllung zusammenhängt. Desintegration (disintegration) = das Gegenteil von Integration. Durchlaufzeit (throughput time) = die Zeit, die ein Objekt in einem System verbringt, gemessen vom Zeitpunkt des Systemeintritts bis zum Zeitpunkt des Systemaustritts. innerbetriebliche Integration (inhouse integration) = die Phänomene der Integration und die daraus resultierenden systematischen Vorgehensweisen beim Systementwurf in einzelnen Wirtschaftseinheiten. Integration (integration) = eine spezifische Form der Verknüpfung von Elementen zum Ganzen eines Systems. Integrationsform (integration mode) = das Objekt, auf welches sich die Maßnahmen der Integration beziehen (z.B. Datenintegration). Integrationsprinzip (integration principle) = eine Regel oder eine Richtschnur für das Schaffen von Integration. Integrationswirkung (impact of integration) = die ökonomischen, technischen und sozialen Konsequenzen der Integration. Komplexität (complexity) = der Zustand eines Systems, der durch die Anzahl unterscheidbarer Relationen zwischen seinen Subsystemen beschrieben wird. Kompliziertheit (difficulty) = der Zustand eines Systems, der durch die Anzahl seiner Subsysteme beschrieben wird, organisatorische Integration (organizational integration) = die zusammenfassende Bezeichnung für Datenintegration, Funktionsintegration, Vorgangsintegration, Kommunikationsintegration und Sicherungsintegration, technische Integration (technical integration) = die Integration innerhalb einzelner Techniksysteme oder zwischen mehreren Techniksystemen. Vorgang (trigger) = eine zeitbeanspruchende Tätigkeit mit einem definierten Anfang und einem definierten Ende. Zuverlässigkeit (reliability) = die Fähigkeit eines Systems, die durch die Aufgabenstellung bedingten Funktionen mit einer definierten Wahrscheinlichkeit auszuführen. zwischenbetriebliche Integration (interorganizational integration) = die Phänomene der Integration und die daraus resultierenden systematischen Vorgehensweisen beim Systementwurf zwischen mehreren Wirtschaftseinheiten.

PINTE - Integrationsprinzipien

163

Integration und Integrationsprinzipien Im allgemeinen Sprachgebrauch wird unter Integration die Herstellung oder die Wiederherstellung eines Ganzen durch Vereinigen oder Verbinden logisch zusammengehöriger Teile verstanden (entweder als Vorgang oder als Ergebnis). In der an die Systemtechnik angelehnten Terminologie der Wirtschaftsinformatik handelt es sich um eine spezifische Form der Verknüpfung von Elementen zum Ganzen eines Systems. Die Ausrichtung der einzelnen Elemente auf den Zweck des Systems erfolgt in der Weise, daß Veränderungen eines Elements nicht auf dieses beschränkt bleiben, sondern sich auch auf die anderen Elemente des Systems auswirken (dynamisches System) und damit auf das System insgesamt. Bei einem offenen System wirken die Veränderungen auch auf das Umsystem. Im Zusammenhang mit der Systemplanung hat der Integrationsbegriff eine Reihe spezifischer Ausprägungen erhalten, die sich im Laufe der Zeit - insbesondere in Abhängigkeit von der Entwicklung der Informations- und Kommunikationstechnik - inhaltlich gewandelt und auch stark erweitert haben, sodaß eine präzise Erklärung von Integration mit der Ausrichtung auf Informations- und Kommunikationssysteme nur anhand einer Reihe von enger abgegrenzten Begriffsinhalten möglich ist ("Integrationsformen"). Dies ist gleichzeitig Voraussetzung dafür, aus dem Verständnis von Integration heraus Handlungsempfehlungen für den Systementwurf entwickeln zu können, welche methodisch gesehen zwar nur den Charakter von Heuristiken haben, den Systementwurf aber dennoch unterstützen können ("Integrationsprinzipien"). Zur Lösung dieser Erklärungsaufgabe und der Entwicklungsaufgabe für Integrationsprinzipien wird zunächst zwischen den beiden Phänomenen "technische Integration" und "organisatorische Integration" unterschieden und das Verhältnis beider zueinander geklärt. Daran anschließend wird auf die Wirkungen der Integration eingegangen. Technische Integration Bei der technischen Integration handelt es sich um die Integration der Techniksysteme, im einzelnen: • um die Integration innerhalb einzelner Techniksysteme bzw. um die Verbesserung der innerhalb einzelner Techniksysteme bestehenden Integration; • um die Integration zwischen einzelnen Techniksystemen bzw. - in Fortsetzung dieses Ansatzes - um die Schaffung von Obersystemen, die mehrere Techniksysteme zu einem umfassenderen, integrierten Gesamtsystem verknüpfen. Die Entwicklung der Informations- und Kommunikationstechnik kann als ein Prozeß der fortschreitenden technischen Integration aufgefaßt werden; er wird sich auch in Zukunft fortsetzen. Dies führt beispielsweise dazu, daß Techniksysteme für die Eingabe, den Transport und die Ausgabe zur Verfügung stehen werden, die sowohl für Daten und Text als auch für Bild und Sprache geeignet sind. Aus der Sicht des Benutzers führt die technische Integration vom Arbeitsplatz mit einer Menge von Techniksystemen, deren Zusammenwirken der Benutzer selbst bewältigen muß (Abbildung PINTE-1, linker Teil), zum mehrfunk-

164

Methoden und Techniken der Grobprojektierung

tionalen Arbeitsplatz (Abbildung PINTE-1, rechter Teil). Die technische Integration ist heute weitgehend verwirklicht (z.B. die Integration von Telefon mit Anrufbeantworter und Fax-Maschine mit der Möglichkeit der Fernabfrage). Sie allein eröffnet dem Anwender allerdings nur geringe Nutzenpotentiale.

Fernkopierer Fernschreiber Mikrofilm

Mit einem Gerät • Schreiben • Ablegen • Wiederfinden

Datensichtgerät

Posteingang Postausgang

Drucker

Kopierer

{

Telefon Telefax Bildschirmtext Elektronische Post Büroanwendungen Zugriff auf DV Senden Empfangen

Abb. PINTE-1: Wirkung der technischen Integration aus der Sicht des Arbeitsplatzes (Quelle: Siemens)

Organisatorische Integration Bei der organisatorischen Integration handelt es sich um die Integration der betrieblichen Aufgaben im Aufgabensystem, im einzelnen: • um die Integration der Daten in einem einheitlichen Datensystem ("Datenintegration", vgl. Lerneinheiten WDASY und EDASY); • um die Integration der Methoden in einem einheitlichen Methodensystem ("Methodenintegration", "Funktionsintegration", vgl. Lerneinheiten WMESY und EMESY); • um die Integration der Bearbeitungsvorgänge in der Arbeitsorganisation ("Vorgangsintegration", vgl. Lerneinheiten WAORG und EAORG); • um die Integration der Kommunikation in einem einheitlichen Transportsystem ("Kommunikationsintegration", vgl. Lerneinheiten WTRAN und ETRAN); • um die Integration der Maßnahmen zur Systemsicherung in einem einheitlichen Sicherungssystem ("Sicherungsintegration", vgl. Lerneinheiten WSICH und ESICH). Zwischen den Objekten der organisatorischen Integration bestehen Beziehungen in der Weise, daß eine Integrationsform nur dann umgesetzt werden kann, wenn

PINTE - Integrationsprinzipien

165

eine andere Integrationsform realisiert wurde (z.B. ist Datenintegration Voraussetzung für Vorgangsintegration). Funktionsintegration hat zwei Erscheinungsformen. Entweder wird sie dadurch bewirkt, daß das Ergebnis der Bearbeitung einer Funktion die Bearbeitung einer anderen Funktion anstößt ("triggert"), oder dadurch, daß zwei (oder mehr) Funktionen zu einer neuen, umfassenderen Funktion vereinigt werden. Die entscheidende ablauforganisatorische Auswirkung ist in beiden Fällen die Verkürzung bzw. Vermeidung der Liegezeit, im zweiten Fall auch die Vermeidung von Transportzeit. Eine Konsequenz dieser primär ablauforganisatorischen Integrationsformen ist die Möglichkeit oder sogar die Notwendigkeit der aufbauorganisatorischen Integration. Beispielsweise verändert der Einsatz integrierter CAD/CAM-Systeme die Zuordnung von Arbeitsaufgaben auf Aufgabenträger so, daß mehrere traditionelle Stellenbilder (z.B. Auftragsklärung, Konstruktion, technisches Zeichnen, Arbeitsvorbereitung, Werkstattsteuerung und Steuerung der Betriebsmittel) verschwinden und ein neues Stellenbild entsteht. Darüber hinaus können Aufgabenzuordnungen auf Abteilungen (im Beispiel Marketing, Vertrieb, Konstruktion und Produktion) unzweckmäßig werden. Die bestehende Aufbauorganisation muß geändert werden. An diesem Beispiel werden auch die Beziehungen, die zwischen technischer und organisatorischer Integration bestehen, erkennbar. Horizontale, vertikale und diagonale Integration Mit horizontal, vertikal und diagonal werden die Dimensionen der Integration bezeichnet. Horizontale Integration liegt vor, wenn Aufgaben vereinigt oder verbunden werden, die Gegenstand eines Informationsverarbeitungskomplexes, aber verschiedener Teilsysteme sind (z.B. Fakturierung, Bestandsführung, Lohnabrechnung und Provisionsabrechnung innerhalb des Komplexes "Abrechnung"). Vertikale Integration liegt vor, wenn Aufgaben verschiedener Informationsverarbeitungskomplexe vereinigt oder verbunden werden, wobei man sich innerhalb bestimmter Teilsysteme bewegt (z.B. Planung, Überwachung, Steuerung, Abrechnung und Analyse der Lagerwirtschaft). Umfassende Integrationsmaßnahmen zielen gleichzeitig in beide Dimensionen, was als diagonale Integration bezeichnet wird (z.B. wird in einem CAD/CAM-System sowohl horizontal als auch vertikal integriert). Damit werden die in Fertigungsbetrieben üblichen Grenzen zwischen dem Büro- und Verwaltungsbereich einerseits und dem Produktionsbereich andererseits aufgehoben. Informationswirtschaftliche Integration Die bisherigen Erläuterungen zeigen, daß die innerbetriebliche Integration zunächst nur eine Frage der Systemplanung ist, wenn auch mit wesentlichen Auswirkungen auf ihr Umfeld (z.B. auf die Aufbauorganisation). Die Bedeutung des Produktionsfaktors Information und Kommunikation für die Organisation insgesamt macht aber auch eine Einbindung informationswirtschaftlicher Überlegungen in die Unternehmensführung notwendig ("informationsorientierte Unternehmensführung"). Phänomene der informationswirtschaftlichen Integration sind (wegen Einzelheiten vgl. den Band "Informationsmanagement"):

166

Methoden und Techniken der Grobprojektierung

• die Kommunikation zwischen Top-Management und Linienmanagement auf der einen und den "Datenverarbeitungsspezialisten" auf der anderen Seite; • das Bewußtsein des Top-Managements für das informationswirtschaftliche Leistungs- und Kostenpotential; • die organisatorische Gestaltung und Einbindung aller Stellen und Aufgabenträger, denen Aufgaben der Informationsfunktion zugeordnet sind (Strukturorganisation der Informationsfunktion). Innerbetriebliche und zwischenbetriebliche Integration Aus der Einbettung eines Unternehmens in seine Umwelt, bei Betriebswirtschaften insbesondere aus den Beziehungen des Unternehmens zu Kunden und Lieferanten und den daraus resultierenden Kommunikationsbeziehungen, ergibt sich die Erweiterung des innerbetrieblichen Integrationsfeldes um das zwischenbetriebliche Integrationsfeld. Die zwischenbetriebliche Integration verbindet mehrere Informationssysteme verschiedener Unternehmen (vgl. auch Lerneinheiten WTRAN und ETRAN). Abbildung PINTE-2 gibt einen Überblick über die Integrationsformen. Systemintegration

informationswirtschaftliche Integration

ablauforganisatorische Integration

1 horizontale Integration

vertikale Integration

strukturorganisatorische Integration

1 diagonale Integration

DatenKommunikations- Sicherungs- Methoden- Vorgangsintegration integration integration integration integration Abb. PINTE-2: Integrationsformen

Technische Integration und organisatorische Integration Das Verhältnis zwischen der technischen Integration und der organisatorischen Integration kann so beschrieben werden: Die technische Integration schafft die Potentiale für die organisatorische Integration. Dies zeigt die Entwicklung der Informations- und Kommunikationstechnik. Zunächst erzwang ihr Einsatz, der vornehmlich unter ökonomischen Zielen (und hier insbes. unter dem Ziel "Produktivität") erfolgte, vorhandene Aufgabenzusammenhänge durch eine tayloristische Arbeitsteilung aufzulösen ("Desintegration"). Insbesondere erfolgte die Desintegration der Aufgabenfunktionen (z.B. von Datenerfassung und Datenbearbeitung). Später wurden zunehmend Integrationspotentiale eröffnet, beispielsweise

P1NTE - Integrationsprinzipien

167

durch die Entwicklung von Online-Systemen, von Datenbank- und Methodenbanksystemen und von Lokalen Netzen. Die heutige Situation ist dadurch gekennzeichnet, daß die durch den Stand der Techniksysteme eröffneten Integrationspotentiale nur unvollständig ausgeschöpft werden. Integrationswirkungen Für die Entwicklung von Integrationsprinzipien sind Informationen über die Konsequenzen von Integrationshandlungen erforderlich. Diese Informationen sind möglichst zu quantifizieren und daraufhin zu überprüfen, ob sie die Erreichung der Planungsziele unterstützen. Die Konsequenzanalyse kann sich - in Ermangelung aussagefähiger Forschungsergebnisse - im wesentlichen nur auf Erfahrungswissen stützen, mit dem die verschiedenen Integrationswirkungen, die zum Teil widersprüchlich sind, beschrieben werden. Im folgenden werden einige Integrationswirkungen angegeben. • Zunehmende Komplexität und Kompliziertheit: Da Integration Teile zu einem größeren Ganzen verbindet oder vereinigt, wächst der Umfang des betrachteten Systems und damit - ceteris paribus - die Komplexität und die Kompliziertheit des Systems. Dem muß beim Systementwurf durch eine geeignete Zerlegung des Systems und durch die Definition von Schnittstellen begegnet werden. • Steigerung der Wirtschaftlichkeit: Integration beseitigt Schnittstellen, die erfahrungsgemäß wirtschaftlichkeitsmindernd wirken (z.B. durch das mehrmalige Aufnehmen von Daten, durch Redundanz im Datensystem und durch Verlängerung der Durchlaufzeit). • Erhöhung der Zuverlässigkeit: Insbesondere die genannten Schnittstellen sind durch eine hohe Fehlerrate gekennzeichnet, in erster Linie durch Einflüsse des "unzuverlässigsten Systemelements", nämlich des Menschen als Aufgabenträger. Dies gilt insbesondere für die Aufgabenfunktion Eingeben (z.B. das Eingeben von Daten). • Verbesserung der Arbeitszufriedenheit: Die Ausschöpfung des Integrationspotentials unter sozialen Zielen ermöglicht eine Arbeitsorganisation, die durch weniger Arbeitsteilung gekennzeichnet ist. Insbesondere sind arbeitsbereichernde Maßnahmen (Aufgabenbereicherung) möglich, wodurch die Arbeitszufriedenheit erhöht werden kann. • Erhöhung der Qualifikationsanforderungen: Die Integration mehrerer Arbeitsvorgänge an einem Arbeitsplatz erfordert eine höhere Qualifikation des Personals. Maßnahmen zur Qualifizierung des Personals sind also flankierend zur Integration erforderlich. • Verstärkung des Rationalisierungsdrucks: Integration in einem Unternehmen kann in verbundenen Unternehmen (z.B. bei Lieferanten und Kunden) zu einem Anpassungsdruck führen. Demonstrationsbeispiel Es wird die organisatorische Integration am Beispiel der Vorgangsintegration gezeigt. Bei Stapelverarbeitung werden Arbeitsvorgänge zur Durchführung einzelner Aufgabenfunktionen so organisiert, daß unterschiedliche Aufgabenfunktionen (z.B. Dateneingabe und Datenbearbeitung) mehreren Aufgabenträgern zuge-

168

Methoden und Techniken der Grobprojektierung

ordnet werden. Dialogverarbeitung ermöglicht die Re-Integration, also die Wiederherstellung einer ursprünglich bestehenden Integration. Beispielsweise wird die Dateneingabe in den Arbeitsplatz des Benutzers eingebunden und damit in den ihm zugeordneten Teil der Aufgabenfunktion Datenbearbeitung integriert. BATCH-VERARBEITUNG BUCHHALTUNG

DATENERFASSUNG

RECHENZENTRUM

1 ) BELEGE VORPRÜFEN i BELEGE KONTIEREN ' (BUCH-STEMPEL, ALLONGE) ) ABSTIMMSUMMEN BILDEN j BELEGTRANSPORT IN ' DATENERFASSUNG

BELEGRÜCKLAUF-

10 KONTROLLE © BELEGABLAGE

© © © ©

BELEGE AUF DATENTRÄGER ERFASSEN ERFASSUNG PRÜFEN DURCH ERNEUTE EINGABE KORRIGIEREN FALSCH ERFAßTER DATEN "TN RÜCKTRANSPORT DER BEZ J LEGE IN DIE BUCHHALTUNG TRANSPORT DER DATENTRÄGER INS RECHENZENTRUM DATENEINGABE UND -PRÜFUNG DRUCKEN FEHLERPROTOKOLL TRANSPORT FEHLERPROTOKOLL IN DIE BUCHHALTUNG

© ©

©

ZUM FEHLERPROTOKOLL ÜBERBELEG SUCHEN FEHLER KORRIGIEREN ' UND KORREKTURBELEG VORBEREITEN

M 7 ) DATEN VERARBEITEN TRANSPORT: 18 1 AUSWERTUNGEN FÜR DIE BUCHHALTUNG

19) ERGEBNISSE AUSWERTEN

DIALOGVERARBEITUNG

© ® © © © © ©

BUCHHALTUNG

DATENERFASSUNG

RECHENZENTRUM

BENUTZERIDENTIFIKATION • t PROGRAMMAUFRUF BELEGE VORPRÜFEN BELEGE AUF BILDSCHIRMMASKE - KONTIEREN - KORRIGIEREN - ABFRAGEN BELEG MIT ERFASSUNGSVERMERK VERSEHEN BELEGABLAGE ERGEBNISSE ABFRAGEN

Abb. PINTE-3: Vorgangsintegration durch Dialogverarbeitung (Quelle: Reblin)

P1NTE - Integrationsprinzipien

169

Abbildung PINTE-3 zeigt ein Beispiel. Im oberen Teil der Abbildung werden die den Stellen Buchhaltung, Datenerfassung und Rechenzentrum zugeordneten Tätigkeiten der Aufgabe "Finanzbuchhaltung" und der sachlogische Zusammenhang zwischen den Tätigkeiten bei Stapelverarbeitung gezeigt. Es sind 19 Tätigkeiten auszuführen, an denen Aufgabenträger in drei Stellen beteiligt sind. Die Aufgabengliederung und die Rückkopplungen führen zu einer langen Durchlaufzeit. Der untere Teil der Abbildung zeigt die gleiche Aufgabe bei Dialogverarbeitung, bei der die Aufgabe in nur fünf Tätigkeiten zerlegt ist. Es sind nur Aufgabenträger einer Stelle beteiligt; eine drastische Verringerung der Durchlaufzeit kann erwartet werden. Forschungsbefunde Der Gesamtkomplex der Integration und insbesondere die Frage der Integrationswirkungen sind bislang nur lückenhaft erforscht worden. Deshalb lassen sich Integrationsprinzipien, die rezeptartig anwendbar sind, nicht formulieren. Mögliche Integrationsmaßnahmen müssen einer Konsequenzanalyse unterzogen werden, um festzustellen, ob sie - bei gegebenen Planungszielen - zweckmäßig sind. Durch Integration werden Konsequenzen bewirkt, die technische, ökonomische und soziale Ziele betreffen. Über die Beziehungen zwischen den Zielen besteht ebenso Unklarheit wie darüber, welche Beziehungen im einzelnen zwischen den verschiedenen Integrationsformen bestehen. Als weitgehend gesichert können folgende Aussagen angesehen werden (vgl. auch die in Lerneinheit WAORG referierten Forschungsbefunde): • Die technische Integration ist Voraussetzung für die organisatorische Integration; sie schafft die organisatorischen Integrationspotentiale. • Die organisatorischen Integrationspotentiale werden nicht ausgeschöpft, was in erster Linie auf die mangelhafte Qualifikation der Systemplaner sowie darauf zurückzuführen ist, daß die Wirkung der Integrationsformen weitgehend unbekannt ist. • Die Wirkung von Integration auf die Wirtschaftlichkeit dürfte sowohl einzelbetrieblich als auch gesamtwirtschaftlich gesehen positiv sein, desgleichen die Wirkung auf die Arbeitsorganisation. Ambichl/Gappmaier berichten über Ergebnisse einer Laborstudie, mit der nicht vernetzte PCs und mit einem Lokalen Netz vernetzte PCs vergleichend bewertet wurden (Untersuchungszeitraum 1988). Unter anderem wird über die positiven Wirkungen technischer Integration auf Verfügbarkeit, Wirksamkeit, Flexibilität, Produktivität und Wirtschaftlichkeit der Aufgabendurchführung berichtet; sie wurden durch Datenintegration und durch Funktionsintegration erreicht. Aufgabenverweise Entwerfen des Datensystems (Lerneinheit WDASY); Entwerfen des Methodensystems (Lerneinheit WMESY); Entwerfen der Arbeitsorganisation (Lerneinheit WAORG); Entwerfen des Transportsystems (Lerneinheit WTRAN); Entwerfen des Sicherungssystems (Lerneinheit WSICH).

170

Methoden und Techniken der Grobprojektierung

Kontrollfragen 1. Was bedeutet "Integration" im allgemeinen Sprachgebrauch, in der Wirtschaftsinformatik und in der Systemplanung? 2. Welche Integrationsformen werden unterschieden? 3. Warum ist die Datenintegration Voraussetzung für die Vorgangsintegration? 4. Wodurch unterscheidet sich innerbetriebliche von zwischenbetrieblicher Integration? 5. Welchen Charakter haben die vorliegenden Forschungsbefunde zur Integration? Quellenliteratur Ambichl, E. und Gappmaier, M.: Nicht vernetzte PCs versus Lokale Netzwerke - eine Vergleichsstudie. In: Information Management, 1/1989, 38 - 43 Reblin, E.: Stapel- oder Dialogverarbeitung im Rechnungswesen. In: Stahlknecht, P. (Hrsg.): Online-Systeme im Finanz- und Rechnungswesen. Springer Verlag, Berlin et al. 1980, 50 Scheer, A.-W.: EDV-orientierte Betriebswirtschaftslehre. 2. A., Springer Verlag, Berlin et al. 1985, 16-21 und 3 7 - 4 3 Vertiefungsliteratur Becker, J.: CIM-Integrationsmodell. Die EDV-gestützte Verbindung betrieblicher Bereiche. Springer Verlag, Berlin et al. 1991 Heitmann, H.: Integration - Ein zentraler Begriff der Wirtschaftsinformatik im Wandel der Zeit. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 150/1989,46 - 58 Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. A., Oldenbourg Verlag, München/Wien 1992 Lehmann, H.: Integration. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980,976 - 984 Mertens, P.: Zwischenbetriebliche Integration der EDV. In: Informatik Spektrum 8/1985, 81 -90

Der Prozeß der Feinprojektierung Strategische Informationssystem-Planung

% Planungsziele | OJ)

Der Prozeß der Vorstudie

B

s o

^77777777777777777777777777^}

Grundkonzeption

3 3 o

^

Der Prozeß der Feinstudie

T3 § ß b + = Trennzeichen

Abb. ETRAN-4: Stuktur einer EDIFACT-Übertragungsdatei (Quelle: aus Frank nach Berge)

Elektronische Postsysteme stellen dem Benutzer standardisierte Felder für den Nachrichtenkopf zur Verfügung (z.B. Adreßfeld, Absenderfeld, Betreff) sowie Felder für Dringlichkeit, Durchschlag an, Antwort auf. Elektronische Postsysteme sind besonders dafür geeignet, größere Gruppen von Empfängern über Verteiler zu adressieren. Auf der Grandlage von elektronischen Postsystemen arbeiten auch elektronische Konferenzsysteme. Datenaustauschformate können - je nach Ausprägung - national oder international bzw. branchenabhängig oder branchenunabhängig sein. Das international gültige und branchenunabhängige Datenaustauschformat ist EDIFACT. Ende 1991 standen den Anwendern etwa 20 genormte Nachrichten ("Nachrichtentypen") zur Verfügung (z.B. INVOIC für Rechnung und ORDER für Bestellung). Ein Nachrichtentyp ist ein Modell, das sämtliche, für eine Kommunikationsart benötigten Datenelemente sowie die zwischen ihnen bestehenden Beziehungen mit Hilfe von Segmentstrukturen festlegt. Zur Realisierung einer vollständigen zwischenbetrieblichen elektronischen Kommunikation sind etwa 100 Nachrichtentypen erforderlich. Abbildung ETRAN-4 zeigt die Struktur einer EDIFACTÜbertragungsdatei, Abbildung ETRAN-5 eine Rechnung und einen Teil der dieser Rechnung entsprechenden EDIFACT-Darstellung.

ETRAN - Entwickeln des Transportsystems

225

Rechnung Verkäufer: 7539742518 DataQuick, Köln NAD Empfänger: 98377-671 ^Le Fe vre, Paris^

Rechnungsdatum: ° 7 - 0 8 - 9 0 BGM Rechnungsnr.: CK 8739514 (Währung: DM C U x )

Artikelbez. Menge AET8932 LIN ARV9265

C

Preis Betrag

150 Stk. 15,6 200 Stk. 23,5

2340 4700

J

UNH+1025+IN VOIC:90:1' B GM+400+CK8739514+07.08.90' N AD+SE+7539742518 ' N AD+CN+98377-671 ' CUX+DEM:IN ' TDT++40+LH738, 07.08.90' LIN+++AET8932++150:PCS+15,6 ' LIN+++ARV9265++200:PCS+23,5 ' TMA+7040 '

(TMA 7040 )

Transportangaben: TDTM LH 738, 07.08.90

Abb. ETRAN- 5: Rechnung und Teil der entsprechenden EDIFACT-Darstellung (Quelle: Frank)

Ein Nachrichtentyp ist aufgebaut als eine Folge von Segmenten, die durch das Segment UNH eingeleitet und durch das Segment UNT abgeschlossen wird. Ein Segment ist ein Datensatz, der aus Datenelementen bzw. Datenelementgruppen zusammengesetzt ist. Am Anfang des Segments befindet sich ein Bezeichner mit Code und Wiederholungsfaktor, der erforderlich ist, weil nicht alle möglichen Segmenttypen in einer Nachricht verwendet werden müssen und Segmente mehrfach wiederholt werden können. Da die Länge der Datenelemente variabel ist, müssen sie durch Trennzeichen ('+') abgeschlossen werden. Da die Interpretation eines Feldes über seine Stellung im Segment erfolgt, muß auch ein nicht spezifiziertes Feld mit Trennzeichen abgeschlossen werden. Datenelementgruppen werden gebildet, indem ihre Komponenten durch Trennzeichen (':') begrenzt werden. Es können für Datenelemente auch qualifier angegeben werden (z.B. für eine Gewichtsangabe die Maßeinheit KG). Zur Spezifikation können neben Werten bestimmte Codes verwendet werden (z.B. für Länder und Währungen). Die Liste der Nachrichtentypen wird im EDIFACT Data Message Directory dokumentiert. Software-Bedarfe bestehen für die Selektion und Zusammenfassung der internen Daten in eine Ausgangsdatei, zur Umwandlung der Ausgangsdatei in die Übertragungsdatei nach den vereinbarten Standards sowie für die Abwicklung der Kommunikation, also die Übermittlung der Übertragungsdatei. Zur Umwandlung der Ausgangsdatei in die Übertragungsdatei empfiehlt sich der Einsatz eines tabellengesteuerten Standard-Konverters; durch Anpassung der Tabellen kann er für beliebige Ausgangsdateien verwendet werden. Die intern verwendete Datenstruktur wird auf die Struktur des ausgewählten Nachrichtentyps abgebildet und umgekehrt. Mit zunehmender Verbreitung von EDIFACT werden

226

Aufgaben der Feinprojektierung

die Konvertierungsroutinen mehr und mehr in die Anwendungssoftware verlagert werden. Als Zwischenstufe zu EDIFACT werden in verschiedenen Ländern nationale Standards verwendet (z.B. SED AS in Deutschland und in Österreich). Die Infrastruktur für den Datenaustauschservice (SDS in Deutschland, ECODEX in Österreich) wird von INS (Information Network Service, ein Geschäftsbereich der IBM) zur Verfügung gestellt. Zutrittspunkte bestehen an mehreren Orten über die Postdienste, in größeren Orten zum Ortstarif. Die Daten werden in einer zentralen Mailbox gespeichert und vom Empfänger abgerufen. Als weitere Zwischenstufe auf dem Weg zu einem weltweiten Standard könnte der Datenaustausch über die nationalen zentralen Knoten und zwischengeschaltete EDIFACTKonverter erfolgen. Verschiedene Hersteller bieten SEDAS-Konverter an (z.B. IBM für AS/400 und S/36). Demonstrationsbeispiel Es wird die Gestaltung des Transportsystems am Beispiel eines einfachen Geschäftsvorgangs gezeigt und die Verwendung von Belegen als Kommunikationsmittel mit elektronischem Datenaustausch verglichen. Brief

Abb. ETRAN-6: Transportsystem mit Belegen

Im Transportsystem mit Belegen übermitteln Lieferanten mit Briefpost an Kunden Rechnungen, die mit dem Anwendungsprogramm Fakturierung erstellt werden. Beim Kunden wird die Briefpost bearbeitet, und es werden die Rechnungsdaten manuell erfaßt und weiterverarbeitet (insbes. Buchung und Erstellen des Überweisungsauftrags). Der Überweisungsauftrag wird ausgedruckt und mit Briefpost an die Kunden-Bank übermittelt (der Einfachheit halber wird ange-

ETRAN - Entwickeln des Transportsystems

121

nommen, daß Kunden-Bank und Lieferanten-Bank identisch sind). Die Daten des Überweisungsauftrags werden bei der Bank erfaßt und weiterverarbeitet (insbes. Gutschrift auf einem Konto des Lieferanten und Belastung eines Kontos des Kunden). In der Regel sind an diesem Vorgang mehrere Banken beteiligt, sodaß auch ein Datenaustausch zwischen Banken erforderlich ist. Überweisungen von Bank zu Bank erfolgen heute meist elektronisch, der Lieferant muß aber die Gutschrift und der Kunde die Belastung erfassen. Das Beispiel zeigt die mehrmalige Umsetzung der vom Anwendungsprogramm erzeugten Rechnungsdaten auf Belege, von Belegen zum Anwendungsprogramm und vom Anwendungsprogramm auf Belege ("Medienbrüche") sowie den umständlichen Transport der Dokumente mit Briefpost zwischen den Geschäftspartnern. Abbildung ETRAN-6 veranschaulicht diese Vorgänge. Abbildung ETRAN-7 zeigt das gleiche Anwendungsbeispiel mit elektronischem Datenaustausch. Der Vergleich läßt erkennen, daß die folgenden Vorgänge nicht mehr erforderlich sind: • • • •

die Erstellung von Belegen; die innerbetriebliche Belegbearbeitung; der zwischenbetriebliche Belegtransport; die (meist manuelle) Datenerfassung.

Abb. ETRAN-7: Transportsystem mit elektronischem Datenaustausch

Bei vielen Anwendungen erfolgt der elektronische Datenaustausch heute auf Grund bilateraler Vereinbarungen zwischen den Geschäftspartnern. Dies führt zu einer Vielfalt von Regeln und zu einer großen Anzahl von Kommunikationsverbindungen. Abbildung ETRAN-8 zeigt die Architektur des Transportsystems zwischen sechs Geschäftspartnern. Jeder Geschäftspartner muß für jeden anderen Geschäftspartner einen Konverter zur Verfügung haben. Die Architektur des Transportsystems kann durch folgende Maßnahmen verbessert werden: • Aufbau eines einheitlichen Verfahrens für den Datenaustausch auf der Grundlage von Normen (z.B. EDIFACT).

228

Aufgaben der Feinprojektierung

Aufbau eines "multilateralen Datenaustauschs" durch Nutzung einer Clearingstelle (wie z.B. bei ECODEX), wie in Abbildung ETRAN-9 gezeigt. Informationssystem A

Informationssystem C

Informationssystem E

Informationssystem B

Informationssystem D

Informationssystem F

U H Anwendungsprogramme • XY Konverter von Informationssystem X zu Informationssystem Y logische Verbindung Abb. ETRAN-8: Bilateraler elektronischer Datenaustausch

Forschungsbefunde Heinrich/Hartwig berichten über die Ergebnisse von empirischen Untersuchungen (Feldexperiment mit A-B-A-Design, Untersuchungszeitraum 1985 bis 1988), deren primäres Ziel es war, das Verhalten von Benutzern eines Kommunikationssystems bezüglich der Wahl zwischen alternativen Kommunikationsmitteln zu erklären. Untersuchungsobjekt war das Kommunikationssystem "Studierende/Institut" am Institut für Wirtschaftsinformatik der Universität Linz. Die zur Wahl stehenden Kommunikationsmittel waren: persönliches Gespräch, Telefon, Computer, Brief und Aushang. Unter anderem wurde festgestellt, daß das persönliche Gespräch der "Vergleichsmaßstab" für die Beurteilung aller anderen Kommunikationsmittel ist. Kommunikation über den Computer wird primär nicht als Alternative, sondern als sinnvolle Ergänzung zu den "klassischen" Kommunikationsmitteln gesehen. Im konkreten Entscheidungsfall wird das Kommunikationsmittel als optimal angesehen, das die aktuell benötigten Eigenschaften am besten erfüllt. Es erfolgt also eine weitgehend rationale Auswahl des Kommunikationsmittels. Derartige Forschungsbefunde weisen auf die Zweckmäßigkeit der situationsbezogenen Auswahl des für die Erfüllung der Kommunikationsaufgabe am besten geeigneten Kommunikationsmittels durch den Benutzer hin. Sie bestätigen auch die Forderung nach differentieller Aufgabengestaltung, indem mehrere bestimmte, vom Aufgabenträger alternativ anzuwendende Vorgehensweisen für die Aufgabenerfüllung zur Verfügung gestellt werden (vgl. Lerneinheit PAORG). Scheer et al. berichten aus einer Einzelfallstudie (Untersuchungszeitraum nicht angegeben, vermutlich 1990), wie durch das Ersetzen von Belegen in Papierform durch elektronische Kommunikation "ein hohes Rationalisierungspotential innerbetrieblicher Abläufe entstehen kann". Konkretisiert wird das Ratio-

ETRAN - Entwickeln des Transportsystems

229

nalisierungspotential durch die Angabe der Anzahl auszuführender Vorgänge in der Logistikkette; sie konnten von 50 auf 42, bei Verlagerung von Logistikfunktionen zwischen den Partnern auf 35 reduziert werden. Die Autoren behaupten, daß sich die Ergebnisse "leicht auf andere Unternehmungen der gleichen Branche wie auch anderer Branchen übertragen" lassen. Informationssystem A

Informationssystem C

El] Anwendungsprogramme B EDJFACT-Konverter • genormte EDI-Datei

Informationssystem B

:nformationssystem D

Abb. ETRAN-9: Multilateraler elektronischer Datenaustausch

A. Kohl et al. beschreiben den Entwicklungsstand und die Einsatzmöglichkeiten elektronischer Produktkataloge als Kommunikationsmittel zwischen Anbietern von Produkten und/oder Dienstleistungen und potentiellen Kunden. Ein Realisierungsbeispiel im Handel ist VideOcart, dessen Technologie und Funktionalität wie folgt beschrieben werden kann: Auf dem Einkaufswagen sind ein DIN A4Bildschirm und eine Tastatur montiert. Der Kunde kann ein alphabetisches Verzeichnis aller verfügbaren Produkte/Dienstleistungen aufrufen. Für ein ausgewähltes Angebot zeigt VideOcart auf einem Lageplan den Weg zwischen dem Standort des Kunden und dem Lagerplatz. Werbespots werden eingeblendet, wenn der Kunde den entsprechenden Lagerplatz passiert ("Werbung am Einkaufspunkt"). Zur Unterhaltung werden Spiele, Kreuzworträtsel, Kinoprogramme und ähnliches angeboten (z.B. zur Überbrückung der Wartezeit am Kassenpunkt). Neben dem Zugang zu den Informationen über den Namen, die Bezeichnung oder die Nummer eines Produkts/einer Dienstleistung ist ein Zugang über bestimmte Eigenschaften und/oder über exemplarisch gezeigte Probleme und Problemlösungen denkbar. Verschiedene Autoren berichten über den Einfluß elektronischer Kommunikation auf Führungsaufgaben; sie kommen zu sehr unterschiedlichen Ergebnissen. Sorg/Zangl berichten von einer intensiven Nutzung elektronischer Kommunikationssysteme bei Führungskräften in mehreren Unternehmen (z.B. für Aufgaben der Arbeitsplanung und Koordination, der Abstimmung von Arbeitsergebnissen und der Informationssuche). Die Unpersönlichkeit des Mediums wird positiv beurteilt, da sie die Kommunikation "auf ein fachlich notwendiges Maß" reduziert, sowie - wegen geringerer interpersoneller Spannungen durch "Emotionen und gegenseitige Abneigungen" - mehr Sachlichkeit ermöglicht. Im Unterschied dazu stellen Reichwald/Stauffert fest, daß elektronische Kommunikation, unter

230

Aufgaben der Feinprojektierung

anderem wegen ihrer Unpersönlichkeit, nur für wenige Arten der Kommunikation im Führungsbereich geeignet ist. M. Feldman berichtet aus verschiedenen empirischen Studien zur Benutzung von elektronischen Postsystemen, daß sie gut geeignet sind, um lose Verbindungen ("weak ties") zwischen Personen(gruppen) aufzubauen und aufrecht zu erhalten. Allerdings gehen 45% der Nachrichten an "Zimmernachbarn", woraus die These abgeleitet werden kann, daß elektronische Post bestehende Kommunikationsbeziehungen verstärkt. Für häufige Benutzer entwickelt sich elektronische Post zum üblichen Medium für berufliche und private Kommunikation, das zu jeder Tages- und Nachtzeit benutzt wird und als weniger störend empfunden wird als das Telefon. H. K. Pfeiffer berichtet über die Ergebnisse einer empirischen Untersuchung zur Diffusion von EDI (schriftliche Befragung von 719 Unternehmen in Europa und USA, Befragungszeitraum 1990). Unter anderem wird festgestellt, daß - mit Ausnahme der Transaktionskosten bei Anwendern mit hohem Datenvolumen kurzfristig kein nennenswerter monetärer Nutzen erwartet werden kann. Überwiegend wird die Auffassung vertreten, daß mit der Einführung von EDI keine Personalfreisetzungen zu erwarten sind. Die Befunde weisen auf eine langfristige Lernkurve. Das heißt, der Prozeß der Assimilation von EDI und die damit verbundenen struktur- und ablauforganisatorischen Veränderungen sowie mögliche Auswirkungen auf die Beschäftigung ist keine Frage von Monaten, sondern von Jahren. Nicht bestätigt wurde die Hypothese, daß EDI zu einer dramatischen Reduzierung der Lagerbestände beiträgt. Der quantifizierbare Nutzen von EDI kann die Kosten nicht kompensieren. Im Vordergrund der Nutzeffekte steht die positive Auswirkung auf den Kundenservice. EDI ist daher eher ein wirksames Marketing-Instrument als ein Mittel zur Verbesserung der Wirtschaftlichkeit. R. Mörk zitiert verschiedene Einzelbeobachtungen operativer Nutzeffekte einer zwischenbetrieblichen Integration, unter anderem: Ciba-Geigy beziffert den Nutzen, der durch elektronischen Datenaustausch erzielt werden kann, für sein Stammhaus in Basel mit SFr. 10 Mio. pro Jahr; Digital Equipment konnte durch elektronischen Datenaustausch den Lagerbestand in einem Werk von zwei Mio. auf 0,5 Mio. US$ senken; Douglas Aircraft Company konnte durch elektronischen Datenaustausch die Kosten für die Ersatzteil-Bestellabwicklung von zehn auf zwei DM je Bestellvorgang senken; General Motors geht von der Annahme aus, durch elektronischen Datenaustausch die Produktionskosten pro Fahrzeug um zweihundert US$ senken zu können; Motorola rechnet bei elektronischem Datenaustausch mit einer Kostensenkung von dreiundzwanzig DM je Geschäftsvorgang. Methodenverweise Nummernsysteme (Lerneinheit NUMSY); Prinzipien der Arbeitsorganisation (Lerneinheit PAORG):

ETRAN - Entwickeln des Transportsystems

231

Kontrollfragen 1. 2. 3. 4. 5.

Welche Aufgaben sind beim Entwickeln des Transportsystems zu bearbeiten? Welche Anforderungen sind bei der Beleggestaltung zu berücksichtigen? Wie kann die Lesbarkeit eines Dokuments mit Hilfe der Tabelle der Lesbarkeit von Le Courier beurteilt werden? Auf welche wesentlichen Gesichtspunkte können die Unterschiede zwischen beleggebundener und elektronischer Kommunikation zurückgeführt werden? Welche Auswirkungen hat branchenunabhängige, internationale Normung beim EDI?

Quellenliteratur Frank, U.: Anwendungsnahe Standards der Datenverarbeitung: Anforderungen und Potentiale. In: WIRISCHAFTSINFCRMAnK 2/1991, 100- 111 Heinrich, L. J. und Hartwig, Th.: Abschlußbericht zum Forschungsprojekt CUSIS: Computerunterstütztes Studenten-Informationssystem - Ersetzbarkeit von Mensch-Mensch-Kommunikation durch Mensch-Maschine-Mensch-Kommunikation. Linz 1989 Kohl, A. et al.: Elektronische Produktkataloge - Entwicklungsstand und Einsatzmöglichkeiten. In: WKISOIAFTSINFORMAnK 5/1992, 5 0 9 - 5 1 6 Mörk, R.: Ein praxisorientiertes Vorgehensmodell zur Einführung von zwischenbetrieblicher Integration. In: Theorie und Praxis der Wirtschaftsinformatik 165/1992,47 - 67 Müller-Pleuß, J.: Vordruckgestaltung. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A„ Poeschel Verlag, Stuttgart 1992, 2582 - 2595 Reichwald, R. und Stauffert, T.: Bürokommunikationstechnik und Führung. In: Kieser, A. et al. (Hrsg.): Handwörterbuch der Führung. Poeschel Verlag, Stuttgart 1987, 115 - 127 Scheer, A.-W. et al.: Analyse der Umsetzung einer EDI-Konzeption am Beispiel der Beschaffungslogistik in der Automobilzuliefererindustrie. In: Information Management 2/1991, 30 - 37 Vertiefungsliteratur DIN (Hrsg.): EDIFACT - Elektronischer Datenaustausch für Verwaltung, Wirtschaft und Transport. Referate zur 4. DIN-Tagung. DIN Normenausschuß für Bürowesen, Berlin 1989 EAN AUSTRIA, Gesellschaft für kooperative Logistik GesmbH., Wien (Hrsg.): EAN INFO, Fachzeitschrift für Artikelnumerierung, Warenwirtschaft und elektronischen Datenaustausch Feldman, M.: Constraints on Communication and Electronic Messaging. In: CSCW '86. Proceedings ACM-Conference on Computer Supported Cooperative Work, Austin/Texas, 7 3 - 9 0 IBM Österreich (Hrsg.): ECODEX Informationsbroschüre. Wien 1991 Miebach, J. T.: Funktionalität von EDI-Konvertem. In: WIRTSCHAFTSINFORMATIK 5/1992, 517 -526 Oppelt, U.: EDI-Implementierung in der Praxis - Voraussetzungen, Vorgehensweise, Wirtschaftlichkeit. In: Reichwald, R. (Hrsg.): Marktnahe Produktion. Gabler Verlag, Wiesbaden 1992, 68-81 Pfeiffer, H. K.: The Diffusion of Electronic Data Interchange. Selected Results of an International Empirical Investigation. Working Report 23, Institut für Wirtschaftsinformatik der Universität Bern, Bern 1990 Picot, A. et al.: Ökonomische Perspektiven eines "Electronic Data Interchange". In: Information Management 2/1992,22 - 29 Sorg, S. und Zangl, H.: Vorteile integrierter Bürosysteme für Führungskräfte - Erfahrungen aus einem Pilotprojekt. In: Jahrbuch der Bürokommunikation 2/1986,117- 119 Normen ÖNORM ISO 7498 - Informationsverarbeitungssysteme, Kommunikation offener Systeme, BasisReferenzmodell DIN 16556 - EDIFACT - Elektronischer Datenaustausch für Verwaltung, Wirtschaft und Transport. Syntax-Regeln auf Anwendungsebene (deutsche Übersetzung der ISO/DIS-Norm 9735)

ESICH - Entwickeln des Sicherungssystems Lernziele Sie kennen die zum Entwickeln des Sicherungssystems erforderlichen Arbeitsaufgaben und eine daraus abgeleitete Vorgehensweise. Sie können die Arbeitsschritte der Vorgehensweise erläutern. Sie wissen, daß Sicherungsmaßnahmen in einem geschlossenen System unwirksam werden, wenn äußere Schalen des Sicherungssystems durchlässig sind. Sie erkennen die sich daraus ergebende Bedeutung kryptographischer Verschlüsselungsmethoden. Definitionen und Abkürzungen Authentifikation (authentification) = die Verifizierung der durch Identifikation festgestellten Identität eines Benutzers. Ereignisaufzeichnung (event logging) = die Aufzeichnung definierter Ereignisse während eines Verarbeitungsvorgangs in einer Log-Datei, die für den Wiederanlauf nach einem Systemzusammenbruch verwendet wird. Funktionstrennung (function Separation) = die Zuordnung von Aufgaben auf Aufgabenträger so, daß eine gegenseitige Kontrolle bei der Aufgabendurchführung möglich ist. Identifikation (identification) = die Bestimmung der Identität eines Benutzers, integriertes Sicherungssystem (integrated backup system) = die Gesamtheit der aufeinander abgestimmten Sicherungsmaßnahmen zur Deckung des aus den Sicherheitszielen abgeleiteten Sicherungsbedarfs, kryptographische Verschlüsselung (cryptographic encryption) = die Abbildung eines Klartextes in einen Geheimtext so, daß der Aufwand für die unbefugte Entschlüsselung größer als der mit der Entschlüsselung verbundene Nutzen ist. Paßwort (password) = ein Mechanismus zur Identifikation. Sicherungsmaßnahme (backup measure) = eine Maßnahme technischer, organisatorischer, baulicher oder sonstiger Art zur Deckung eines bestimmten Sicherungsbedarfs. Systemabbruch (systems crash) = das abnormale Beenden des Betriebs eines Informationssystems aus unterschiedlichen Gründen (z.B. Hardware-Defekt oder Software-Fehler). Transaktionsprotokoll (transaction protocol) = eine Aufzeichnung zum Nachweis aller in einem Informationssystem durchgeführten Transaktionen. Vier-Augen-Prinzip (four-eyes principle) = die gleichzeitige Tätigkeit von zwei (oder mehr) Personen in einer Stelle mit dem Zweck der gegenseitigen Kontrolle zur Vermeidung von Fehlern und/oder deliktischen Handlungen. Wiederanlauf (restart) = das Neustarten eines Programms nach einer Programmunterbrechung oder einem Programmabbruch. Wiederanlauf-Verfahren (restart procedure) = die Art und Weise, in der ein Wiederanlauf technisch bewerkstelligt wird (z.B. Fixpunkt verfahren). Zugriffsberechtigung (access authority) = der Anspruch, das Anrecht oder die Befugnis eines Benutzers, auf bestimmte Teile der Datenbasis und/oder der Methodenbasis zugreifen zu können. Synonym: Benutzerberechtigung.

ESICH - Entwickeln des Sicherungssystems

233

Schnittstellen beim Entwickeln des Sicherungssystems Die Schnittstellen beim Entwickeln des Sicherungssystems sind durch die nachfolgend beschriebenen Inputs und Outputs gekennzeichnet. Inputs zum Entwickeln des Sicherungssystems sind: • das Ergebnis des Entwerfens des Sicherungssystems, also die vorhandenen Sicherungsbedarfe (vgl. Lerneinheit WSICH); • die Ergebnisse der Systementwicklung in den Teilprojekten Datensystem (vgl. Lerneinheit EDASY), Methodensystem (vgl. Lerneinheit EMESY), Arbeitsorganisation (vgl. Lerneinheit EAORG) und Transportsystem (vgl. Lerneinheit ETRAN). Outputs des Entwickeins des Sicherungssystems sind: • die Ergebnisse der Systementwicklung im Teilprojekt Sicherungssystem, durch die Entwicklungsarbeiten in anderen Teilprojekten beeinflußt werden; • das integrierte Sicherungssystem als Ergebnis des Entwickeins des Sicherungssystems.

Abb. ESICH-1: Inputs und Outputs beim Entwickeln des Sicherungssystems

Abbildung ESICH-1 zeigt die Einbettung des Entwickeins des Sicherungssystems in die genannten Inputs und Outputs. Die seitliche Anordnung des Inputs "Systementwicklung in anderen Teilprojekten" deutet auf den interaktiven Zusammenhang der Entwicklungsarbeiten in allen Teilprojekten hin. Der Weg von den Inputs zum Ergebnis als integriertes Sicherungssystem ist durch das Erfassen bekannter und das Entwickeln neuer Sicherungsmaßnahmen für alle definierten Sicherungsbedarfe gekennzeichnet, wobei die in anderen Teilprojekten bereits implementierten Sicherungsmaßnahmen zu berücksichtigen sind. Eine Abstimmung mit den unternehmensweit vorhandenen Sicherungsmaßnahmen ist zur Vermeidung von Unvereinbarkeiten und unwirtschaftlicher Mehrfachimplementierung erforderlich (vgl. Lerneinheiten SICHM und KATAM im Band "Informationsmanagement" ).

234

Aufgaben der Feinprojektierung

Aufgaben beim Entwickeln des Sicherungssystems Die implementierten Sicherungsmaßnahmen sollen so aufeinander abgestimmt sein, daß sie in ihrer Gesamtheit die vorhandenen Sicherungsbedarfe, die durch das gegenständliche IuK-Projekt verursacht werden, abdecken und damit die definierten Sicherheitsziele erfüllen. Die projektspezifischen Sicherungsmaßnahmen allein können nicht zu einem unternehmensweiten Sicherungssystem führen, da sich aus den strategischen Sicherheitszielen Sicherungsbedarfe ergeben, die über projektspezifische Anforderungen hinausgehen. Mit anderen Worten: Die Gesamtheit der durch IuK-Projekte implementierten Sicherungsmaßnahmen muß durch unternehmensweit geschaffene Sicherungsmaßnahmen ergänzt werden. Die durch ein IuK-Projekt geschaffenen Sicherungsmaßnahmen sind in dieses Gesamtkonzept so einzuordnen, daß ein optimaler Schutz der gesamten Informationsinfrastruktur erreicht wird. Das unternehmensweite Sicherungssystem entsteht also durch einen evolutionären Prozeß, der top-down und bottom-up verläuft. Top-down wird das Rahmenkonzept geschaffen, und es werden die Sicherungsmaßnahmen implementiert, die sich auf die Informationsinfrastruktur als Ganzes beziehen (z.B. Geländeschutz und Gebäudeschutz) bzw. auf solche Komponenten, die von mehreren Informationssystemen genutzt werden (z.B. Schutz der zentralen Hardware-Komponenten). Mit jedem IuK-Projekt entstehen in der Regel neue Sicherungsbedarfe, die mit zusätzlichen, bisher nicht verfügbaren Sicherungsmaßnahmen abgedeckt werden müssen; dieser Bottom-up-Prozeß führt zur Ergänzung und Präzisierung des Rahmenkonzepts. In jedem IuK-Projekt muß überprüft werden, ob das unternehmensweite Sicherungssystem die notwendigen Sicherungsmaßnahmen bereits zur Verfügung stellt. Nur wenn dies nicht der Fall ist, sind weitere Sicherungsmaßnahmen zu schaffen, oder die bestehenden Sicherungsmaßnahmen sind entsprechend anzupassen (z.B. zu verschärfen). Kennzeichnend für die meisten Sicherungsmaßnahmen ist, daß sie nur in einer sicheren Anwendungsumgebung wirksam sind. Das Sicherungssystem ist ein geschlossenes System, das man sich als Schalenmodell vorstellen kann (z.B. mit Sicherungsmaßnahmen zum Geländeschutz, zum Gebäudeschutz, zum HardwareSchutz, zum Betriebssystemschutz, zum Schutz des Datenverwaltungssystems, zum Schutz der Programme und schließlich zum Schutz der Datenbestände). Kann eine Sicherungsmaßnahme in einer äußeren Schale durchbrochen werden, so werden die Sicherungsmaßnahmen der inneren Schalen unwirksam (z.B. ist ein Hardware-Schloß am PC wirkungslos, wenn der PC von einem Eindringling weggetragen und an einem "sicheren Ort" aufgebrochen werden kann). Da sich projektspezifische Sicherungsmaßnahmen meist in einer inneren Schale befinden, heißt dies zunächst, daß jede Sicherungsmaßnahme daraufhin überprüft werden muß, ob die von ihr erwartete Wirkung zur Abdeckung eines Sicherungsbedarfs in der bestehenden Anwendungsumgebung auch tatsächlich erreicht wird. Kann sie durch Durchlässigkeiten äußerer Schalen umgangen werden, ist ihre Wirkung zumindest reduziert. Einen Ausweg aus dieser Situation bieten nur solche Sicherungsmaßnahmen, die auch in einer unsicheren Anwendungsumgebung ihre volle Wirksamkeit behalten. Dazu gehören insbesondere die Siehe-

ES1CH - Entwickeln des Sicherungssystems

rungsmaßnahmen, die Methoden der kryptographischen verwenden (vgl. Lerneinheit KRYPT).

235

Verschlüsselung

Da eine große Anzahl von Sicherungsmaßnahmen zur Verfügung steht, besteht die erste Aufgabe beim Entwickeln des Sicherungssystems in einer gründlichen Bestandsaufnahme und Systematisierung. Davon ausgehend, werden jedem vorhandenen, beim Entwerfen des Sicherungssystems dokumentierten Sicherungsbedarf die Sicherungsmaßnahmen zugeordnet, die den Sicherungsbedarf so weit abdecken, daß die definierten Sicherheitsziele erreicht werden. Häufig gibt es alternativ verwendbare Sicherungsmaßnahmen, die mit geeigneten Kriterien zu bewerten sind. Schließlich sollen alle ausgewählten Sicherungsmaßnahmen dokumentiert werden. Vorgehensweise beim Entwickeln des Sicherungssystems Aus den genannten Aufgaben kann die folgende, in Arbeitsschritte gegliederte Vorgehensweise beim Entwickeln des Sicherungssystems abgeleitet werden (vgl. Abbildung ESICH-2).

Abb. ESICH-2: Arbeitsschritte beim Entwickeln des Sicherungssystems

Erster Arbeitsschritt: Erfassen und Systematisieren von Sicherungsmaßnahmen. Im ersten Arbeitsschritt werden alle Sicherungsmaßnahmen, die in der einschlägigen Literatur dokumentiert sind, erfaßt und systematisiert. Für die Systematisierung können verschiedene Ordnungssysteme verwendet werden. Abbildung ESICH-3 zeigt ein Beispiel für eine Systematik, welche die drei Dimensionen Phase, Instrumentalcharakter und Gegenstand der Sicherung verwendet. • Nach der Phase der Sicherung wird in vorbeugende, kontrollierende und korrigierende Sicherungsmaßnahmen gegliedert. Damit wird eine Sicherungsmaßnahme bezüglich des Zeitpunkts des Sicherungsbedarfs charakterisiert, also ob die Sicherungsmaßnahme vor, während oder nach Durchführung einer bestimmten Tätigkeit zur Wirkung kommt.

236

Aufgaben der Feinprojektierung

• Nach dem Instrumentalcharakter der Sicherung wird in organisatorische, hardwaremäßige und softwaremäßige Sicherungsmaßnahmen gegliedert. Damit wird eine Sicherungsmaßnahme bezüglich der Art des verwendeten Sachmittels für seine Implementierung charakterisiert. • Nach dem Gegenstand der Sicherung wird in materielle, formale und zeitliche Sicherungsmaßnahmen gegliedert. Damit wird eine Sicherungsmaßnahme bezüglich der Art des Sicherungsbedarfs charakterisiert, auf dessen Abdeckung sie ausgerichtet ist. Materielle Fehler sind zum Beispiel bei der Sicherung des Datensystems die Schlüsselattribute, die unzutreffend auf Daten zugeordnet werden. Formale Fehler sind zum Beispiel fehlerhafte Feldfolgen in einem Datensatz. Zeitliche Fehler kennzeichnen Abweichungen der Verfügbarkeitstermine der Datensätze von Terminvorgaben.

Zweiter Arbeitsschritt: Zuordnen von Sicherungsmaßnahmen auf Sicherungsbedarfe. Dabei wird von der im ersten Arbeitsschritt erstellten Systematik der Sicherungsmaßnahmen ausgegangen. Im allgemeinen wird es für jeden Sicherungsbedarf zumindest eine Sicherungsmaßnahme geben, die geeignet ist und die dem Stand der Technik entspricht. Bei Vorliegen außergewöhnlicher, sehr spezifischer Sicherungsbedarfe müssen neue Sicherungsmaßnahmen entwickelt werden, wobei es sich meist um eine Verfeinerung bekannter Sicherungsmaßnahmen handelt (z.B. eine neue Methode der kryptographischen Verschlüsselung). Anpassungen bekannter Sicherungsmaßnahmen reichen im allgemeinen aus, um die Sicherungsbedarfe voll abzudecken (z.B. die Verfeinerung der Paßworttechnik). Da einzelne Sicherungsmaßnahmen nicht nur auf den Sicherungsbedarf einer Komponente, sondern auf den mehrerer Komponenten eines Informationssystems wirken können, muß beim Zuordnen von Sicherungsmaßnahmen auf Sicherungsbedarfe darauf geachtet werden, daß nicht redundante Sicherungsmaßnahmen, die Kosten verursachen, ohne offene Sicherungsbedarfe abzudecken, implementiert werden. Abbildung ESICH-4 veranschaulicht die mehrere Komponenten eines Informationssystems überdeckende Wirkung von Sicherungsmaß-

ESICH - Entwickeln des Sicherungssystems

237

nahmen. Die Überdeckung kann dafür eingesetzt werden, die Abwehrtiefe gegen bestimmte Bedrohungen zu verstärken.

Abb. ESICH-4: Komponentenüberdeckung der Sicherungsmaßnahmen

Dritter Arbeitsschritt: Bewerten und Auswählen von Sicherungsmaßnahmen. Häufig stehen alternative Sicherungsmaßnahmen zur Abdeckung eines bestimmten Sicherungsbedarfs zur Verfügung. In diesem Fall muß eine Bewertung der Alternativen mit dem Ziel erfolgen, die optimale Sicherungsmaßnahme auszuwählen. Das Bewerten und Auswählen wird mit der Nutzwertanalyse unterstützt (vgl. Lerneinheit NUTZW). Dabei können alle Bewertungskriterien, die für die Bewertung von Sicherungsmaßnahmen sinnvoll sind, verwendet werden. Beispiele sind Wirksamkeit, Wirtschaftlichkeit und Zuverlässigkeit; durch systematisches Zerlegen werden daraus operationale Bewertungskriterien abgeleitet (z.B. Kosten der Implementierung, Verlängerung der Antwortzeit und Anzahl nicht erkannter Fehler). Das Ermitteln der Zielerträge erfordert häufig empirische Tests (vgl. Lerneinheit TESTM); in einigen Fällen kann auf Forschungsbefunde (z.B. Paßworttests) zurückgegriffen werden. Vierter Arbeitsschritt: Dokumentieren der Sicherungsmaßnahmen. Die Dokumentation der Sicherungsmaßnahmen soll gewährleisten, daß im Störungsfall das Informationssystem so schnell wie möglich wieder verfügbar werden kann ("Problemmanagement", vgl. Lerneinheit PROBM im Band "Informationsmanagement"). Die Dokumentation muß vertraulich sein, da die Beschreibung von Sicherungsmaßnahmen auch als Anleitung zum Mißbrauch dienen kann. Handelt es sich um eine Sicherungsmaßnahme, deren Versagen so erhebliche Auswirkungen haben kann, daß eine Weiterführung der Verarbeitung nicht mehr gewährleistet ist oder daß das Leben oder die Gesundheit von Mitarbeitern gefährdet wird ("Katastrophe"), muß der Katastrophenplan (vgl. Lerneinheit KPLAN im Band "Informationsmanagement") ergänzt werden.

238

Aufgaben der Feinprojektierung

Merkmale von Sicherungsmaßnahmen Für die Bewertung und Auswahl von Sicherungsmaßnahmen ist ihre Beschreibung anhand typischer Merkmale zweckmäßig. Dazu gehören, neben dem Aufwand bzw. den Kosten für die Implementierung und den Betrieb, folgende: • Flexibilität. Eine Sicherungsmaßnahme ist flexibel, wenn sie ohne oder mit geringem Aufwand an unterschiedliche Anwendungsumgebungen angepaßt werden kann. • Anwendungsbarriere. Eine Sicherungsmaßnahme hat keine bzw. eine geringe Anwendungsbarriere, wenn sie ohne besondere Denk- oder Merkleistungen des Benutzers angewendet werden kann. • Einsichtigkeit. Eine Sicherungsmaßnahme ist einsichtig, wenn ihr Zweck und ihr Nutzen vom Benutzer ohne besondere Erklärung erkannt werden kann. • Sanktionierbarkeit. Eine Sicherungsmaßnahme ist sanktionierbar, wenn Verstöße gegen ihre Verwendung erkannt, erfaßt und bestraft werden. • Umgehbarkeit. Eine Sicherungsmaßnahme ist umso umgehbarer, je geringer der Aufwand für die Umgehung ist. • Überprüfbarkeit. Eine Sicherungsmaßnahme ist überprüfbar, wenn es Aufzeichnungen darüber gibt, ob sie den beabsichtigten Zweck erfüllt; die Aufzeichnungen sollen möglichst automatisch erfolgen. • Konsistenz. Eine Sicherungsmaßnahme ist konsistent, wenn sie bei jeder Anwendung in völlig gleicher Weise wirkt. Prinzipien beim Entwickeln von Sicherungsmaßnahmen Die Zuordnung von Sicherungsmaßnahmen auf Sicherungsbedarfe soll nach bestimmten Prinzipien erfolgen; dazu gehören: • Prinzip der Verantwortlichkeit. Für jede Sicherungsmaßnahme soll festgelegt sein, wer für ihre Anwendung zuständig ist und wer die Anwendung überprüft ("Vier-Augen-Prinzip"). • Prinzip der Unabhängigkeit. Die Wirksamkeit einer Sicherungsmaßnahme soll nicht von der Wirksamkeit einer anderen Sicherungsmaßnahme abhängig sein. • Prinzip der Ablehnung. Der Ausfall einer Sicherungsmaßnahme soll dazu führen, daß das gesicherte Objekt nicht mehr zur Verfügung steht. • Prinzip der Parametrisierbarkeit. Eine Sicherungsmaßnahme soll nicht ausschließlich feste Werte benutzen, sondern über variable Parameter steuerbar sein. • Prinzip der Unsichtbarkeit. Eine Sicherungsmaßnahme soll wirken, nicht "zur Schau gestellt" sein; auf gesicherte Objekte soll nicht ausdrücklich hingewiesen werden. Demonstrationsbeispiel Aus der Vielzahl der Sicherungsmaßnahmen werden zwei beispielhaft erläutert, die der Datensicherung und der Sicherung der Anwendungsprogramme dienen: das Führen eines Transaktionsprotokolls über alle Datenbankveränderungen und das Gestalten der Zugriffsberechtigung mit der Paßworttechnik (wegen

ESICH - Entwickeln des Sicherungssystems

239

weiterer Sicherungsmaßnahmen vgl. Kapitel Schutztechnik im Band "Informations- und Kommunikationstechnik"). Transaktionsprotokoll. Mit dieser Sicherungsmaßnahme wird der Wiederanlauf nach einem Datenbankfehler (z.B. verursacht durch einen Systemabbruch) gewährleistet. Das primäre Ziel des Wiederanlauf-Verfahrens ist das Bereitstellen des Datensystems in dem Zustand, in dem es vor dem Auftreten des Datenbankfehlers bestanden hat. Im Transaktionsprotokoll werden alle Datenbankveränderungen aufgezeichnet ("Ereignisaufzeichnung"). Es können - zur Abdeckung anderer Sicherungsbedarfe - auch Lese-Transaktionen, die Anzahl der Datenbankzugriffe, Daten über Beginn und Ende einer Transaktion und über Verfahrensverletzungen (z.B. wiederholte unberechtigte Versuche, auf die Datenbank zuzugreifen) aufgezeichnet werden. Für den Wiederanlauf nach einem Datenbankfehler sind die Aufzeichnungen des Transaktionsprotokolls von Interesse, die auf Grund von Veränderungen der Datenbank durch Transaktionen des Benutzers protokolliert worden sind. Dazu werden eine Kopie des Datenbereichs mit dem Inhalt der Datenfelder vor der Änderung ("before image") und eine Kopie des Datenbereichs mit dem Inhalt der Datenfelder nach der Änderung ("after image") in einer Protokolldatei gespeichert. Das Verändern der Daten in der Datenbank muß wie folgt ablaufen: 1. Schreiben einer Kopie des Datenbankbereichs vor Änderung in die Protokolldatei; 2. Schreiben einer Kopie des Datenbankbereichs nach Änderung in die Protokolldatei; 3. tatsächliches Verändern des Datenbankbereichs ("update"); 4. Eintrag in der Protokolldatei, daß die Datenbankveränderung erfolgreich durchgeführt wurde. Diese Vorgehensweise stellt sicher, daß das Transaktionsprotokoll jederzeit den "wahren" Zustand der Datenbank wiedergibt und daß alle Veränderungen in der Datenbank nachvollzogen und rückgängig gemacht werden können. Die Protokolldatei soll physisch auf einem anderen Datenträger als die Datenbank gespeichert sein. Ergänzend dazu ist in periodischen Abständen die gesamte Datenbank auf externen Datenträgern zu sichern ("Mehrfach-Bestandsführung"). Paßworttechnik. Jeder Benutzer muß sich durch ein Paßwort zu erkennen geben ("Benutzeridentifikation"). Das Betriebssystem (oder das Datenverwaltungssystem) prüft die Übereinstimmung zwischen dem Paßwort und dem im System abgelegten Berechtigungsnachweis ("Zugriffsberechtigung"). Gesucht ist ein Paßwort, das den Benutzer identifiziert und die Zugriffsberechtigung auf Anwendungsprogramme und auf Dateien regelt. Dazu werden Anwendungsprogramme und Dateien zunächst je sechs Klassen zugeordnet, und jede Klasse wird in die Ebenen 0 bis 9 gegliedert. Ebene 0 verhindert den Zugriff, Ebenen 1 bis 8 stehen für anwendungsorientierte Arbeiten und Ebene 9 steht für systemorientierte Arbeiten zur Verfügung. Jedem Benutzer werden folgende Informationen zugeordnet, die in internen Systemtabellen abgelegt werden:

240

Aufgaben der Feinprojektierung

• eine Identifikation, welche die Systemanmeldung ermöglicht - für jede der sechs Anwendungsprogramm-Klassen die höchste zulässige Ebene (Anwendungsprogramm-Benutzer-Ebene); • für jede der sechs Datei-Klassen die höchste zulässige Ebene (Datei-Benutzer-Ebene). Im Paßwort ZWERG 584008 813406 bedeutet ZWERG die Identifikation, 584008 legt die Anwendungsprogramm-Benutzer-Ebenen und 813406 die DateiBenutzer-Ebenen fest. Beispielsweise hat ZWERG die Berechtigung, in der ersten Anwendungsprogramm-Klasse auf die Anwendungsprogramme bis zur Ebene 5, in der ersten Datei-Klasse auf die Dateien bis zur Ebene 8, also auf sämtliche Dateien dieser Klasse, zuzugreifen. Die Zugriffsberechtigung auf die Dateien (und analog auf die Anwendungsprogramme) wird in Satzparameter-Listen abgelegt und so spezifiziert, daß die Zugriffsberechtigung für jedes Attribut, differenziert nach Mutieren (Verändern) und Lesen, definiert ist. Abbildung ESICH-5 zeigt ein Beispiel. Danach kann das Kreditlimit von allen Benutzern gelesen werden, welche mindestens die Benutzer-Ebene 7 haben, jedoch nur von den Benutzern verändert werden, welche mindestens die Benutzer-Ebene 8 in dieser Datei-Klasse haben. Benutzer-Ebene Mutieren

Benutzer-Ebene Lesen

Attribut

1 3 6 8

1 3 6 7

Kundennummer Kontenkreis Provisionssatz Kreditlimit

Abb. ESICH-5: Satzparameter-Liste Datei Debitoren/Kreditoren (Ausschnitt)

Forschungsbefunde Piller/Weißenbrunner berichten über Paßworttests, bei denen untersucht wurde, ob ein Beobachter ein Paßwort erkennen kann, wenn er einem Benutzer bei der Eingabe eines Paßworts zusieht (das Paßwort erscheint nicht am Bildschirm). Aus den Tests werden folgende Schlußfolgerungen gezogen: • "Sinnlose" Paßwörter sind wesentlich wirkungsvoller als Namen oder Begriffe. Der Beobachter kann sich ein "sinnloses" Paßwort mit fünf und mehr Zeichen in der Regel nicht merken, außer es wird langsam eingegeben. • Es ist leichter zu beobachten, wenn der Benutzer in Grundstellung des Zehnfingersystems schreibt, als mit nur einem Finger. Ausnahme: Wenn ein wenig geübter Benutzer mit nur einem Finger langsam tippt. Die maximale Dauer für die Paßworteingabe soll zwei Sekunden sein. • Als Paßwort soll eine sinnlose Zeichenkette mit sechs bis acht Zeichen (ohne Zeichen bzw. Ziffern der obersten Tastaturreihe) verwendet werden. Von einem längeren Paßwort ist abzuraten, da es leicht vergessen wird. • Es soll darauf geachtet werden, daß kein Paßwort verwendet wird, das in Beziehung zum Benutzer steht (z.B. der Name der Ehefrau, der Freundin,

ESICH - Entwickeln des Sicherungssystems

241

der Firma oder des Hundes, die Telefonnummer, der Wohnort oder der Vorname). Standardpaßwörter wie "Test", "Demo" usw. sind zu vermeiden. Paaß/Wauschkuhn berichten über Ergebnisse von Experimenten, mit denen das Identifikationsrisiko von anonymisierten Datensätzen in einer Datenbank ermittelt wurde (Projekt AIMIPH = Konstruktion und Erprobung eines anonymisierten integrierten Mikrodatenfiles der bundesdeutschen Privathaushalte). Dabei wurden Angriffsversuche für verschiedene Szenarien konstruiert und simuliert (z.B. "Staatsanwalt", "Steuerfahnder", "Journalist"). Die beiden verwendeten Datenbestände wurden aus realen Daten entnommen (Einkommens- und Verbrauchsstichprobe 1978, Mikrozensus 1978). Die Datensätze wurden formal anonymisiert; extreme Merkmalsausprägungen wurden durch Zusammenfassen oder Weglassen verschleiert. Unter anderem wurde festgestellt, daß das Sicherheitsrisiko dann besonders groß ist, wenn der Angreifer einen sog. Fischzug startet, bei dem er nicht einen bestimmten Datensatz, sondern einen besonders auffälligen, "extremen" Datensatz zu identifizieren versucht. Dies gilt auch dann, wenn das Überschneidungswissen gering ist. Geringes Überschneidungswissen schützt also nicht (wie meist angenommen) vor dem Identifikationsrisiko. Methodenverweise Kryptographische Verschlüsselungsmethoden (Lerneinheit KRYPT). Kontrollfragen 1. 2. 3. 4. 5.

Welche Aufgabe hat das Entwickeln des Sicherungssystems? Wie kann die Aufgabe in Teilaufgaben zerlegt und zu einer Vorgehensweise geordnet werden? Welche Dimensionen verwendet die vorgeschlagene Systematik der Sicherungsmaßnahmen? Mit welcher Methode kann das Bewerten alternativer Sicherungsmaßnahmen unterstützt werden? Welche Prinzipien sollen beim Zuordnen von Sicherungsmaßnahmen auf Sicherungsbedarfe beachtet werden?

Quellenliteratur Abel, H. und Schmölz, W.: Datensicherung für Betriebe und Verwaltungen. Sicherungsmaßnahmen in der modernen Informationstechnik - Erfahrungen aus der Praxis. Verlag Beck, München 1987 Heinrich, L. J. et al.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 4. A., Oldenbourg Verlag, München/Wien 1994, insbes. Kapitel "Schutztechnik" Piller, E. und Weissenbrunner, A.: Software-Schutz. Springer Verlag, Wien/New York 1986 Pommerening, K.: Datenschutz und Datensicherheit. B.I. Wissenschaftsverlag, Mannheim et al. 1991 Strauß, Ch.: Informatik-Sicherheitsmanagement. Eine Herausforderung für die Unternehmensführung. Verlag Teubner, Stuttgart 1991 Vertiefungsliteratur Drews, H.-L. et al.: Lexikon Datenschutz und Datensicherung. 3. A., Siemens AG, Berlin/München 1986 Heilmann, W. und Reusch, G. (Hrsg.): Datensicherheit und Datenschutz. Hilfen zur Bestimmung eines eigenen Standpunktes. Forkel Verlag, Stuttgart/Wiesbaden 1984 Kersten, H.: Einführung in die Computersicherheit. Oldenbourg Verlag, München/Wien 1991 Krallmann, H.: EDV-Sicherheitsmanagement. Integrierte Sicherheitskonzepte für betriebliche Informations- und Kommunikationssysteme. Schmidt Verlag, Berlin 1989

242

Aufgaben der Feinprojektierung

Paaß, G. und Wauschkuhn, U.: Datenzugang, Datenschutz und Anonymisierung. Oldenbourg Verlag, München/Wien 1985 Schaumüller-Bichl, I.: Sicherheitsmanagement. Risikobewältigung in informationstechnologischen Systemen. B. I. Wissenschaftsverlag, Mannheim et al. 1992 Weyer, H. und Pütter, St.: Organisation und Technik der Datensicherung - Empfehlungen aus der Kontrollpraxis. Datakontext Verlag, Köln 1983

EINTE - Integration der Systementwicklung Lernziele Sie kennen die Aufgaben und den Zweck der Systemintegration bei der Systementwicklung. Sie können die Aufgaben der Systemintegration in geeigneter Weise gliedern. Sie können typische Beispiele für Aufgaben der Systemintegration nennen und erläutern. Sie sind in der Lage, eine Vorgehensweise für die Systemintegration anzugeben. Definitionen und Abkürzungen Dezentralisierung (decentralization) = die Ausrichtung oder das Streben von einem Mittelpunkt (einem Zentrum) weg, also das Verteilen von "etwas" (z.B. von Betriebsmitteln der Informationsinfrastruktur auf Struktureinheiten). Ebenen-Konzept (level concept) = die Anordnung der Betriebsmittel der Informationsinfrastruktur (insbes. der Verarbeitungssysteme) auf mehreren Ebenen (z.B. Unternehmensebene, Abteilungsebene und Arbeitsplatzebene). Frame (frame) = ein Repräsentationsformalismus für Wissen, bei dem jedes Objekt mit seinen Attributen und Attributewerten in einem Rahmen ("Frame") beschrieben wird. Heraufladen (upload) = das Übertragen von Programmen oder von Daten von einem benutzten Verarbeitungssystem in ein anderes Verarbeitungssystem. Herunterladen (download) = das Übertragen von Programmen oder von Daten aus einem Verarbeitungssystem in das benutzte Verarbeitungssystem. Integration (integration) = eine spezifische Form der Verknüpfung von Elementen zum Ganzen eines Systems. Integrationsbedarf (integration need) = die aus Sicht der Planungsziele nicht ausreichende Abstimmung zwischen den Elementen eines Systems. Integrationsstrategie (integration strategy) = die zusammenfassende Bezeichnung für Erweiterungsstrategie, Entwicklungsstrategie und Kopplungsstrategie bei der Integration von Datenbanksystem und wissensbasiertem System. Kopplung (docking) = eine Maßnahme zur Integration von Systemen verschiedener Formalismen (z.B. Datenverarbeitungssystem und Datenbanksystem). Migration (migration) = der koordinierte Übergang von einer bestehenden Ausgangsplattform auf eine Zielplattform. Modul (module) = das Ergebnis einer systematischen, bestimmten Prinzipien folgenden Zerlegung eines Systems (z.B. eines Programms). Modularität (modularity) = die Eigenschaft eines Systems, nach bestimmten Prinzipien in Moduln zerlegt zu sein. Parameter (parameter) = eine unbestimmte Konstante eines Systems, durch deren verschiedene Wahl sich die Gestalt des Systems verändert. S Q L = Akronym für Structured Query Language; eine durch die ANSI-Norm X3.135-1986 genormte Datenbanksprache für relationale Datenbanksysteme. Systemkonzept (systems concept) = die vom verwendeten Repräsentationsformalismus geprägte Charakteristik eines Systems, wissensbasiertes System (knowledge-based system) = ein System zur Wissensverarbeitung (z.B. ein Expertensystem).

244

Aufgaben der Feinprojektierung

Aufgaben der Systemintegration Generelle Aufgabe der Systemintegration ist es, alle Komponenten des entwickelten Informationssystems so zusammenzufügen und in die bestehende Informationsinfrastruktur einzubinden, daß das Informationssystem produktiv verwendbar ist. Mehrere unterschiedliche Integrationsfelder sind dabei zu betrachten. Erstens geht es um die Verbindung der in den Teilprojekten entwickelten Komponenten, also um die Integration zwischen den entwickelten Teilsystemen. Trotz der Bemühungen, mehrere Komponenten des Informationssystems integrativ zu entwickeln (z.B. durch Objektorientierung, vgl. Lerneinheiten OBOSP und SOBOP), ist es illusorisch anzunehmen, daß es möglich ist, ohne das Entstehen von Integrationsbedarfen zu arbeiten. Die Komplexität des Planungsobjekts und die Arbeitsteiligkeit des Planungsprozesses sind die wesentlichen Ursachen für das Entstehen von Integrationsbedarfen. Zweitens ist die Verbindung der nach unterschiedlichen Systemkonzepten (z.B. prozedurale Anwendungsprogramme, Datenbanken mit deskriptiven Benutzersprachen, wissensbasierte Systeme) entwickelten Komponenten erforderlich, also die Integration innerhalb der Teilsysteme. Da es sich dabei nicht nur um Entwicklungsergebnisse des betrachteten IuK-Projekts, sondern auch um Entwicklungsergebnisse aus früheren IuK-Projekten (also um Komponenten der vorhandenen Informationsinfrastruktur) handeln kann, ist die Einbindung in die bestehende Informationsinfrastruktur ein drittes Integrationsfeld. Abbildung EINTE-1 veranschaulicht die Aufgaben der Systemintegration. Da die Entwicklung des Sicherungssystems als Querschnittsaufgabe verstanden wird und da die Entwicklung der Sicherungsmaßnahmen teilweise in anderen Teilprojekten erfolgt, wird das Sicherungssystem nicht ausdrücklich berücksichtigt. Aus Abbildung EINTE-1 sind die ersten beiden Integrationsfelder erkennbar, also die Integration zwischen den Teilsystemen und die Integration unterschiedlicher Systemkonzepte innerhalb der Teilsysteme.

Physisches Modell Datensystem

Physisches Modell Arbeitsorganisation

X

Physisches Modell Methodensystem 1

i

Physisches Modell Transportsystem

Informationsinfrastruktur Abb. EINTE-1: Aufgaben der Systemintegration bei der Systementwicklung

Aufgabenschwerpunkte liegen erfahrungsgemäß im Datensystem und im Methodensystem. Integrationsbedarfe im Datensystem entstehen vor allem, dann wenn Teile des Datensystems als konventionelle Dateien, andere Teile als Datenbanksystem realisiert sind. Integrationsbedarfe im Methodensystem entstehen vor

EINTE - Integration der Systementwicklung

245

allem durch unterschiedliche Systemkonzepte der Methodenbasis (vgl. Lerneinheit WMESY), beispielsweise in prozeduralen Programmiersprachen implementierte Anwendungsprogramme einerseits und wissensbasierte Systeme andererseits, aber auch durch unterschiedliche Systemkonzepte bei den Anwendungsprogrammen (z.B. Individualsoftware und Programme von Methodenbanken). Erfahrungsgemäß treten erhebliche Integrationsbedarfe beim Einfügen von Standardsoftware (z.B. SAP) in eine Anwendungsumgebung auf, die über Jahrzehnte durch die Entwicklung von Individualsoftware entstanden ist. Eine weitere Aufgabe der Systemintegration ergibt sich aus der Dezentralisierung der Informationsinfrastruktur ("Ebenen-Konzept"). Vor allem im Datensystem bestehen zwischen den Ebenen Integrationsbedarfe (z.B. wenn von Arbeitsplatzcomputern auf Daten, die auf Hostsystemen auf Unternehmensebene geführt werden, zugegriffen werden soll). Wenn das neu geschaffene Informationssystem ein relationales Datenbanksystem verwendet und die Altsysteme dateiorientiert sind, liegen grundlegend verschiedene Datenstrukturen vor, die zu erheblichen Integrationsbedarfen führen. Durch eine projektspezifische Systemintegration lassen sie sich nicht beseitigen. Eine grundlegende Bereinigung der unternehmensweiten Datenbasis ist in einer gewachsenen Anwendungsumgebung nur über einen längeren Zeitraum möglich, zumal auch der AnwendungsprogrammBestand davon betroffen ist. Mit verschiedenen Migrationsstrategien wird versucht, die Integrationsbedarfe zwischen Neusystemen und Altsystemen zu beseitigen (vgl. Lerneinheiten DAKON und PRADA). Aus dem umfangreichen Aufgabenkomplex der Systemintegration werden Integrationsmaßnahmen für folgende Einzelaufgaben erläutert: • • • •

die die die die

Integration Integration Integration Integration

Integration

von von von von

Anwendungsprogrammen und Datenbanksystemen; Anwendungsprogrammen und wissensbasierten Systemen; Individualprogrammen und Methodenbanken; Arbeitsorganisation und Methodensystem.

Anwendungsprogramme/Datenbanksysteme

Das Datensystem wird heute als relationales Datenbanksystem implementiert. Die Integration zwischen den Anwendungsprogrammen und dem Datenbanksystem erfolgt über eine logische Schnittstelle, entweder mit einem systemspezifischen Format oder über einen SQL-Ausdruck (weitgehend üblich). Erfolgt die Abfrage in der Weise, daß sie von dem anfordernden Programm nicht beeinflußt werden kann, wird von Transaktionsbetrieb gesprochen. Datenbanksysteme unter Betriebssystemen wie UNIX und MS-DOS bieten häufig die Möglichkeit, auf der physikalischen Ebene, also auf den Daten der Datenbank, zu operieren. Dies ermöglicht die Optimierung des Zugriffs, ist jedoch der Datenintegrität und Datensicherheit abträglich. Datenverwaltungsfunktionen (wie Zugriffssynchronisation und Integritätssicherung), welche das Datenverwaltungssystem zur Verfügung stellt, sorgen für Datenintegrität und Datensicherheit. Werden konventionelle Dateien verwendet, dann muß der Entwickler die Integration zwischen den Anwendungsprogrammen und dem Datensystem durch entsprechende Vorkehrungen in den Anwendungsprogrammen sicherstellen.

246

Aufgaben der Feinprojektierung

Integration Anwendungsprogramme/wissensbasierte

Systeme

Mit zunehmender Verwendung von wissensbasierten Systemen zur Unterstützung schlecht strukturierter Aufgaben, bei gleichzeitiger Verwendung von herkömmlichen Anwendungsprogrammen zur Unterstützung gut strukturierter Aufgaben, entsteht das Problem, beide Systemkonzepte in einer Anwendungsumgebung zu integrieren. Methodische Schwierigkeiten resultieren daraus, daß herkömmliche Anwendungsprogramme meist in einer prozeduralen Programmiersprache (vgl. Lerneinheit SPROM) implementiert sind, also auf einem Steuerungsmodell beruhen, das mit den in einem wissensbasierten System verwendeten Formalismen zur Wissensdarstellung (vgl. Lerneinheit SWISS) nicht vereinbar ist. Zwei alternative Integrationsmaßnahmen sind denkbar: • Es existieren beide Formalismen unabhängig nebeneinander, sodaß lediglich über eine Schnittstelle eine Verbindung zwischen beiden Systemen besteht ("lose Kopplung"). • Es werden beide Formalismen miteinander vereinigt, indem das Anwendungsprogramm Teil der Wissensbasis wird ("feste Kopplung"). Die lose Kopplung kann durch statische Kopplung erfolgen, indem ein Unterprogramm als Modul in das wissensbasierte System eingebunden wird oder indem das Anwendungsprogramm das wissensbasierte System als Modul enthält. Die Abhängigkeit des Moduls vom Hauptprogramm wird durch die Form der Schnittstelle bestimmt. Entweder erfolgt die Übergabe von Parametern ("Parameterkopplung"), oder es werden gemeinsame Speicherbereiche verwendet ("Datenstrukturkopplung"). Bei der Parameterkopplung ruft das wissensbasierte System das Unterprogramm auf und erhält vom Unterprogramm ein Ergebnis. Bei der Datenstrukturkopplung werden die Komponenten des wissensbasierten Systems - außer der Wissensbasis - selbst als Unterprogramme geführt; erst zur Laufzeit des Anwendungsprogramms greift die Inferenzkomponente des wissensbasierten Systems auf die Wissensbasis zu. Die Parameterkopplung erlaubt - im Unterschied zur Datenstrukturkopplung - eine hohe Modularität, sodaß das Modul ohne aufwendige Anpassungen auch in anderen Programmen verwendet werden kann. Die lose Kopplung kann auch als dynamische Kopplung erfolgen, indem das Anwendungsprogramm zur Laufzeit des wissensbasierten Systems als Tochterprozeß oder - falls ein Mehrprogrammsystem als Zielsystem verwendet wird - als eigenständiger Prozeß aufgerufen wird. Die Kommunikation zwischen den Prozessen kann durch einen Ein-/Ausgabe-Datenstrom ("pipe") erfolgen, der von den Prozessen interpretiert wird. Dadurch sind beide Systeme erst zur Laufzeit voneinander abhängig. Da beide Systeme im Hauptspeicher resident sein müssen, hat die dynamische Kopplung einen großen Hauptspeicherbedarf. Die feste Kopplung ist nur möglich, wenn beide Systeme nicht nur auf der Implementierungsschicht, sondern auch auf der Ebene der Repräsentationsformalismen verbunden werden. Voraussetzung für die Realisierung der festen Kopplung sind Werkzeuge für wissensbasierte Systeme, die über die gleichen - meist sequentiellen - Formalismen verfügen, die in herkömmlichen Anwendungspro-

EINTE - Integration der Systementwicklung

1A1

grammen verwendet werden. Mit der Portierung eines Algorithmus in ein wissensbasiertes System ist eine erhebliche Verlängerung der Laufzeit verbunden. Abbildung EINTE-2 gibt einen Überblick über die Formen der Integration zwischen Anwendungsprogrammen und wissensbasierten Systemen. Integrationsformen lose Kopplung feste Kopplung I = Expertensystem Anwendungsprogramm als Modul des als Modul des Anwendungsprogramms Expertensystems Parameterkopplung

Datenstrukturkopplung

Parameterkopplung

Datenstrukturkopplung

Abb. EINTE-2: Integrationsformen zwischen Anwendungsprogrammen und wissensbasierten Systemen (Quelle: nach Bechtolsheim)

Integration wissensbasierte Systeme/Datenbanksysteme Wie die meisten Anwendungen, erfordern auch mit wissensbasierten Systemen unterstützte Aufgaben den Zugriff auf Daten, die in Datenbanken geführt werden. Häufig operieren wissensbasierte Systeme mit großen Faktenmengen in ihrer Wissensbasis, die eine Datenverwaltung erforderlich machen. Schließlich benötigen wissensbasierte Systeme, die von vielen Anwendern genutzt werden, Datenverwaltungsfunktionen für die Wissensbasis (z.B. für die Zugriffskontrolle, die Synchronisation bei Mehrfachzugriff und die Datensicherung). Aus diesen Gründen müssen wissensbasierte Systeme mit Datenbanken integriert werden. Dafür bieten sich drei Strategien an: • Erweiterung eines der beiden Systemkonzepte ("Erweiterungsstrategie"); • Entwicklung anwendungsbezogen integrierter Wissensbankverwaltungssysteme ("Entwicklungsstrategie"); • Kopplung der unabhängig voneinander entwickelten Systeme ("Kopplungsstrategie"). Erweiterungsstrategie und Entwicklungsstrategie gehen in der Regel über das hinaus, was in einem bestimmten IuK-Projekt eines Anwenders geleistet werden kann; sie stellen eher Grundlagenentwicklung dar (z.B. beim Software-Anbieter). Aus diesem Grund wird hier nur auf die Kopplungsstrategie eingegangen; sie wird vermutlich noch auf längere Sicht die dominierende Strategie der Integration von wissensbasierten Systemen mit Datenbanksystemen sein. Die einfachste Form der Integration ist die Transaktionskopplung, bei der vom wissensbasierten System Transaktionsaufrufe an das Datenbanksystem abgegeben werden. Kommerziell verfügbare Kl-Sprachen (vgl. Lerneinheit SWISS) erlauben den Aufruf von Datenbank-Update- und Retrieval-Funktionen (z.B. auf Basis von SQL). Während der Bearbeitung einer Transaktion durch das Daten-

248

Aufgaben der Feinprojektierung

banksystem wartet das wissensbasierte System auf die Rückgabe des Ergebnisses; dieser sequentielle Ablauf kann - besonders bei Mehrbenutzer-Betriebssystemen zu erheblicher Verlängerung der Antwortzeit des wissensbasierten Systems führen. Ursache dafür ist, daß wissensbasierte Systeme typischerweise auf Einzelfakten arbeiten, während Datenbanksysteme für den mengenorientierten Zugriff optimiert sind. Zur Vermeidung dieses Problems ist es denkbar, eine Pufferungsstrategie zu verwenden, das heißt den für die aktuelle Anwendung benötigten Teil der Datenbank zu duplizieren ("Herunterladen") und im direkten Zugriff des wissensbasierten Systems verfügbar zu halten ("Download-Kopplung"). DownloadKopplung ist zweckmäßig, wenn das wissensbasierte System auf einem dezentralen Arbeitsplatzsystem installiert ist, auf ein zentrales Datenbanksystem zugreifen kann und über eine Schnittstelle zum Herunterladen verfügt (z.B. durch ein eigenes Datenverwaltungssystem oder durch den direkten Zugriff auf Dateien). Hauptproblem dieser Integrationsmaßnahme ist die Sicherung der Datenintegrität, da erst beim Heraufladen die lokal veränderten Daten in das zentrale System gebracht werden. Transaktionskopplung und Download-Kopplung über Schnittstellen sind unbefriedigend, weil die Abbildung der Fakten in eine Datenbank nicht in der Weise erfolgen kann, in der viele Repräsentationsformalismen auf einer Faktenbasis arbeiten (z.B. können "Vererbungsfähigkeiten" des Frame-Konzepts nicht auf eine Datenbankschnittstelle abgebildet werden). Diese Schwierigkeiten haben zu der Idee geführt, die den Datenbanken zugrunde liegenden Datenmodelle (insbes. das relationale Datenmodell) mit den bekannten Repräsentationsformalismen in einer Wissensbasis zu integrieren ("Expert Database System"). Beim Expert Database System wird entweder vom Datenbanksystem ausgegangen, das mit Inferenzfähigkeiten ausgestattet wird, oder vom wissensbasierten System, dem ein (relationales) Datenmodell als weiterer Formalismus hinzugefügt wird. Integration

Individualprogramme/Methodenbanksysteme

Der Anwender benutzt Methoden einer Methodenbank (d.h. Unterprogramme), indem er sie in eigenen Anwendungsprogrammen (d.h. in Hauptprogrammen) aufruft. Die Art des Aufrufs hängt von der Programmiersprache ab, in der das Individualprogramm implementiert ist. Die Versorgung der Unterprogramme mit Daten und die Übergabe der Ergebnisse von den Unterprogrammen an das Hauptprogramm erfolgt ausschließlich über Übergabeparameter ("Parameterliste"); die Beschreibung der Übergabeparameter befindet sich in der Unterprogramm-Beschreibung. Die Unterprogramme (außer den speziellen Ein-/Ausgabemethoden) haben keine eigene Ein-/Ausgabe von externen bzw. auf externe Dateien. Die Integration zwischen den Unterprogrammen einer Methodenbank und der Datenbasis erfolgt immer über das Hauptprogramm. Integration

Arbeitsorganisation/Methodensystem

Die Integration zwischen der Arbeitsorganisation und dem Methodensystem erfolgt über die Benutzeroberfläche. Dazu wird der Teil der Aufgabe, der im Methodensystem durch herkömmliche Anwendungsprogramme oder Experten-

EINTE - Integration der Systementwicklung

249

systeme unterstützt wird ("Sachaufgabe"), durch eine als Interaktionsaufgabe bezeichnete Aufgabe ergänzt. Zweck der Interaktionsaufgabe ist die Kommunikation des Benutzers mit der Sachaufgabe und damit die Integration zwischen der Arbeitsorganisation und dem Methodensystem. Bei der Gestaltung der Benutzeroberfläche geht die Entwicklung von zeichenorientierten Darstellungen zu grafischen Darstellungen mit mehreren Ebenen in Form von Fenstern und der Verwendung von Zeigeinstrumenten (insbes. Maus). Da die Gestaltung der Benutzeroberfläche primär von den Benutzeranforderungen ausgeht und nicht vom Methodensystem und seiner physischen Realisierung als herkömmliches Anwendungsprogramm oder als Expertensystem, gibt es diesbezüglich keine grundsätzlichen Unterschiede zwischen beiden Systemkonzepten (vgl. Lerneinheiten EAORG und PKOER). Damit gilt das bei herkömmlichen Anwendungsprogrammen verfolgte Ziel, eine einheitliche Benutzeroberfläche zu schaffen, auch für Expertensysteme, in denen herkömmliche Anwendungsprogramme und Expertensysteme verwendet werden. Vorgehensweise bei der Systemintegration In Anbetracht der gezeigten Unterschiedlichkeit der Integrationsaufgaben, kann nur eine sehr allgemeine Vorgehensweise angegeben werden, die aus den erläuterten Integrationsaufgaben abgeleitet ist. Die in Abbildung EINTE-3 genannten Arbeitsschritte müssen, unter Berücksichtigung der in einem IuK-Projekt bestehenden Integrationsbedarfe, angepaßt und präzisiert werden.

Abb. EINTE-3: Arbeitsschritte bei der Systemintegration

Erster Arbeitsschritt: Feststellen der Integrationsbedarfe. Die Schnittstellen zwischen den entwickelten Komponenten des Informationssystems sowie zwischen dem Informationssystem und der Informationsinfrastruktur werden

250

•

•

•

•

Aufgaben der Feinprojektierung

systematisch daraufhin überprüft, an welchen Stellen durch das IuK-Projekt Integrationsbedarfe entstanden sind. Festgestellte Integrationsbedarfe werden dokumentiert (vgl. Lerneinheit DOKUM). Die Dokumentation wird für die folgenden Arbeitsschritte verwendet. Zweiter Arbeitsschritt: Festlegen der Integrationsmaßnahmen. Für jeden festgestellten Integrationsbedarf wird zumindest eine wirkungsvolle Integrationsmaßnahme festgelegt. Dabei wird von dem Bestand bekannter und verfügbarer Integrationsmaßnahmen ausgegangen (vgl. dazu die erläuterten Beispiele); gegebenenfalls müssen weitere Integrationsmaßnahmen entwickelt werden. Dritter Arbeitsschritt: Bewerten der Integrationsmaßnahmen. Häufig gibt es mehrere alternative Integrationsmaßnahmen für einen bestimmten Integrationsbedarf. Zur Auswahl ist dann eine Bewertung der Alternativen erforderlich. Für das Bewerten müssen Bewertungskriterien, die sich an den Planungszielen und den Projektzielen orientieren (vgl. Lerneinheit FORMZ), verwendet werden (z.B. Entwicklungsaufwand, Laufzeit, Wiederverwendbarkeit und Wartbarkeit). Zur methodischen Unterstützung wird die Nutzwertanalyse (vgl. Lerneinheit NUTZW) verwendet. Vierter Arbeitsschritt: Testen der Integrationsmaßnahmen. Die Wirkung der Integrationsmaßnahmen kann nur durch empirisches Testen festgestellt werden (vgl. Lerneinheit TESTM). Beim Testen kann sich herausstellen, daß die Integrationsmaßnahme den Integrationsbedarf nicht voll abdeckt. In diesem Fall wird zum zweiten Arbeitsschritt zurückgekehrt, und es werden andere Integrationsmaßnahmen festgelegt oder entwickelt. Fünfter Arbeitsschritt: Beschreiben der Integrationsdefizite. Stehen Integrationsmaßnahmen zur Abdeckung aller Integrationsbedarfe nicht zur Verfügung, dann verbleiben Integrationsdefizite. Diese werden in der Systemdokumentation beschrieben. Die Beschreibung soll so erfolgen, daß es dem Benutzer möglich ist, die Integrationsdefizite auszugleichen bzw. das Informationssystem so zu verwenden, daß die Integrationsdefizite nicht zu Fehlern bei der Nutzung führen.

Forschungsbefunde Weber et al. berichten über Ergebnisse eines Forschungsprojekts, in dem ein "Verhandlungsmechanismus" zwischen drei einfachen wissensbasierten Systemen in Laborstudien empirisch untersucht wurde. Die Verteilung der Gesamtaufgabe auf die kooperierenden Teilsysteme erfolgte nach funktionalen Gesichtspunkten (d.h. jedem der drei wissensbasierten Systeme wurden bestimmte Funktionen fest zugeordnet); andere Verteilungen können an regionalen oder an produktbezogenen Kriterien ausgerichtet werden. Die Autoren zeigen den Aufbau des Verhandlungsmechanismus und den Ablauf der Interaktion zwischen den Teilsystemen. Eine vergleichende Bewertung mit einer zentralen Wissensbasis erfolgt nicht. Methodenverweise Integrationsprinzipien (Lerneinheit PINTE); Dokumentationsmethoden (Lerneinheit DOKUM); Nutzwertanalyse (Lerneinheit NUTZW); Objektorientierte Programmiersprachen (Lerneinheit SOBOP); Testmethoden (Lerneinheit TESTM).

EINTE - Integration der Systementwicklung

251

Kontrollfragen 1. Welcher Zweck wird mit der Integration der Systementwicklung verfolgt? 2. Welcher Zusammenhang besteht zwischen Systemintegration und Migration? 3. Mit welchen Strategien kann die Integration von Anwendungsprogrammen und Datenbanksystemen erfolgen? 4. Warum ist fiir den Anwender nur die Kopplungsstrategie von Bedeutung? 5. In welche Arbeitsschritte kann die Vorgehensweise bei der Systemintegration gegliedert werden? Quellenliteratur Bechtolsheim, M. von: Der gordische KI-Knoten: Die technische Integration von Expertensystemen. In: Information Management 1/1991, 2 4 - 3 1 Jarke, M.: Wissensbasierte Systeme - Architektur und Einbettung in betriebliche DV-Landschaften. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990,459 - 479 Weber, E. et al.: Ein Verhandlungsmechanismus zwischen drei einfachen Wissensbasierten Systemen. In: WIRISCHAFISINFCRMA3IK 1/1990, 59 - 70 Vertiefungsliteratur Al-Zobaidie, A. and Grimson, J. B.: Expert Systems and Database Systems - how can they serve each other? In: Expert Systems 2/1987, 30 - 37 Bechtolsheim, M. von: Die informationstechnische Integration von Expertensystemen: Stand der Technik, Probleme und Lösungsansätze. In: Gesellschaft für Mathematik und Datenverarbeitung (Hrsg.): Jahresbericht 1988. St. Augustin 1989,71 - 83 Jarke, M. and Vassiliou, Y.: Coupling Expert Systems with Database Systems. In: Reitman, W. (Ed.): Artificial Intelligence Applications for Business. Norwood/N.J. 1984, 65 - 85 Mertens, P.: Enriching Conventional PPS Systems by Knowledge-Based Elements. In: Proceedings of the International Conference on Artificial Intelligence in Industry & Government. Hyderabad/India 1989, 271 - 290 Reuter, A.: Kopplung von Datenbank- und Expertensystemen. In: Informationstechnik 3/1987, 164-175

PSOFT - Prinzipien der Software-Entwicklung Lernziele Sie kennen den Zweck der Prinzipien der Software-Entwicklung. Sie erkennen die Abhängigkeiten und Wechselwirkungen zwischen mehreren Prinzipien. Sie erkennen die Vorteile, die mit der Anwendung der Prinzipien verbunden sind. Sie wissen, daß Programmiersprachen in unterschiedlicher Weise in der Lage sind, die Umsetzung der Prinzipien in Software zu unterstützen. Definitionen und Abkürzungen Abstraktion (abstraction) = das Abgehen vom Konkreten, das Hervorheben des Wesentlichen aus dem Zufälligen, das Erkennen gleicher Merkmale. Synonym: Verallgemeinerung. Im Gegensatz dazu: Konkretisierung. Hierarchie (hierarchy) = eine stufenmäßig aufgebaute Ordnung der Elemente eines Systems, häufig in der Form einer Rangordnung mit von oben nach unten abnehmender Bedeutung. Komplexität (complexity) = der Zustand eines Systems, der durch die Anzahl unterscheidbarer Beziehungen zwischen seinen Subsystemen beschrieben wird. Lesbarkeit (readability) = die Beschaffenheit eines Programms bezüglich seiner Struktur und Dokumentation im Hinblick auf seine Eigenschaft, von Menschen gelesen werden zu können. Modul (module) = eine Sammlung von Objekten und Algorithmen in der Form, daß die Kommunikation mit der Umgebung nur über eine definierte, möglichst schmale Schnittstelle erfolgt; die Benutzung eines Moduls setzt keine Kenntnis seines inneren Aufbaus voraus ("Geheimnisprinzip"). Modularisierung (modulizing) = die Zerlegung eines Systems in kleine, weitgehend unabhängige Einheiten ("Moduln"). Prinzip (principle) = ein Grundsatz, eine Regel oder eine Richtschnur für Denken und Handeln. Rangordnung (rank order) = eine abstufende Wertordnung von Objekten, durch die ein Vorzug, eine Überordnung oder eine Unterordnung der Objekte ausgedrückt wird. Standardisierung (standardization) = die Ausrichtung des Handelns an einem Standard oder an mehreren Standards. Struktur (structure) = die vom Detail losgelöste, auf die wesentlichen statischen Merkmale eines Systems reduzierte Darstellung. Verständlichkeit (understandability) = die Eigenschaft der Dokumentation eines Systems, seinem Benutzer den Zweck des Systems offenlegen zu können. Wartbarkeit (serviceability) = die Eigenschaft eines Systems, an veränderte Anforderungen mit geringem Aufwand anpaßbar zu sein. Wiederverwendbarkeit (reuse) = die Möglichkeit, einmal entwickelte Komponenten eines Systems auch für andere, später entwickelte Systeme verwenden zu können. Zerlegung (decomposition) = das systematische Zergliedern eines Systems in Subsysteme so, daß die Subsysteme bezüglich der verfolgten Ziele möglichst homogen sind.

PSOFT - Prinzipien der Software-Entwicklung

253

Zweck der Prinzipien Zweck der Prinzipien der Software-Entwicklung ist es, die Herstellung qualitativ guter Software ("Software-Qualität") mit einem wirtschaftlich vertretbaren Aufwand zu unterstützen. Um die Prinzipien umzusetzen, sind geeignete Entwurfsmethoden, Werkzeuge (vgl. Lerneinheit WERSP) und Programmiersprachen (vgl. Lerneinheiten SPROM, SOBOP, SVIER und SWISS) erforderlich. Software-Qualität wird durch äußere und durch innere Anforderungen bestimmt. Äußere Qualitätsanforderungen sind Geschwindigkeit, Benutzbarkeit und Wartbarkeit. Damit die äußeren Qualitätsanforderungen erreicht werden, müssen die inneren Qualitätsanforderungen erfüllt werden, deren wichtigste Korrektheit, Robustheit, Erweiterbarkeit, Wiederverwendbarkeit und Verträglichkeit sind. • Korrektheit ist die Eigenschaft von Software, die durch die Spezifikation definierten Anforderungen fehlerfrei zu erfüllen. • Robustheit ist die Eigenschaft von Software, auch unter außergewöhnlichen Bedingungen korrekt zu funktionieren. • Erweiterbarkeit ist die Eigenschaft von Software, mit geringst möglichem Aufwand an veränderte Anforderungen angepaßt werden zu können. • Wiederverwendbarkeit ist die Eigenschaft von Software, ganz oder teilweise für andere Aufgaben verwendet werden zu können. • Verträglichkeit ist die Eigenschaft von Software, mit anderer Software verbunden werden zu können. Prinzipien der Software-Entwicklung sollen die Erreichung dieser Qualitätsanforderungen sichern helfen. Dabei zeigt sich, daß Korrektheit und Robustheit durch Prinzipien begünstigt werden, die systematisches, auf präziser Spezifikation beruhendes Handeln in den Mittelpunkt stellen. Erweiterbarkeit, Wiederverwendbarkeit und Verträglichkeit erfordern eher Prinzipien, die flexible Entwürfe unterstützen, die aus festen, durch definierte Schnittstellen verbundenen Moduln bestehen. Folgende Prinzipien sollen beachtet werden: • das Prinzip der konstruktiven Voraussicht und methodischen Restriktion; • das Prinzip der Abstraktion; • das Prinzip der Modularisierung mit dem Geheimnisprinzip, dem Prinzip der funktionalen und informalen Bindung, dem Prinzip der schmalen Datenkopplung und dem Prinzip der Schnittstellenspezifikation; • das Prinzip der schrittweisen Verfeinerung; • das Prinzip der Strukturierung; • das Prinzip der Hierarchisierung; • das Prinzip der Lokalität; • das Prinzip der integrierten Dokumentation; • das Prinzip der Standardisierung. Einige der Prinzipien scheinen trivial zu sein. Die Schwierigkeit liegt nicht darin, sie zu verstehen, sondern darin, sie anzuwenden. Zum Teil sind die Prinzipien wechselseitig miteinander verbunden und sich gegenseitig voraussetzend; teilweise überschneiden sie sich in ihren Aussagen. Das Prinzip der konstruktiven Voraussicht und methodischen Restriktion nimmt eine Sonderstellung ein, weil es

254

Methoden und Techniken der Feinprojektierung

einen Sachverhalt ausdrückt, der alle anderen Prinzipien überlagert. Zentrale Bedeutung hat das Prinzip der Modularisierung, da es mit weiteren Prinzipien in Wechselwirkung steht und da Modularisierung für mehrere andere Prinzipien Voraussetzung ist. Das Prinzip der Standardisierung ist von peripherer Bedeutung. Nachfolgend werden die genannten Prinzipien erläutert. Prinzip der konstruktiven Voraussicht und methodischen Restriktion Dieses Prinzip bildet die "Basis" für alle anderen Prinzipien. Durch eine bewußte, vorausblickende Konstruktion der Software und die Einhaltung von methodischen Restriktionen soll der Aufwand in nachfolgenden Entwicklungsphasen, insbesondere der Aufwand für die Wartung des installierten SoftwareProdukts, wesentlich reduziert werden. Zur Einhaltung dieses Prinzips muß die Entscheidung, welche Methoden und Werkzeuge in einem IuK-Projekt eingesetzt werden, vor Beginn des Projekts gefällt werden. Nur in außergewöhnlichen Fällen sollte es während des Projekts zu einer grundlegenden Änderung der verwendeten Methoden und Werkzeuge kommen (z.B. wenn das Projekt notleidend ist und saniert werden muß). Prinzip der Abstraktion Eines der wichtigsten Prinzipien zur Beherrschung der Komplexität der Software-Entwicklung ist das Prinzip der Abstraktion. Bei jedem Entwicklungsschritt sollen immer nur die Systemeigenschaften, die für den nächsten Entwicklungsschritt wesentlich sind, hervorgehoben werden; Details sollen (zunächst) vernachlässigt werden. Daher findet ein ständiges Wechselspiel zwischen Abstraktion und Konkretisierung statt. Abstraktion und Konkretisierung sind nicht absolut, sondern relativ; es gibt immer eine mehr oder weniger starke Abstraktion bzw. Konkretisierung. Der Begriff Abstraktionsebene wird benutzt, um Abstufungen der Abstraktion zu bezeichnen. Programmiersprachen unterstützen verschiedene Abstraktionsebenen. • Auf der untersten Ebene ist keine oder nur eine geringe Abstraktion gegeben. Die einzige Möglichkeit, das Abstraktionsniveau zu heben, besteht im Konzept der Subroutinen. Programmiersprachen, die diese Abstraktionsebene unterstützen, sind COBOL, BASIC und Assembler. • Zweck der funktionalen Abstraktion ist es, Funktionen oder Prozeduren durch die Angabe ihres Namens verwenden zu können, ohne irgendwelche Kenntnisse der Implementierung zu benötigen. Es wird das "Was?" beschrieben, nicht das "Wie?", also nicht der Transformationsprozeß der Eingabedaten zu den Ausgabedaten. Funktionale Abstraktionen sind zur Beschreibung von abstrakten Operationen gut geeignet, sie erlauben jedoch keine geeignete Beschreibung von abstrakten Objekten. Programmiersprachen, die diese Abstraktionsebene unterstützen, sind Fortran, Pascal und C. • Um auch abstrakte Objekte beschreiben zu können, wurde auf der nächsten Abstraktionsebene die Datenabstraktion eingeführt. Eine Datenabstraktion besteht aus logisch zusammengehörenden Zugriffsoperationen, die selbst wiederum funktionale Abstraktionen darstellen. Die Datenabstraktion beschreibt

PSOFT - Prinzipien der Software-Entwicklung

255

ein Objekt nicht mehr durch dessen Struktur, sondern charakterisiert es ausschließlich durch die Definition der auf dem Objekt ausführbaren Operationen. Das Modulkonzept ist dieser Abstraktionsebene zuzuordnen. Eine Programmiersprache, die diese Abstraktionsebene unterstützt, ist Modula-2. • Die nächste Abstraktionsebene bringt den Übergang von der Datenabstraktion zum abstrakten Datentyp (abgekürzt: ADT). Ein ADT ist eine Abstraktion, die eine Menge von Objekten durch ihre Datenstruktur und die Operationen auf dieser Datenstruktur beschreibt. Es ist nicht möglich, einen ADT auf einfache Art und Weise zu ergänzen, ohne das Geheimnisprinzip zu verletzen. Eine Programmiersprache, die diese Abstraktionsebene unterstützt, ist Ada. • Die höchste Abstraktionsebene entsteht durch die Einführung erweiterbarer Klassen, wobei unter Klasse eine Menge von Objekten mit gleichen Eigenschaften verstanden wird (mit anderen Worten: die Implementierung eines ADT). Die entstehenden Klassenhierarchien sind die Basis für die objektorientierte Programmierung. Programmiersprachen, die diese Abstraktionsebene unterstützen, sind Smalltalk, C++ und Eiffel. Die Anwendung des Prinzips der Abstraktion bringt folgende Vorteile: • das Erkennen, Ordnen, Klassifizieren und Gewichten von wesentlichen Merkmalen; • das Erkennen allgemeiner Charakteristika als Voraussetzung für Allgemeingültigkeit; • das Trennen des Wesentlichen vom Unwesentlichen. Prinzip der Modularisierung Für den Modulbegriff gibt es zahlreiche, im Detail voneinander abweichende Definitionen, die meist auf bestimmte Kriterien der Modulbildung Bezug nehmen, also selbst wieder Prinzipien sind. Es sind insbesondere die folgenden: • Modulgeschlossenheit: Ein Modul soll eine weitgehend abgeschlossene Aufgabe realisieren; ein bestimmter Algorithmus oder eine bestimmte Datenstruktur soll nicht auf mehrere Moduln verteilt sein. Moduln müssen zu syntaktischen Einheiten der benutzten Programmiersprache passen ("sprachliche Moduleinheiten"). • Minimalität und Sichtbarkeit der Schnittstellen: Schnittstellen zwischen Moduln sollen so einfach wie möglich sein; sie sollen so wenig Parameter wie möglich und möglichst keine Übergangsparameter enthalten. Jeder Modul soll mit möglichst wenig anderen kommunizieren. Wenn zwei Moduln A und B miteinander kommunizieren, dann muß das aus der Beschreibung des Moduls A oder des Moduls B hervorgehen ("explizite Schnittstellen"). • Inferenzfreiheit: Einzelne Moduln sollen durch andere ersetzt werden können, ohne daß am Gesamtsystem etwas geändert werden muß. • Modulgröße: Jeder Modul soll so klein wie möglich sein. • Modulkopplung: Die Moduln sollen möglichst unabhängig voneinander sein; sie sollen daher möglichst nur über Prozeduren kommunizieren, nicht über Parameter oder über einen globalen Datenbereich ("Kontextunabhängigkeit"). Die Kontextunabhängigkeit eines Moduls ist umso höher, je geringer seine Kopplung mit anderen Moduln ist.

256

Methoden und Techniken der Feinprojektierung

• Modulbindung: Innerhalb eines Moduls soll ein enger funktionaler, datenorientierter und sequentieller Zusammenhang bestehen. Der funktionale Zusammenhang wird durch schrittweise Verfeinerung erreicht. Ein Modul ist datenorientiert, wenn er aus Funktionen besteht, die auf denselben Datenstrukturen arbeiten. Sequentiell gebunden ist ein Modul, wenn er aus Funktionen besteht, die nacheinander ausgeführt werden, und deren Ergebnisse jeweils Voraussetzung für die Ausführung der nächsten Funktion sind. Mit dem 1972 erstmals von D. L. Parnas formulierten Geheimnisprinzip wird gefordert, daß die interne Konstruktion eines Moduls, einschließlich der verwendeten Datenstruktur, der Umgebung verborgen bleiben soll. Eine Menge zusammenhängender, änderungswahrscheinlicher Details wird als "Geheimnis" betrachtet und im Modul verborgen. Die Schnittstellen des Moduls geben nur die Eigenschaften wieder, die für die Funktionsweise des Moduls wesentlich sind. Modularisierung meint nicht nur modulare Zerlegbarkeit, sondern auch modulare Kombinierbarkeit, modulare Verständlichkeit, modulare Stetigkeit und modulare Geschütztheit. Die Anwendung des Prinzips der Modularisierung bringt folgende Vorteile: • hohe Wartbarkeit durch leichten Austausch von Moduln und leichte Erweiterbarkeit der Moduln; • Erleichterung der Standardisierung; • Verbesserung der Überprüfbarkeit. Programmiersprachen, die das Prinzip der Modularisierung gut unterstützen, sind Modula-2 und Ada. Eine Schwäche ihres Modulkonzepts ist, daß die Moduln statische Größen (d.h. nicht mehrmals instantiierbar) sind. Erst bei objektorientierten Programmiersprachen wird diese Schwäche durch Klassen vermieden. Prinzip der schrittweisen Verfeinerung Das von N. Wirth als "Konstruktionslehre" empfohlene Prinzip der schrittweisen Verfeinerung wird durch die beiden folgenden Arbeitsschritte beschrieben: • Zerlege die betrachtete Aufgabe in Teilaufgaben. • Betrachte jede einzelne Teilaufgabe und zerlege sie wieder in Teilaufgaben, bis diese so einfach sind, daß sie algorithmisch formuliert werden können. Das Prinzip ist sehr funktionsorientiert (daher auch als funktionsorientierte Zerlegung oder top-down-funktionale Vorgehensweise bezeichnet). Es unterstützt einen prozeduralen Entwurf; bei der Verwendung prozeduraler Programmiersprachen ist die Anwendung dieses Prinzips typisch. Grundsätzlicher Mangel ist die Verwendung eines Systembegriffs, der ausschließlich durch eine bestimmte Aufgabe gekennzeichnet ist. Wiederverwendbarkeit wird durch funktionsorientierte schrittweise Verfeinerung nicht gefördert, weil Funktionen wesentlich weniger stabil sind als Datenstrukturen. Funktionsorientierte Zerlegung vernachlässigt die Datenstrukturen. Jede Datenstruktur muß einer Funktion oder mehreren Funktionen zugeordnet werden. Bei Anwendungsaufgaben, die eine starke Datenkomponente haben, geht der

PSOFT - Prinzipien der Software-Entwicklung

257

Einfluß der Datenstruktur in der Programmstruktur verloren. Datenorientierte Zerlegung orientiert sich an den zu verarbeitenden Daten; die Struktur der Software spiegelt die Datenstruktur wider. Die Zerlegung muß daher von den zu verarbeitenden Daten abgeleitet werden. Da Funktionen und Daten komplementäre Rollen spielen, birgt die datenorientierte Zerlegung ein symmetrisches Risiko, nämlich das Risiko, daß die Funktionen nicht ausreichend berücksichtigt sind. Dies führt zur objektorientierten Zerlegung, bei der ein Software-System als eine Menge miteinander kommunizierender Objekte gesehen wird. Jedes Objekt verfügt über von außen nicht sichtbare Datenstrukturen und darauf ausführbaren Operationen. Das Zerlegungsprinzip orientiert sich an der Zusammengehörigkeit von Daten und Funktionen; es berücksichtigt das Geheimnisprinzip. Wird schrittweise Verfeinerung nur als Zerlegungsprinzip verstanden, dann ist sie von der benutzten Programmiersprache unabhängig. Dagegen hängt die Möglichkeit, Verfeinerungen im Programmtext auszudrücken, von den verfügbaren Sprachelementen ab. Insbesondere werden Sprachelemente benötigt, die es gestatten, grobe Algorithmen zu formulieren und deren Anweisungen an anderer Stelle des Programmtextes durch detaillierte Algorithmen zu beschreiben ("Verfeinerungskonstrukte"). Synchron mit der algorithmischen Verfeinerung sollen auch Datenbeschreibungen verfeinert werden können. Prinzip der Strukturierung Das Prinzip der Strukturierung (auch: strukturierte Programmierung) hat sowohl für den Software-Entwicklungsprozeß als auch für das Software-Produkt als Ergebnis des Entwicklungsprozesses große Bedeutung. Beiden soll eine geeignete Struktur aufgeprägt werden. Ein gut strukturierter Software-Entwurf entsteht durch Anwendung des Prinzips der Hierarchisierung und des Prinzips der Modularisierung. Grundidee der strukturierten Programmierung ist es, einem Programm eine Struktur zu geben, bei der die statische Aufschreibung und das dynamische Ablaufverhalten übereinstimmen. Die Vermeidung von unbeschränkten Ablaufstrukturen (wie z.B. GOTO-Anweisungen) ist eine wichtige Maßnahme, um dies zu erreichen. Ein gut strukturierter Anweisungsteil eines Programms entsteht durch Anwendung der drei Grundstrukturen Aneinanderreihung (Sequenz), Auswahl (Selektion) und Wiederholung von Strukturblöcken; Auswahl und Wiederholung existieren in mehreren Ausprägungen. Strukturblock ist dabei ein Stück Programmtext mit einem Eingang und einem Ausgang. Es kann nachgewiesen werden, daß sich damit jeder beliebige Algorithmus beschreiben läßt. Schon 1973 haben Nassi/Shneiderman eine grafische Darstellungsart eingeführt, die nur die Verwendung der drei Grundstrukturen erlaubt ("Nassi/Shneiderman-Diagramm", "Struktogramm", vgl. Lerneinheit DARST). Die Anwendung des Prinzips der Strukturierung bringt folgende Vorteile: • • • •

gute Verständlichkeit; leichte Einarbeitung; höhe Änderungsfreundlichkeit; leichte Wartbarkeit.

258

Methoden und Techniken der Feinprojektierung

Prinzip der Hierarchisierung Ein System hat eine Hierarchie, wenn seine Elemente nach einer Rangordnung angeordnet sind. Elemente gleicher Rangordnung stehen auf derselben Stufe; sie bilden eine Ebene der Hierarchie. Um die Rangordnungen vergleichbar zu machen, ist eine Klassifizierung notwendig, die nach den Kriterien Basis, Struktur und Zeitraum erfolgen kann. • Basis der Hierarchie. Damit ist die Beziehung der Systemelemente untereinander gemeint (z.B. Modul A besteht aus Modul B und Modul C; Modul A wird von Modul D verwendet). • Struktur der Hierarchie: Aus der Basis der Hierarchie ergibt sich eine Ordnungsstruktur; die Beziehungen zwischen den Elementen eines Systems (z.B. Objekte, Moduln und Datenstrukturen) und deren Eigenschaften werden mit geeigneten Darstellungsmitteln erfaßt. • Zeitraum der Hierarchie: Wichtig für die Beurteilung von Hierarchien ist der Zeitraum, in dem die Hierarchie existiert. Danach wird zwischen Entwicklungshierarchie, statischer Hierarchie und dynamischer Hierarchie unterschieden. Die Anwendung des Prinzips der Hierarchisierung bringt folgende Vorteile: • • • •

Strukturierung des Software-Produkts; Erhöhung der Verständlichkeit; Verbesserung der Wartbarkeit; Reduzierung der Komplexität.

Prinzip der Lokalität Das Lösen von Aufgaben und das Verstehen der Aufgabenlösung wird erleichert, wenn alle wichtigen Informationen lokal komprimiert, das heißt an einem Platz vorhanden sind. Logisch zusammengehörige Teile sollen daher auch in einem Programmtext in physischer Nachbarschaft stehen. Programmiersprachen sollen über Sprachelemente zur Unterstützung des Lokalitätsprinzips verfügen. Zur Lokalität gehört auch die Vereinbarung von Daten an den Stellen eines Programms, wo die Verarbeitung erfolgt. Optimale Lokalität liegt beispielsweise dann vor, wenn die zur Fehlersuche in einem Modul benötigten Informationen alle auf einer Seite Programmcode zu finden sind. Die Beachtung des Prinzips der Lokalität bringt folgende Vorteile: • schnelle Einarbeitung; • gute Verständlichkeit und Lesbarkeit; • leichte Wartbarkeit. Prinzip der integrierten Dokumentation Ein Software-Produkt besteht aus dem Programm-Code und der ProgrammDokumentation; die Dokumentation ist ein wesentlicher Bestandteil des Produkts. Das Produkt ist erst fertiggestellt, wenn Programm-Code und ProgrammDokumentation vorliegen. Die Dokumentation soll möglichst parallel zum Soft-

PSOFT - Prinzipien der Software-Entwicklung

259

ware-Entwicklungsprozeß erstellt werden; sie soll den aktuellen Zustand des Entwicklungsprozesses und seiner Ergebnisse jederzeit wiedergeben. Die Programm-Dokumentation besteht aus Einzeldokumenten mit unterschiedlichen Adressaten, Aufgaben, Inhalten und Formen (vgl. Lerneinheit DOKUM). Es kommt nicht darauf an, möglichst umfangreiche Dokumente zu erstellen, sondern darauf, die Informationen in der Form darzustellen, die für die Zielgruppen der Dokumentation geeignet ist. Dazu ist es notwendig, die Inhalte der Dokumentation sorgfaltig aufeinander abzustimmen und gegeneinander abzugrenzen. Prinzip der Standardisierung Standardisierung ist eine wesentliche Voraussetzung für Wiederverwendung, da sie zu einer Vereinheitlichung des Software-Entwicklungsprozesses und des Software-Produkts führt. Standardisierung läßt sich durch verschiedene Maßnahmen erreichen, insbesondere: • durch Einhalten überbetrieblicher Standards und Normen; • durch Festlegen und Einhalten unternehmensspezifischer Richtlinien; • durch Einsatz von CASE-Werkzeugen und CASE-Systemen. Das konsequente Einhalten von Standards wird nur durch CASE-Werkzeuge bzw. CASE-Systeme (vgl. Lerneinheit WERSP) erreicht, weil es durch sie erzwungen wird und nicht mehr in das Belieben der Entwickler gestellt ist. Die Anwendung des Prinzips der Standardisierung hat folgende Vorteile: • • • •

Vereinheitlichung Vereinheitlichung Vereinheitlichung Verbesserung der

des Software-Entwicklungsprozesses; des Erscheinungsbilds von Dokumenten; der Struktur von Programmen; Lesbarkeit und Wartbarkeit.

Demonstrationsbeispiel Es wird die Verfolgung des Prinzips der Modularisierung an einem Beispiel gezeigt (entnommen aus Puchan et al.). Die Aufgabe besteht darin, die Modulstruktur eines Programms zur Telegrammabrechnung zu entwickeln. Nach dem Einlesen eines Telegramms soll das Tripel (Identifikationscode, Wortzahl, Preis) berechnet und in eine Abrechnungstabelle eingetragen werden. Ferner sollen die Größen "Gesamtwortzahl" und "Gesamtpreis" berechnet werden. Schließlich soll die Ausgabe der aktualisierten Tabelle erfolgen. Die Analyse der Aufgabe führt zur Festlegung der wichtigsten Bestandteile für Telegramm, Preis und Abrechnungstabelle wie folgt: • Telegramm: a) sechsstelliger Identifikationscode b) Menge von Wörtern (durch Leerzeichen getrennt); • Preis: a) pro angefangene zwölf Zeichen eines Wortes DM 0,60 b) Mindestpreis DM 4,20; • Erstellung einer Abrechnungstabelle, die enthält: a) für jedes einzelne Telegramm den Identifikationscode, die Wortzahl und den Preis b) die Gesamtwortzahl und den Gesamtpreis.

260

Methoden und Techniken der Feinprojektierung

Die Zerlegung in Moduln orientiert sich an der zeitlichen Verarbeitungsfolge; sie ergibt: • Modul Eingabe: Einlesen des Telegramms; • Modul Auswertung: a) Wortzahl feststellen b) Preis p berechnen c) Bereitstellung des Tripels (Identifikationscode, Wortzahl, Preis); • Modul Tabelleneintrag: a) Eintragen des Tripels in eine geordnete Tabelle b) Aktualisierung von Gesamtwortzahl und Gesamtpreis; • Modul Ausgabe: Ausgabe Tabelle; • Modul Ablaufkontrolle: a) Aufrufen der einzelnen Moduln in der richtigen Reihenfolge b) Fehlerbehandlung. Abbildung PSOFT-1 zeigt den Ablauf. Dabei bezeichnen einfache Pfeile den Wechsel der Ausführung und doppelte Pfeile den Datenfluß, wobei von einem Modul zum anderen folgende Daten transportiert werden: • • • • •

1: Telegramm in externer Darstellung; 2: Telegramm in interner Darstellung; 3: Abrechnungstripel; 4: Tabelle in interner Darstellung; 5: Tabelle in externer Darstellung.

Die einzelnen Moduln können jetzt schrittweise verfeinert werden. Ablaufkontrolle

^

Eingabe ^

Auswertung ^ Tabelleneintrag ^

Ausgabe

Abb. PSOFT-1: Modulstruktur Programm Telegrammabrechnung Aufgabenverweise Entwickeln des Methodensystems (Lerneinheit EMESY). Kontrollfragen 1. 2. 3. 4. 5.

Welcher Zweck wird mit der Anwendung der Prinzipien der Software-Entwicklung verfolgt? Welche Zusammenhänge bestehen zwischen den Prinzipien der Software-Entwicklung? Was besagt das Prinzip der Modularisierung? Was besagt das Prinzip der schrittweisen Verfeinerung? Was besagt das Geheimnisprinzip?

Quellenliteratur Balzert, H.: Die Entwicklung von Software-Systemen. Prinzipien, Methoden, Sprachen, Werkzeuge. B.I. Wissenschaftsverlag, Mannheim et al. 1982 Meyer, B.: Objektorientierte Softwareentwicklung. Hanser Verlag, MünchenAVien und PrenticeHall International Inc., London 1990

PSOFT - Prinzipien der Software-Entwicklung

261

Puchan, J. et al: Programmieren mit Modula-2. Verlag Teubner, Stuttgart 1991 Willmer, H. und Balzert, H.: Fallstudie einer industriellen Software-Entwicklung. Definition, Entwurf, Implementierung, Abnahme, Qualitätssicherung. B. I. Wissenschaftsverlag, Mannheim et al. 1984 Vertiefungsliteratur Kurbel, K.: Programmentwicklung. 2. A., Verlag Gabler, Wiesbaden 1985 Parnas, D. L.: On the Criteria to be Used in Decomposition Systems into Modules. In: Comm. of the ACM 12/1972, 1053 - 1058 Pomberger, G.: Softwaretechnik und Modula-2. Hanser-Verlag, München/Wien 1984 Pomberger, G. und Blaschek, G.: Software Engineering. Prototyping und objektorientierte Software-Entwicklung. Hanser Verlag, München/Wien 1993 Wirth, N.: Program Development by Stepwise Refinement. In: Comm. of the ACM 4/1971, 221 227

SPROM - Höhere prozedurale Programmiersprachen Lernziele Sie verstehen das Entwickeln der Anwendungssoftware mit höheren prozeduralen Programmiersprachen als den Übergang vom logischen Modell zum physischen Modell des Methodensystems. Sie kennen die von höheren prozeduralen Programmiersprachen verwendeten Sprachkonzepte. Sie kennen die wichtigsten Eigenschaften der Programmiersprachen Modula-2, C und Ada sowie die Eigenschaften der mit ihnen implementierten Programme. Definitionen und Abkürzungen Anwendungsprogramm (application program) = ein vom Anwender für eine bestimmte betriebliche Aufgabe eingesetztes produktives Programm, das nach Durchführung aller Tests für den Echtbetrieb zur Verfügung steht. Befehl (instruction) = eine Anweisung, die sich in der benutzten Programmiersprache nicht mehr in Teile, die selbst Anweisungen sind, zerlegen läßt. Datenkapsel (data capsule) = ein Modul, bestehend aus der Deklaration von Daten und einer Sammlung von Prozeduren, die diese Daten verwalten; auf die Daten des Moduls kann nur über Zugriffsprozeduren zugegriffen werden. Datentyp (data type) = eine Menge definierter Werte, die hinsichtlich der Art der Darstellung (z.B. numerisch, nicht-numerisch) und der Struktur festgelegt ist; jedem Datentyp sind bestimmte Operationen zugeordnet, die auf seine Daten angewendet werden können. Implementierung (implementation) = die Überführung eines Software-Entwurfs in ein Programm mit Hilfe einer Programmiersprache. Kellerspeicher (stack) = ein Datenspeicher, bei dem nur an einem Ende etwas gespeichert und von demselben Ende wieder entnommen werden kann. Kompilierer (Compiler) = ein Übersetzer, der in einer problemorientierten Programmiersprache abgefaßte Quellanweisungen in Zielanweisungen der zugehörigen Maschinensprache umwandelt (kompiliert). Maschinensprache (machine language) = eine Programmiersprache, deren Anweisungen die gleiche oder eine ähnliche Struktur wie die Befehle einer bestimmten digitalen Rechenanlage haben. Programm (program) = eine zur Lösung einer Aufgabe vollständige Anweisung an ein Computersystem, zusammen mit allen erforderlichen Vereinbarungen. Programmiersprache (programming language) = eine zum Abfassen von Programmen geschaffene künstliche Sprache. Programmierung (programming) = der Vorgang des Entwickeins eines Programms. Programmiervorgabe (program specification) = die verbindliche Arbeitsgrundlage für die Programmierung. Operatorüberladung (operator overloading) = die Tatsache, daß für einen Operator mehrere Spezifikationen ("Funktionsdeklarationen") angegeben werden, wobei die zum Typ der Operanden passende Spezifikation verwendet wird (z.B. Operator "+" für zwei Zeichenketten).

SPROM - Höhere prozedurale Programmiersprachen

263

Zweck höherer prozeduraler Programmiersprachen Software-Entwicklung ist der Prozeß, mit dem aus dem logischen Modell des Methodensystems (vgl. Lerneinheit WMESY) und in Abstimmung mit den logischen Modellen des Datensystems (vgl. Lerneinheit WDASY), der Arbeitsorganisation (vgl. Lerneinheit WAORG), des Transportsystems (vgl. Lerneinheit WTRAN) und des Sicherungssystems die Anwendungsprogramme entwickelt werden. Zweck höherer prozeduraler Programmiersprachen ist es, geeignete Strukturen zur Verfügung zu stellen, um eine möglichst einfache Transformation der Entwurfsergebnisse in ausführbare Anwendungsprogramme zu gewährleisten. Die Programmiersprachen müssen es ermöglichen, daß sich die Zerlegungsstrukturen (Methoden und Daten), die beim Entwurf gewählt wurden, in der Implementierung widerspiegeln. Um dieser Anforderung gerecht zu werden, müssen sie geeignete Programmkontrollstrukturen (wie Modul und Prozedur) und Datenstrukturen (einfache und zusammengesetzte Datentypen, abstrakte Datenstrukturen) zur Verfügung stellen. Abbildung SPROM-1 veranschaulicht den Übergang vom logischen Modell zum Anwendungsprogramm.

Aufgabe der Programmiersprache Abb. SPROM-1: Transformation der Entwurfsergebnisse

Der Prozeß der Software-Entwicklung läßt sich in mehrere Teilaufgaben gliedern, die nicht starr nacheinander ablaufen, sondern die teilweise nebeneinander oder überlappt, manchmal auch sich wiederholend zur Entstehung eines Anwendungsprogramms beitragen. Teilaufgaben der Software-Entwicklung mit höheren prozeduralen Programmiersprachen sind: • das Aufbereiten der Ergebnisse der Grobprojektierung und der Feinprojektierung aus allen Teilprojekten zu Programmier vorgaben; • das Entwickeln der Anwendungsprogramme auf der Grundlage der Programmiervorgaben durch das Erarbeiten einer funktionellen Lösung ("Algorithmenbildung") und durch das Erarbeiten einer programmtechnischen Lösung (Programmierung im engeren Sinn);

264

Methoden und Techniken der Feinprojektierung

• das Erstellen der Dokumentation ("Programmdokumentation"), die nicht nur für die Entwicklung, sondern auch für die Nutzung und Wartung der Anwendungsprogramme von Bedeutung ist (vgl. Lerneinheit DOKUM); • das Testen der Anwendungsprogramme (vgl. Lerneinheit TESTM). Konzepte höherer prozeduraler Programmiersprachen Höhere prozedurale Programmiersprachen basieren im wesentlichen auf vier Konzepten, dem Blockkonzept, dem Datentypkonzept, dem Modulkonzept und dem Prozeßkonzept oder Koroutinenkonzept. • Das Blockkonzept ist die Basis für die Anwendung der Unterprogrammtechnik und für das Prinzip der strukturierten Programmierung (vgl. Lerneinheit PSOFT). Es dient dazu, Daten in einem Programm bestimmte Gültigkeitsbereiche (d.h. eine bestimmte Lebensdauer) zuzuordnen. Durch das Blockkonzept soll vor allem die Fehlerquelle, die durch die Verwendung globaler Daten auftritt, ausgeschaltet werden. Weiters ist die Verwendung lokaler Daten speichereffizienter, da der Speicherplatz der Variablen nach dem Verlassen des Blocks freigegeben wird. • Das Datentypkonzept ermöglicht die Konsistenzprüfung von Daten, teilweise schon zur Ubersetzungszeit, spätestens jedoch zur Laufzeit des Programms. Wichtig ist die strenge Typbindung von Daten. Dies bedeutet, daß ein Datum im Verlauf seiner Lebensdauer im Programm den ihm zugeordneten Datentyp nie automatisch ändern kann (es ist allerdings möglich, explizit Daten von einem Datentyp in einen anderen zu konvertieren). Mächtige höhere Programmiersprachen (z.B. Modula-2, Pascal) erlauben es, neben den vordeklarierten Datentypen (z.B. INTEGER, REAL, CHAR), neue selbstdefinierte Datentypen zu deklarieren; damit werden die Programme besser lesbar und änderbar. • Das Modulkonzept ist die Grundlage für die getrennte Entwicklung und Übersetzung (Kompilierung) von Programmmteilen (vgl. Lerneinheit PSOFT). Bei der modularen Programmierung steht die Sicherheit und die leichte Änderbarkeit des damit erstellten Anwendungsprogramms im Vordergrund, nicht so sehr die statische und dynamische Effizienz. Die Sicherheit und die leichte Änderbarkeit der Anwendungsprogramme wird durch das Konstrukt der Datenkapsel weiter erhöht. • Das Prozeßkonzept erlaubt das parallele Abarbeiten von Aktivitäten in einem Computersystem. Dieses Konzept ist vor allem für die Programmierung von Systemsoftware erforderlich. Wichtig dabei sind Mechanismen zur Synchronisation von Prozessen. Darstellung ausgewählter Programmiersprachen Es wird auf die Programmiersprachen Ada und Modula-2, die den heutigen Anforderungen der Softwaretechnik genügen, beispielhaft eingegangen. Wegen ihrer großen Verbreitung wird die Programmiersprache C behandelt. Modula-2 wurde in den Jahren 1977 bis 1980 von N. Wirth aus Pascal und Modula entwickelt. Modula-2 enthält alle Möglichkeiten von Pascal. Die wesentlichen Konzepte von Pascal, nämlich Einfachheit und Beschränkung auf die allernotwendigsten Sprachelemente, das Vorhandensein von strukturierten Daten-

SPROM - Höhere prozedurale Programmiersprachen

265

typen, die durch den Benutzer definierbar sind, und die strenge Typprüfung durch den Compiler wurden übernommen. Darüber hinaus unterstützt Modula-2 das Prozeßkonzept, mit dem die Möglichkeit eines elementaren Multiprogramming gegeben ist, und das Modulkonzept, das die separate Übersetzung von Programmteilen und die Prüfung von Schnittstellen zur Übersetzungszeit ermöglicht. Im Unterschied zu Pascal eignet sich Modula-2 gleichermaßen für die Systemund Anwendungsprogrammierung. Besonders die Einfachheit von Modula-2 (die Sprachdefinition besteht aus 28 Seiten mit 78 Syntaxregeln) und die Ausnutzbarkeit vieler heute bekannter Prinzipien der Softwaretechnik machen Modula-2 zu einer wertvollen höheren prozeduralen Programmiersprache. Ada wurde in den Jahren 1975 bis 1979 von J. Ichbiah entwickelt. Ada sollte auf allen Rechnern des US-Militärs und der NATO lauffähig sein. Vor allem militärische Echtzeitanwendungen sollten realisiert werden können. Obwohl Modula2 und Ada von der Zielsetzung und der geschichtlichen Entwicklung her völlig verschieden sind, bestehen viele Ähnlichkeiten. In beiden Programmiersprachen werden Spezifizierungs- und Implementierungsteil voneinander getrennt. Beide Programmiersprachen gestatten die getrennte Übersetzbarkeit von ProgrammModuln, wobei die Programmstruktur des "Moduls" in Modula-2 fast genau dem "package" von Ada entspricht. In Ada können, wie in Modula-2, parallele Prozesse formuliert werden. Weiters erlaubt Ada die Behandlung von Ausnahmebedingungen, die Erzeugung generischer Programme und das Überladen von Operatoren; hierzu finden sich in Modula-2 keine ähnlichen Konstrukte. Eine Folge der Ähnlichkeit von Ada mit Modula-2 ist, daß in den weitaus meisten Anwendungen statt Ada ebensogut Modula-2 benutzt werden kann. Der Dokumentationswert der beiden Programmiersprachen ist nahezu identisch. Der Nachteil von Ada gegenüber Modula-2 liegt im deutlich größeren Sprachumfang (230 Seiten Sprachdefinition mit 143 Syntaxregeln). C wurde anfang der siebziger Jahre von D. M. Ritchie als Implementierungssprache des Betriebssystems UNIX entwickelt und von B. W. Kernighan verbessert. Ziel war die Schaffung einer effizienten Programmiersprache zur Implementierung systemnaher Software. C ist eine nicht sehr umfangreiche, relativ maschinennahe Programmiersprache, die aber nicht von einem bestimmten Betriebssystem abhängig ist. C verfügt über die üblichen fundamentalen Kontrollstrukturen und strukturierten Datentypen, verfügt aber nicht über eine strenge Datentyp-Prüfung. Dieser Mangel wurde in der objektorientierten Erweiterung von C (C++, vgl. Lerneinheit SOBOP) behoben. Wie bei Modula-2 und Ada, ist es auch bei C möglich, größere Programme auf mehrere Dateien aufzuteilen, diese separat zu übersetzen und danach zu binden. Zur Übersetzungszeit findet allerdings keine Schnittstellenprüfung statt. In C existieren keine Sprachelemente für Multiprogrammierung (Prozeßkonzept) oder Koroutinen; es gibt auch keine Modularisierungshilfsmittel direkt in der Programmiersprache. Der Gestaltungsspielraum für die Programmstruktur wird in C kaum eingeschränkt. Ohne Selbstdisziplin des Programmierers können daher sehr schwer lesbare Programme entstehen.

266

Methoden und Techniken der Feinprojektierung

UNIX hat in den letzten Jahren große Verbreitung gefunden. Wegen der Verbindung mit UNIX ist daher auch C heute weit verbreitet (auf jedem UNIX System befindet sich ein C-Compiler). Dies gilt auch für C++. Bei objektorientierten Datenbanken stellt C++ einen Quasi-Standard dar. Vergleichende Beurteilung der Programmiersprachen Im folgenden werden Modula-2, Ada und C anhand wesentlicher Eigenschaften der mit ihnen implementierten Programme verglichen und beurteilt. Die Beurteilung erfolgt mit den Kriterien Verständlichkeit, Wartbarkeit und Übertragbarkeit. Die Verständlichkeit eines Programms hängt vom Dokumentationswert der Programmiersprache und von der Disziplin des Programmierers ab. Der Dokumentationswert von Modula-2 und Ada liegt weit über dem von C. Trotzdem ist es einem C-Programmierer möglich, Programme mit dem gleichen Dokumentationswert wie mit Modula-2 oder Ada zu entwickeln, jedoch mit einem größeren Zeitaufwand. Bei einem Wechsel von koventionellen Programmiersprachen (wie FORTRAN und PL/1) auf Modula-2 kann der Dokumentationsaufwand erfahrungsgemäß um 50 bis 70% verringert werden. Die Wartbarkeit eines Programms ist seine Eignung zur Fehlerauffindung und Fehlerkorrektur sowie die Möglichkeit, Veränderungen und Erweiterungen ohne großen Aufwand durchführen zu können. Die Wartbarkeit ist insofern von Bedeutung, als praktische Erfahrungen zeigen, daß 80% der Kapazität von Software-Entwicklungsabteilungen für die Wartung und nur 20% für Entwickung von Programmen verwendet werden. Die Verständlichkeit spielt auch für die Wartbarkeit eine entscheidende Rolle (weil mit zunehmender Verständlichkeit die Wartbarkeit zunimmt). Durch Verwendung des Modulkonzepts und von Datenkapseln erreichen in Modula-2 und Ada implementierte Programme ein hohes Maß an Flexibilität, was Änderung und Erweiterung anbelangt. In C muß das Modulkonzept simuliert werden, da es nicht durch Sprachkonstrukte unterstützt wird, um eine ähnliche Flexibilität zu erreichen wie in Modula-2 und Ada. Die Möglichkeit der separaten Übersetzung von Programmteilen, welche in den drei Programmiersprachen gegeben ist, erleichtert die Fehlersuche und verkürzt die Compilier-Zeiten bei Änderungen und Erweiterungen. Die in C fehlende Schnittstellenprüfung zur Übersetzungszeit birgt eine Gefahrenquelle, die auch auf Kosten der Wartbarkeit geht. Die Übertragbarkeit ist die Möglichkeit der Verwendung eines Anwendungsprogramms auf einer anderen Hardware-Plattform oder auf einem anderen Betriebssystem als der bzw. dem, für das es ursprünglich geschrieben wurde. Sowohl bei C als auch bei Modula-2 sind die Ein- und Ausgabe, die Speicherverwaltung und die Behandlung von Zeichenketten nicht im Sprachumfang enthalten, sondern werden in Form von Standardbibliotheken zur Verfügung gestellt. Dies hat den Sinn, daß die an die Eigenheiten des Computers angepaßten Teile einfach zu lokalisieren und zu ändern sind. Auch hier erweist sich das

SPROM - Höhere prozedurale Programmiersprachen

267

Modulkonzept als vorteilhaft. Soll ein Programm auf ein anderes Computersystem übertragen werden, müssen nur die systemabhängigen Moduln neu geschrieben werden. Demonstrationsbeispiel Es werden Modula-2 und C anhand der Implementierung eines Kellerspeichers verglichen. Die Modularisierung muß in C simuliert werden, da sie nicht durch Sprachkonstrukte unterstützt wird. Dem simulierten Modul in C fehlt die Schnittstellenprüfung zur Übersetzungszeit, die in Modula-2 unterstützt wird. Realisierung in Modula-2: DEFINITION MODULE StackMod; TYPE STKItem = INTEGER; VAR empty, stackoverflow: BOOLEAN; PROCEDURE InitStackO; (*Der Kellerspeicher wird

initialisiert.*)

PROCEDURE Push (x:STKItem); ("Kellert das Objekt STKItem. Wenn STKItem nicht mehr gekellert werden kann (Keller voll), wird stackoverfolw=TRUE gesetzt*) PROCEDURE Pop (VAR x:STKItem); ("Liefert das oberste Kellerobjekt STKItem. Wenn der Keller leer ist, wird empty=TRUE gesetzt.*) END StackMod. IMPLEMENTATION MODULE StackMod; CONST stacksize=50; VAR stack: ARRAY [1..stacksize] OF STKItem; VAR top: [0..stacksize] PROCEDURE InitO BEGIN top := 0; empty := TRUE; stackoverflow := FALSE; END Init; PROCEDURE Push(x:STKItem); BEGIN If top

k.

Regel i

Prozedur m

c O N

G

CA Ö o

Abb. SWISS-1: Struktur einer Regel

Regeln sind auch für den Laien verständlich. Mit Regeln können Wissenselemente, die isoliert betrachtet verständlich sind (während das Wissen insgesamt nicht oder nur schwer verständlich ist), dargestellt werden. Der Wissensingenieur kann sich im Dialog mit dem Experten bei der Wissensakquisition auf einzelne Wissenselemente konzentrieren. Weiter: Auf Grund dieser Modularität können einzelne Regeln aus der Wissensbasis entfernt bzw. neue Regeln in sie eingefügt werden, ohne daß andere Regeln deshalb modifiziert werden müssen. Der Informationsgehalt der in einer Regel ausgedrückten WENN/DANN-Beziehung kann durch Zusätze (wie "gilt immer", "gilt manchmal") graduell erhöht werden. Regeln erlauben daher auch die Darstellung von unscharfem Wissen. Regeln können in unterschiedlicher Weise interpretiert werden, und zwar als: • Situations-/Aktionsregeln zur Ansteuerung von Handlungen, z.B.: WENN für Produkt X Hinweise auf Qualitätsmangel Y vorliegen —» DANN veranlasse Einlieferung von A in Sperrlager • Schlußfolgerungsregeln zur Ableitung von Erkenntnissen, z.B.: WENN Qualitätsmangel Y am Produkt X festgestellt wird —¥ DANN liegt vermutlich Bearbeitungsfehler A vor • Vererbungsregeln zur Übertragung von Eigenschaften allgemeiner Objekte auf speziellere Objekte, z.B. WENN X ein Bauteil von Y ist DANN ist X aus Material B Die Datenkomponente enthält die Daten, mit denen die zu bearbeitende Aufgabe beschrieben wird, Statusinformationen zum jeweils aktuellen Bearbeitungsprozeß, Teil-, Zwischen- und Endergebnisse sowie ein Logbuch über den Bearbeitungsprozeß. Auf dieser Datengrundlage kann mit WAS/WENN-Analysen der Beratungsablauf nachvollzogen werden. Häufig wird die Datenkomponente nicht besonders erwähnt, sondern als Teil der Wissenskomponente aufgefaßt. Ein Expertensystem soll die Intelligenzleistung eines menschlichen Experten nachvollziehen, es soll also intelligentes Verhalten simulieren können. Das dazu erforderliche Anwendungs- und Problemlösungswissen ("Expertenwissen") wird in einer Wissensbasis verwaltet. Den Vorgang der systematischen Erhebung und Analyse von Expertenwissen mit dem Ziel, dieses mit einem Formalismus

SWISS - Kl-Sprachen und Wissensverarbeitungssprachen

293

darzustellen und in eine Wissensbasis einzubringen, wird als Wissensakquisition bezeichnet. Abbildung SWISS-2 stellt den Zusammenhang zwischen Expertenwissen, Wissensakquisition und Wissensbasis dar. Die Aufgabe der Wissensakquisition erfordert insbesondere Kenntnisse über die Anwendungsaufgabe des zukünftigen Expertensystems sowie psychologische Kenntnisse, um Experten erfolgreich befragen zu können. Ein Aufgabenträger, der die Wissensakquisition durchführt, wird als Wissensingenieur bezeichnet. Expertenwissen

1

Wissensbasis

Abb. SWISS-2: Zusammenhang zwischen Expertenwissen, Wissensakquisition und Wissensbasis

Der menschliche Experte verwendet bei der Bearbeitung einer Aufgabe nicht nur aufgabenspezifische Fakten ("Faktenwissen"), sondern er wendet auch bestimmte Methoden an. Seine Erfahrung erlaubt es ihm, in Abhängigkeit von der Aufgabe und den Fakten, die am besten geeigneten Methoden auszuwählen und anzuwenden. Fakten sind Kenntnisse des Experten, die Objekte des Wissens oder der Wissensdomäne beschreiben. Objekte können Gegenstände, Ereignisse und abstrakte Kategorien sein. Zwischen den Objekten bestehen Beziehungen; auch diese Beziehungen sind Fakten. Methoden sind Fähigkeiten des Experten, die Wissen über die Anwendung der Fakten beschreiben ("Metawissen"). Solche Fähigkeiten werden im allgemeinen Sprachgebrauch als Erfahrung, Geschicklichkeit, Intuition oder Fingerspitzengefühl bezeichnet. Metawissen ermöglicht die erfolgreiche Bearbeitung von Aufgaben oder erleichtert sie zumindest. Faktenwissen ohne Metawissen würde also nichts nützen oder zumindest nicht viel, weil der Prozeß der Bearbeitung der Aufgabe ohne Metawissen sehr lange dauert. Im allgemeinen wird nur dann jemand als Experte bezeichnet, wenn sein Wissen nicht nur aus Fakten, sondern aus Fakten und Methoden besteht. Wissen läßt sich nach verschiedenen Merkmalen klassifizieren. Eine für die Entwicklung wissensbasierter Systeme brauchbare Unterscheidung folgt der beschriebenen Struktur des Wissens eines Experten. Danach wird zwischen deklarativem Wissen und prozeduralem Wissen unterschieden. • Deklaratives Wissen ist Faktenwissen, also Aussagen über konkrete Objekte der Wirklichkeit oder der Vorstellungswelt des Menschen, und Aussagen über ihre Beziehungen. Die Darstellung dieses Wissens erfolgt unabhängig von den Methoden zu seiner Anwendung (z.B. durch Regeln). Diese Wissensdarstellung ist statisch; über die Anwendung von Wissen wird also keine Aussage gemacht. • Prozedurales Wissen ist Wissen über die Anwendung des Faktenwissens.

294

Methoden und Techniken der Systemplanung

Es fokussiert die Suche nach einer Lösung auf besonders aussichtsreiche Teile des Lösungsraums. Prozedurales Wissen beschreibt bezüglich einer zu bearbeitenden Aufgabe einen Lösungsweg oder mehrere Lösungswege, die zielstrebig ausreichende Lösungen oder sogar die optimale Lösung herleiten lassen. Nicht der gesamte Lösungsraum soll abgesucht werden (wie z.B. bei einer vollständigen Enumeration), sondern nur seine besonders aussichtsreichen Teile. Bei knappen Ressourcen (z.B. knapper Zeit) eine befriedigende Lösung schnell herleiten zu können, ist eine besondere Leistung des menschlichen Experten. Diese Leistung soll auch ein Expertensystem erbringen. Prozedurales Wissen läßt sich in Form von Regeln darstellen. Sind alle Voraussetzungen einer Regel auf Grund des in der Wissensbasis vorhandenen Faktenwissens gegeben, so werden Konsequenzen ausgelöst. Diese können neue Fakten bilden und so die Wissensbasis erweitern ("dynamische Wissensbasis"). Heutige Expertensysteme haben eine Wissensbasis von einigen 100 bis 1000 Regeln. Ein Expertensystem soll sich "intelligent" verhalten. Deshalb muß es nicht nur Wissen darstellen können, sondern auch die Fähigkeit haben, aus dem Wissen Schlüsse ("Inferenzen") zu ziehen ("Schlußfolgern"). Ein Inferenzmechanismus soll gewährleisten, daß in jeder Situation der aussichtsreichste Lösungsweg verfolgt wird. Dazu muß der Inferenzmechanismus zwei Eigenschaften haben: • er muß entscheiden können, wie - basierend auf dem Faktenwissen - der Inferenzprozeß ausgelöst werden soll; • er muß entscheiden können, wie Konflikte gelöst werden, wenn mehrere Wege der Schlußfolgerung möglich sind. Konflikte entstehen, wenn die Voraussetzungen mehrerer Regeln erfüllt sind; es muß dann entschieden werden, welche Regel auszuführen ist. Die Wirksamkeit eines Expertensystems wird stark durch dieses Selektionsverfahren bestimmt. Beim Selektionsverfahren wird immer in den beiden Schritten Vorauswahl und Auswahl vorgegangen. Die Vorauswahl dient der Bestimmung der ausführbaren Regeln, die Auswahl dient der Wahl und Ausführung einer Regel oder der Ausführung aller Regeln. Zur Abarbeitung einer Regel gibt es zwei Abarbeitungsstrategien, nämlich Vorwärtsverkettung und Rückwärtsverkettung. Eine angemessene Abbildung der Vorgehensweise eines menschlichen Experten erfordert die Anwendung beider Abarbeitungsstrategien. Der Benutzer tastet sich an eine Problemlösung heran, indem er abwechselnd Teilziele und wichtig erscheinende Daten eingibt. • Bei der Vorwärtsverkettung wird von den bekannten Fakten ausgegangen und eine Regel gesucht, deren Bedingungsteil ("Voraussetzungen") zutrifft. Daraus werden neue Fakten abgeleitet, die sich aus dem Aktionsteil der Regel ("Konsequenzen") ergeben. Vorwärtsverkettung ist dann zweckmäßig, wenn zwar die Ausgangssituation sehr gut beschrieben werden kann, aber die Anzahl der möglichen Lösungen groß oder sogar unbekannt ist. Mit Hilfe der Fakten und Regeln der Wissensbasis werden neue Zustände erzeugt. Die Menge der Zustände bildet einen Baum, dessen Knoten die Übergänge von einem Zustand

SWISS - Kl-Sprachen

und Wissensverarbeitungssprachen

295

zu einem nächsten Zustand kennzeichnen. Zweck der Vorwärtsverkettung ist es, alle Konsequenzen einer ganz bestimmten Datenkonstellation zu ermitteln. • Bei der Rückwärtsverkettung wird von einer Hypothese über die Lösung der Aufgabe ausgegangen und nach einer Regel gesucht, welche die Hypothese im Aktionsteil enthält und deren Bedingungsteil erfüllt ist. Zweck der Rückwärtsverkettung ist es, auf ganz gezielte Anfragen eine Antwort zu erhalten. Abbildung SWISS-3 zeigt die Architektur eines Expertensystems mit den bisher besprochenen Kernkomponenten sowie den nachfolgend erläuterten ergänzenden Komponenten. Wissensakquisitions-Komponente

Inferenzkomponente

Datenkomponente Wissenskomponente

Erklärungskomponente

Abb. SWISS-3: Architektur eines Expertensystems

• Die Dialogkomponente ist die Schnittstelle zum Benutzer, der entweder Experte oder Laie ist. Der Experte benutzt das Expertensystem, um bei der Bearbeitung einer Aufgabe durch das Wissen anderer Experten unterstützt zu werden. Die Benutzung eines Expertensystems durch einen Laien ist problematisch, da er in Abhängigkeit von dem Expertensystem geraten kann (z.B. wenn er nicht in der Lage ist, die hergeleiteten Ergebnisse zu bewerten). Expertensysteme werden daher häufig als "Chauffeur-Systeme" eingesetzt, bei denen der Laie als Benutzer durch einen Experten unterstützt wird. Die Dialogkomponente muß den Dialog steuern, auf Fragen des Benutzers eingehen und dem Benutzer Erklärungen geben. Sie soll in der Lage sein, die Daten, mit denen der Benutzer die zu bearbeitende Aufgabe beschreibt, auf die wesentlichen Fakten zu reduzieren. • Die Erklärungskomponente macht die Schlußfolgerungen für den Benutzer transparent, indem sie die Regeln auflistet, die verwendet wurden, sie erklärt und möglicherweise auch Hinweise darauf gibt, warum bestimmte Regeln nicht verwendet wurden. Sie ist damit auch Schnittstelle zwischen der Wissenskomponente und der Dialogkomponente. • Die Wissensakquisitions-Komponente unterstützt den Prozeß der Erfassung von Expertenwissen und seine formale Darstellung und Übertragung in die Wissensbasis. Dieser Prozeß erfordert die Strukturierung des Wissens und der verwendeten Fachbegriffe sowie eine Identifizierung der Schlüsselkonzepte der Wissensdomäne und der Bearbeitungsstrategien. Es ist denkbar, die Wis-

296

Methoden und Techniken der Systemplanung

sensakquisitions-Komponente so auszubauen, daß der Experte direkt mit der Wissensbasis kommunizieren kann ("Wissenseditor"). • Die Lernkomponente ändert automatisch die Wissensbasis so, daß die Wirksamkeit des Expertensystems erhöht wird. Sie vollzieht also das Lernphänomen des menschlichen Experten nach. Die Erhöhung der Wirksamkeit kann auf verschiedenen Wegen ("Lernkategorien") erreicht werden (z.B. durch die Erweiterung oder durch die Verbesserung der Problemlösungsleistung, durch Lernen aus Beispielen oder durch Lernen aus Beobachtungen). Demonstrationsbeispiel Es wird gezeigt, wie sich Fakten und Regeln in Lisp darstellen lassen (entnommen aus K. Kurbel). Das Beispiel drückt Wissen über Anwendungssoftware aus, das in einem Konfigurierungssystem enthalten sein kann. Dieses Wissen sind zunächst Fakten über ein Programm namens Magic-Graph wie folgt: Magic-Graph unterstützt 3 D-Darstellung Magic-Graph unterstützt Farbdarstellung Magic-Graph unterstützt Freihandzeichnen Weiter werden die folgenden Zusammenhänge und Schlußfolgerungen in Form von Regeln notiert: Wenn ein Programm 3 D-Darstellung, Farbdarstellung und Freihandzeichnen unterstützt, dann ist es ein Grafikprogramm. Wenn ein Programm ein Grafikprogramm ist, dann ist es Anwendungssoftware. Im folgenden Programmausschnitt sind seif und get vordefinierte Funktionen. (setf {get 'Wissensbasis 'Fakten) '((Magic-Graph supports Drei-D-Darstellung) (Magic-Graph supports Farbdarstellung) (Magic-Graph supports Freihandzeichnen))) (setf (get 'Wissensbasis 'Regeln) '((($if($and (($any Programm) supports Drei-D-Darstellung) (($this Programm) supports Farbdarstellung) (($this Programm) supports Freihandzeichnen))) ($then ($this Programm) is-a Grafikprogramm))) '(($if ($any Programm) is.a Grafikprogramm) ($then ($this Programm) is-a Anwendungssoftware))) Mit dem ersten Aufruf der Funktion set f werden die Fakten mit den Werten (Magic-Graph supports Drei-D-Darstellung) usw. der Wissensbasis als Eigenschaft zugeordnet. Beim zweiten Aufruf werden ihr als weitere Eigenschaft

SWISS - Kl-Sprachen und Wissensverarbeitungssprachen

297

Regeln zugeordnet; diese haben die mit '(($if... eingeleiteten Regeltexte. Das Zeichen $ drückt aus, daß so gekennzeichnete Symbole eine andere als die in Lisp vordefinierte Bedeutung haben. $any gibt an, daß bei der Verarbeitung der Wissensbasis das folgende Symbol (Programm) an dieser Stelle im Ausdruck durch einen Wert ersetzt werden kann, der zu den anderen Symbolen des Ausdrucks "paßt". In der ersten Regel "paßt" Magic-Graph zu supports und Drei-D-Darstellung, weil eine entsprechende Aussage zuvor getroffen wurde. Auf den Wert, der an den Platzhalter Programm gebunden wird, kann an anderen Stellen der Regel mit $this wieder zugegriffen werden. Um eine in dieser Weise codierte Wissensbasis nutzen zu können, muß eine Abarbeitungskomponente vorhanden sein, welche die Symbole $any und $this interpretiert sowie auf den Fakten und Regeln den Mustervergleich durchführt. Die Abarbeitung kann dann durch eine weitere Funktion erfolgen, welche die Symbole $if, $and und $then kennt und unter Verwendung der Funktion Mustervergleich die Regeln bearbeitet. Aufgabenverweise Entwickeln des Methodensystems (Lerneinheit EMESY). Kontrollfragen 1. 2. 3. 4. 5.

Welches sind die wesentlichen Merkmale einer KI-Sprache? Wodurch unterscheiden sich Wissensverarbeitungssprachen von Expertensystem-Shells? Welche Formen von Wissen werden unterschieden? Mit welchen Formalismen kann Wissen dargestellt werden? Aus welchen Kemkomponenten besteht ein Expertensystem?

Quellenliteratur Biethahn, J. und Hoppe, U.: Entwicklung von Expertensystemen - Eine Einführung. Gabler Verlag, Wiesbaden 1991 Kurbel, K.: Entwicklung und Einsatz von Expertensystemen - Eine anwendungsorientierte Einführung in wissensbasierte Systeme. 2. A., Springer Verlag, Berlin et al. 1992 Kurbel, K. und Pietsch, W.: Expertensystem-Projekte. Entwicklungsmethodik, Organisation und Management. In: Informatik Spektrum 12/1989, 133 - 146 Mertens, P. et al.: Betriebliche Expertensystem-Anwendungen. 3. A., Springer Verlag, Berlin et al. 1993 Vertiefungsliteratur Clocksin, W. F. and Mellish, C. S.: Programming in Prolog. 2. A., Springer Verlag, Berlin et al 1984 Hu, D.: C/C++ for Expert Systems. Management Information Source, Inc., Portland/OR. 1989 Karras, D. et al.: Entwicklungsumgebungen für Expertensysteme. Vergleichende Darstellung ausgewählter Systeme. Verlag de Gruyter, Berlin/New York 1987 Keene, S. E.: Object-Oriented Programming in COMMON LISP. A Programmer's Guide to CLOS. Addison-Wesley Publ. Company, Reading/MA. et al. 1989 Merritt, D.: Building Expert Systems in Prolog. Springer Verlag, New York et al. 1989 Schoffa, G.: Die Programmiersprache LISP - Eine Einführung in die Sprache der künstlichen Intelligenz. München 1987 Wenzel, G.: Anwendungen in TURBO PROLOG - Expertensysteme. Hüthig Buch Verlag, Heidelberg 1989 Winston, P. H. und Horn, B. K.: LISP. Addison-Wesley Publ. Company, Bonn et al. 1987

SMEBA - Methodenbanksysteme Lernziele Sie kennen die charakteristischen Merkmale von Methodenbanksystemen und Kriterien, mit denen eine vergleichende Beurteilung durchgeführt werden kann. Sie können beispielhaft die Struktur und den Arbeitsablauf bei der Verwendung von Methodenbanksystemen als einer Form der individuellen Informationsverarbeitung erläutern. Definitionen und Abkürzungen Funktion (function) = eine Methode, die in einer Methodenbank als Programmbaustein realisiert ist und die mit einem Kommando aufgerufen und zum Ablauf gebracht werden kann. Kommando (command) = eine Anweisung, die im Dialogbetrieb über eine Schnittstelle zwischen Funktionseinheiten den Aufruf einer ausführbaren Prozedur bewirkt, sofern sich diese Funktionseinheiten in einem Kommandomodus befinden. Kommandosprache (command language) = eine Programmiersprache, deren Anweisungen Kommandos sind. MEB = Abkürzung für Methodenbank; Kurzbezeichnung für das Software-Produkt "Methodenbank-Bibliothek normierter Unterprogramme für Wirtschaft und Wissenschaft" der Siemens-Nixdorf Informationssysteme. MEMO = Abkürzung für Methodenmonitor; Kurzbezeichnung für das Software-Produkt "Methodenmonitor mit Methoden-, Formel- und Datenbankabfragesprache" der Siemens-Nixdorf Informationssysteme. METHAPLAN = die zusammenfassende Kurzbezeichnung für die Produkte MEB und MEMO der Siemens-Nixdorf Informationssysteme. Methodenbank (method base) = die systematische Sammlung einer Menge von Methoden in Form von Programmbausteinen. Methodenbanksystem (method base system) = die zusammenfassende Bezeichnung für Methodenbank und Methodenverwaltungssystem. Methodenverwaltungssystem (method base management system) = ein Werkzeug zur Verwaltung einer Methodenbank mit analogen Eigenschaften wie ein Datenverwaltungssystem. Parameter (parameter) = eine unbestimmte Konstante einer Funktion, einer Gleichung oder allgemein eines Systems, von der das System abhängt und durch deren verschiedene Wahl ("Parametrisierung") sich die Gestalt des Systems verändert. Programmablauf (program flow) = die logische, dem verwendeten Algorithmus entsprechende Abfolge der Befehle in einem Programm. Programmablaufsteuerung (program flow control) = die Steuerung des Programmablaufs durch das Weiterschalten von einem Befehl zu dem logisch folgenden Befehl, in Abhängigkeit von bestimmten Bedingungen. Programmbaustein (program module) = ein nach Aufbau oder Zusammensetzung abgrenzbares programmtechnisches Gebilde, mit dem eine Methode implementiert ist. SPSS = Akronym für Statistical Package for the Social Science.

SMEBA - Methodenbanksysteme

299

Zweck der Methodenbanksysteme Methodenbanksysteme sind Programmiersysteme für den Teil des Methodensystems, mit dem häufig auftretende, standardisierte betriebliche Aufgaben oder Teilaufgaben unterstützt werden. Im Unterschied zu höheren Programmiersprachen (vgl. Lerneinheiten SPROM und SOBOP) sind die Gestaltungsmöglichkeiten durch den in der Methodenbank vorhandenen Vorrat an Programmbausteinen ("Methodenvorrat") begrenzt. Daher werden Methodenbanksysteme im allgemeinen dazu verwendet, anwenderindividuelle Programme ("Hauptprogramme") durch die vorgefertigten Programmbausteine der Methodenbank ("Unterprogramme") zu ergänzen. Der wichtigste anwendungsbezogene Unterschied zwischen Methodenbanksystemen und Planungsprachen (vgl. Lerneinheit SPLAN) besteht darin, daß Methodenbanksysteme nicht explizit auf eine bestimmte Art von Aufgaben (wie z.B. Planungsaufgaben bei Planungssprachen) zugeschnitten sind. Der Möglichkeit der flexiblen Erweiterung der Methodenbank (z.B. durch Methoden, die der Benutzer erst während der Methodenbankverwendung entwickelt) kommt daher eine große Bedeutung für die Beurteilung der Leistungsfähigkeit eines Methodenbanksystems zu. Charakteristik von Methodenbanksystemen Charakteristische Merkmale von Methodenbanksystemen sind: • Sie sind Sammlungen von softwaretechnisch realisierten Methoden, also von Programmen ("Programmbausteine"). • Die Programmbausteine sind nach einheitlichen Konventionen erstellt und dokumentiert. • Ein Informationsteil erlaubt dem Benutzer einen leichten Zugang zu den Programmbausteinen. Konventionen für die Erstellung der Programmbausteine sind: • Die Programmbausteine haben eine einheitliche Schnittstelle; die Eingangs-, Ausgangs- und Hilfsgrößen werden über eine Parameterliste übergeben. • Der Aufruf der Programmbausteine erfolgt über ihren Namen; ein anderer Eingang ist nicht erlaubt. • Die Programmbausteine sind unabhängig von bestimmten BetriebssystemVersionen; außer der Methodenklasse "Ein- und Ausgaben" enthalten sie daher keine Ein- und Ausgabeoperationen. Methodenbanksysteme gliedern sich im allgemeinen in einen Ablaufteil und einen Informationsteil. Der Ablaufteil enthält die für den Programmablauf notwendigen Programmbausteine. Der Informationsteil führt den Benutzer von einer Übersicht über alle Methodenklassen (z.B. hierarchisch gegliedert) bis zur Dokumentation jeder Methode (z.B. Dokumentation der Theorie, der Schnittstellen und eines Anwendungsbeispiels). Durch die Implementierung der Programmbausteine als Unterprogramme ("Subroutinen") sind diese nur ablauffähig, wenn sie irt ein Hauptprogramm eingebun-

300

Methoden und Techniken der Feinprojektierung

den werden. Je nach Methodenbanksystem werden für die Implementierung von Hauptprogrammen verschiedene Sprachumgebungen (z.B. Fortran, COBOL, Pascal) angeboten; zusätzlich können spezielle Modellformulierungssprachen zur Verfügung stehen (z.B. MEMO bei MEB). Bewertungskriterien für Methodenbanksysteme Für den Vergleich von Methodenbanksystemen können die Bewertungskriterien Methodensammlung, Methodendokumentation, Auswahlhilfen, Auswahlverbote, methodenbezogener Datenschutz, Parameterversorgung, Interpretationshilfen und Benutzerprofil verwendet werden. Methodensammlung: Mit diesem Kriterium werden der Umfang, die Erweiterbarkeit, die Kombinierbarkeit, die Zuverlässigkeit und die Wirtschaftlichkeit der Methodenbasis beschrieben. Der Umfang beschreibt die Art und die Anzahl der verfügbaren Methoden. Die Erweiterbarkeit meint a) das Einfügen einer weiteren, bereits ausgetesteten Methode und b) das Einfügen einer Methode, die erst während der Methodenbankbenutzung entwickelt wurde. Im Unterschied zu a) soll das Einfügen nach b) während einer Dialogsitzung durchgeführt werden können. Mit Kombinierbarkeit ist das nahtlose Zusammenfügen von Methoden zu Modellen gemeint. Die Zuverlässigkeit beschreibt das Einhalten eines vorgegebenen Maßes an Fehlerfreiheit. Die Wirtschaftlichkeit mißt den Betriebsmittelbedarf, der durch gute Programmierung und/oder durch Hinweise zur Methodenauswahl, wenn Varianten verfügbar sind, möglichst gering sein soll. Methodenbank //////////////////////////////// //////////•//////////////•////// / / J ' \ Informationsteil ; ; Ablaufteil j 'sS////S//S///SS/^//SSSS//////sA

'////S/////SS/S//SS/S/SSSSSSS/SSS

Gesamtübersicht über den Inhalt der Methodenklassen

Klasseilübersic it

1 Prograrnmdokume ntationer, U P ,

Allgemeine Beschreibung

n

2

1

1

UP2

technische Beschreibung

up„

Anwendungsbeispiel

Abb. SMEBA-1: Gliederungssystematik der Methodendokumentation bei METHAPLAN (Quelle: Siemens-Nixdorf Informationssysteme)

SMEBA - Methodenbanksysteme

301

Methodendokumentation: Dafür sind nach verschiedenen Gesichtspunkten (z.B. alphabetisch) geordnete Verzeichnisse oder Erschließungssysteme denkbar, bei denen die gewünschte Methode über eine Recherche mit Deskriptoren gefunden wird. Abbildung SMEBA-1 zeigt die hierarchische Gliederungssystematik der Dokumentation in drei Detaillierungsstufen (Gesamtübersicht, Klassenübersicht und Programmdokumentation), die in METHAPLAN verwendet wird. Auswahlhilfen: Dabei werden folgende Formen unterschieden: Führung des Benutzers im Dialog, automatische Auswahl und Auswahl im Dialog. Die Führung des Benutzers im Dialog setzt voraus, daß die Methoden in einer Baumstruktur verbunden sind. Während des Dialogs werden dem Benutzer an den Knoten Menüs angeboten, die ihm ein Durchlaufen des Baums von der Gesamtübersicht bis zum auszuführenden Programm erlauben. Die automatische Auswahl verlangt von der Methodenbank, dem Benutzer geeignete Methoden zur Lösung seines Problems anzubieten. Die Vorauswahl oder Auswahl kann auf Grundlage folgender Merkmale erfolgen: Art der Aufgabe, Qualität der Daten, gewünschter Aufwand. Bei der Auswahl im Dialog werden die für die Auswahl geeigneten Merkmale schrittweise im Dialog abgefragt, um so sukzessiv zu einer geeigneten Methode vorzudringen. Auswahlverbote (oder zumindest Benutzerwarnungen): Diese sollen verfügbar sein, wenn Anforderungen der Methode an die Daten nicht eingehalten sind. Kostenschätzungen für den voraussichtlichen Betriebsmittelbedarf bei Benutzung einer Methode können ebenfalls die Methodenverwendung steuern. Parametrisierender oo ja Benutzer £ .c o «3 00 ModelliePh G •c render u 00 Benutzer gering

Fachmann

X hoch

Methodenwissen

Abb. SMEBA-2: Benutzertypen bei Methodenbanksystemen

Mit dem methodenbezogenen Datenschutz soll der unberechtigte Zugriff auf Daten durch geschickte Methodenanwendung verhindert werden. Mit Parameterversorgung sind Unterprogramme gemeint, die zur Auslegung von Parametern, zur Versorgung von Programmbausteinen mit Daten und zur Übergabe von Daten aus Programmbausteinen (auch zwischen verschiedenen Modelläufen) verwendet werden. Bei den Interpretationshilfen wird zwischen statischen ("Lehrbuchwissen") und dynamischen Interpretationshilfen unterschieden; letztere orientieren sich an der aktuellen Datensituation. Bei der Bewertung von Methodenbanksystemen ist auch zu beachten, auf welchen Benutzertyp sie zugeschnitten sind. Folgende Benutzertypen sind zu unterscheiden (vgl. Abbildung SMEBA-2):

302

Methoden und Techniken der Feinprojektierung

• Der Fachmann, der weiß, welche Methode er zur Lösung seiner Aufgabe bei gegebenen Daten braucht. Er kennt die Methoden- und die Datenbank, beherrscht die Kommandosprache und kann Methodenerweiterungen programmieren und diese einfügen. • Der Benutzer, der bestimmte Methoden und die Kommandosprache kennt; er kann Methoden zu Modellen zusammenführen ("modellierender Benutzer"). • Der "typische Methodenbankbenutzer", auf den Methodenbanken in erster Linie zugeschnitten sein sollen. Sein Fachwissen in seinem Aufgabengebiet ist groß, sein Methodenwissen ist nur klein, "EDV-Wissen" hat er fast nicht ("parametrisierender Benutzer"). Ebenen eines Methodenbanksystems Die Architektur eines Methodenbanksystems besteht aus Grundebene, Anpassungsebene und Benutzerebene. Die Grundebene ist vom Benutzer weitgehend unabhängig und nur dem Methodenadministrator zugänglich. Sie enthält das Methodenverwaltungssystem mit Ablaufsteuerung, Auskunftssystem und Schutzsystem. Funktionen des Methodenverwaltungssystems sind: • • • • • • • • • • • •

Erstmaliges Einrichten der Methodenbasis mit Methoden; Hinzufügen, Ändern und Löschen von Methoden; Erkennen von "Methodenleichen"; Sichern von Methodenkonsistenz; Beschreiben von Schnittstellen (z.B. zu Datenbanken); Bereitstellen von Hilfen für das Einbringen neuer Methoden; Analysieren der Benutzeranweisungen und Laden der angeforderten Programmbausteine; Versorgen der Methoden mit Daten, die entweder vom Benutzer aktualisiert oder aus Ergebnisdaten der Methodenanwendung generiert werden; Beschaffen, Aufbereiten und Speichern externer Daten (z.B. aus einer Datenbank); Abwickeln des Dialogs zwischen Benutzer und Methodenbank; Erklären der Bedienungskommandos; Unterstützen des methodenbezogenen Datenschutzes und der Auswahlverbote.

Auf der Anpassungsebene wird das Grundsystem (Grundebene) für die Bearbeitung von bestimmten Aufgabenklassen aufbereitet; dies erfordert im einzelnen folgendes: • Festlegen des aufgabenspezifischen Methoden Vorrats; • Schaffen einheitlicher Schnittstellen oder eines Aufrufrahmens, um verschiedene Methoden verknüpfen zu können; • Koppeln von Methoden und Daten durch einen Mechanismus, der die Konvertierung von Daten von der in der Datenverwaltung vorgesehenen in die für die Methodenbank erforderliche Form durchführt; • Dokumentation verknüpfter Methoden hinsichtlich Funktion, Anwendbarkeit und Schnittstellen. Die Benutzerebene ist auf den Methodenbankbenutzer ausgerichtet und mit einer der Fachterminologie angepaßten Benutzersprache versehen. Der "parametrisierende Benutzer" nutzt die vorhandenen Funktionen (Methoden oder Mo-

SMEBA - Methodenbanksysteme

303

delle), versieht sie mit aktuellen Daten und läßt sie ausführen. Der "modellierende Benutzer" schafft (auch) neue Methoden und Modelle. Verwendung anderer Programme als Methodenbank Das Konzept des Methodenbanksystems kann auf Programme übertragen werden, die nicht methodenbankspezifisch erstellt wurden. Dies gilt vor allem für Programme, die Standardprodukte sind, häufig verwendet werden und deren Benutzbarkeit gering ist, beispielsweise die sog. Statistik-Pakete (z.B. SPSS und SPSS/PC+). Die Produkte sind kommando-orientiert, das heißt ihre Benutzung erfolgt durch Eingabe von Kommandos, die einer genau vorgeschriebenen Syntax folgen. Im übrigen genügen sie aber im wesentlichen den für Methodenbanksysteme typischen Bewertungskriterien. Die Übertragung des Konzepts erfolgt in der Weise, daß zwischen Benutzer und Methodenbank eine Schnittstelle geschaffen wird, in welcher der Benutzer die durchzuführenden Auswertungen definiert. Die dabei gebotene Benutzerunterstützung kann von einem einfachen HilfeSystem bis zur automatischen Modellauswahl reichen. Die Modellauswahl erfolgt auf Grund des Untersuchungsziels sowie - bei wissensbasierter Realisierung - des automatisch ermittelten Skalenniveaus der auszuweitenden Variablen. Demonstrationsbeispiel Es wird die Architektur der Methodenbank MEB gezeigt. Dabei interessieren vor allem folgende Fragen: • • • • •

Welche Programmbausteine enthält MEB und wie sind sie geordnet? Wie sind die MEB-Programmbausteine beschrieben? Wie werden die MEB-Programmbausteine verknüpft? Wie werden MEB-Programmbausteine aufgerufen? Wie wird bei den MEB-Programmbausteinen die Fehlerbehandlung durchgeführt?

Für die Benutzung von MEB gibt es folgende Alternativen: • Benutzung unter einem anwenderindividuellen Hauptprogramm; • Benutzung unter dem Methodenmonitor MEMO. Nachfolgend wird zunächst von der ersten Alternative ausgegangen. Anschließend wird die Benutzung von MEB unter MEMO erläutert. Gliederung von MEB: Die 420 Programmbausteine von MEB sind in dreizehn Methodenklassen gegliedert; die Bezeichnung der Methodenklassen und die Anzahl der Programmbausteine in jeder Methodenklasse geben einen Überblick über den Inhalt von MEB (vgl. Abbildung SMEBA-3). Beispielsweise enthält die Methodenklasse "Matrizenrechnung" 48 Programmbausteine, und zwar für Matrizeninversion und Determinantenberechnung, für elementare Matrizenoperationen (z.B. elementweise Multiplikation und Division zweier Matrizen), für die Bildung von Zeilen- und Spaltensummen und die Normalisierung sowie für die Änderung und den Aufbau von Matrizen (z.B. Transponieren).

304

Methoden und Techniken der Feinprojektierung

Methodenklasse 0 1 2 3 4 5 6 7 8 9 A B C

Anzahl Programmbausteine Ein-/Ausgabeoperationen und Hilfsroutinen 46 Matritzenrechnung 48 12 Differentialrechnung Integralrechnung 13 24 Gleichungen und Polynome Regression, Approximation und Interpolation 43 110 Statistik Optimierung 17 Simulation 13 32 Berichts- und Planungswesen 14 Spezielle Funktionen Zeitreihenanalyse und Prognose 28 20 Finanz- und Versicherungsmathematik Bezeichnung

Abb. SMEBA-3: Methodenklassen des Methodenbanksystems MEB (Quelle: Siemens-Nixdorf Informationssysteme)

Beschreibung der MEB-Programmbausteine: Jeder Programmbaustein ist nach einer einheitlichen Struktur beschrieben, wie Abbildung SMEBA-4 zeigt. Strukturmerkmal Zweck Theorie Methode Gerufene Programme Rufende Programme Aufruf Parameter Bemerkung Beispiel

Erläuterung Kurzinformation über die Funktion Beschreibung des theoretischen Hintergrunds der Methode sowie Literaturhinweise Hinweise auf die dv-technische Realisierung der Methode MEB-Programmbausteine oder anwenderindividuelle Programmbausteine, die von der Methode aufgerufen werden MEB-Programmbausteine, welche die Methode aufrufen Form des Aufrufs, der in einem rufenden FORTRANProgramm erforderlich ist Beschreibung der Parameter mit Name, Datentyp, Angabe, ob Eingabe- oder Ausgabeparameter, Dimension und Bedeutung Angaben über Anwendungen, für welche die Methode geeignet ist, sowie über den Entwicklungsstand der Methode in Form der gültigen Versionsnummer Beispiel in Form eines rufenden FORTRAN-Programms

Abb. SMEBA-4: Struktur und Beschreibung der MEB-Programmbausteine (Quelle: Siemens-Nixdorf Informationssysteme)

Verknüpfung der MEB-Programmbausteine: Auch wenn eine Aufgabe mit dem Aufruf eines Programmbausteins (einer Methode) bearbeitet werden kann, müssen dem Programmbaustein Eingabeoperationen vorgelagert und Ausgabeoperationen nachgelagert werden, die sich mit MEB-Programmbausteinen der Klasse 0 realisieren lassen. Wenn die mit einem MEB-Programmbaustein zur Verfügung gestellte Methode zur Aufgabenlösung nicht ausreicht, müssen mehrere MEB-Programmbausteine miteinander verknüpft werden. Zur leichten Ver-

SMEBA - Methodenbanksysteme

305

knüpfung sind die Eingabe- und Ausgabeparameter der MEB-Programmbausteine aufeinander abgestimmt. Aufruf der MEB-Programmbausteine: Der Anwender benutzt MEB-Programmbausteine, indem er sie in anwenderindividuellen Hauptprogrammen aufruft. Diese können in FORTRAN, COBOL, PASCAL, PL/1, ALGOL oder Assembler implementiert sein. Die Versorgung der MEB-Programmbausteine mit Daten und die Übergabe der Ergebnisse aus den MEB-Programmbausteinen an das anwenderindividuelle Hauptprogramm erfolgt über eine Liste der Übergabeparameter. Die MEB-Programmbausteine haben keine eigene Ein-/Ausgabe von externen Dateien bzw. auf externe Dateien. Fehlerbehandlung bei MEB-Programmbausteinen: Viele Methoden können für bestimmte Werte der übergebenen Eingabeparameter keine sinnvollen Ausgabeparameter liefern (z.B. kann eine singuläre Matrix nicht invertiert werden). Deshalb signalisiert gegebenenfalls ein Fehlerparameter, ob die Methode mit den übergebenen Werten ordnungsgemäß arbeiten kann oder nicht. Dadurch sind die Methoden weitgehend gegen Anwendungsfehler geschützt. MEMO ist ein offenes Ablauf- und Datenverwaltungssystem für die Benutzung der MEB-Programmbausteine (sowie der Programmbausteine BETINA zum Berechnen von Netzen); MEMO kann auch für anwenderindividuelle Programme verwendet werden. Programmiert wird in MEMO mit einer leicht erlernbaren Modellformulierungssprache, ohne Übersetzen, Binden und Generieren. Die wichtigsten Kommandos der Modellformulierungssprache sind die Namen von Programmbausteinen ("Methodensprache") und beliebige arithmetische Ausdrücke ("Formelsprache"). Die Kommandos können in einem Auftrag an das Methodenbanksystem gegeben oder im Methodenbanksystem als Prozeduren zusammengefaßt werden. Für den Ablauf von MEMO sind folgende Komponenten erforderlich: Ablaufsteuerung, Arbeitsdatei und Bibliothek mit Programmbausteinen ("Programmbibliothek"). MEMO besitzt eine Schnittstelle, über welche die MEB-Programmbausteine verknüpft werden. Anwenderindividuelle Programme werden über eine Verwaltungsroutine angeschlossen. Dadurch können Daten zwischen MEMO und den Programmbausteinen sowie zwischen Programmbausteinen untereinander in Form von Parameterlisten ausgetauscht werden. Anwenderindividuelle Programmbausteine können in FORTRAN, COBOL und Assembler implementiert sein. Anwender von INFPLAN (vgl. Lerneinheit SPLAN) können mit dem Kommando METHAPLAN einen Anschluß an MEMO und damit die Möglichkeit erhalten, Programmbausteine von MEB aufzurufen. Forschungsbefunde Mertens/Bodendorf erörtern, welche Eigenschaften bei Methodenbanken wünschenswert sind und zeigen an Beispielen von realisierten Pilot- und Praxissystemen, inwieweit diese berücksichtigt sind. Sie weisen unter anderem nach: Methodensammlungen sind oft zu inhaltsarm; einfache Erweiterbarkeit ist häufig gegeben; ein zufriedenstellendes Maß an Fehlerfreiheit ist nicht immer gegeben; die Wirtschaftlichkeit ist häufig nicht befriedigend; Kostenschätzungsverfahren fehlen meist.

306

Methoden und Techniken der Feinprojektierung

Aufgabenverweise Entwickeln des Methodensystems (Lerneinheit EMESY). Kontrollfragen 1. 2. 3. 4. 5.

Welches sind die charakteristischen Merkmale von Methodenbanksystemen? Welche Kriterien werden zur Bewertung von Methodenbanksystemen verwendet? Was unterscheidet den "parametrisierenden" vom "modellierenden" Benutzer? Welche drei Ebenen kennzeichnen die Architektur eines Methodenbanksystems? Welche Gliederungssystematik der Methodendokumentation verwendet METHAPLAN?

Quellenliteratur Benz, J.: PC-Standard-Statistik-Programmpakete als Methodenbankbasis in Systemen für Management und Marketing. In: Information Management 3/1991, 28 - 34 Esprester, A. C.: Die Entwicklung einer Methodenbank und einer Methodenbanksprache. In: Angewandte Informatik 7/1978, 203 - 206 Mertens, P. und Bodendorf, F.: Interaktiv nutzbare Methodenbanken - Entwurfskriterien und Stand der Verwirklichung. In: Angewandte Informatik 12/1979, 533 - 541 Mertens, P. und Griese, J.: Integrierte Informationsverarbeitung 2 - Planungs- und Kontrollsysteme. 7. A„ Gabler Verlag, Wiesbaden 1993, 24 - 30 Siemens-Nixdorf Informationssysteme (Hrsg.1): MEB (BS2000) Methodenbank - Anwendungsbeschreibung. Ausgabe März 1986, München 1986 Siemens-Nixdorf Informationssysteme (Hrsg.): MEMO (BS2000) Modellsprache - Beschreibung. Ausgabe 1/1985, München 1985 Vertiefungsliteratur Barth, H.: Grundlegende Konzepte von Methoden- und Modellbanksystemen. In: Angewandte Informatik 8/1980, 301 - 309 Dittrich, K. R. et al.: Das KARAMBA-Methodenbanksystem. In: Böhling, K. H. und Spies, P. P. (Hrsg.): 9. Jahrestagung der GL Springer Verlag, Berlin et al. 1979, 322 - 336 Klösgen, W. und Schwarz, W.: Die Realisierung von Architekturprinzipien für Methodenbanksysteme im Modellbanksystem MBS. In: Böhling, K. H. und Spies, P. P. (Hrsg.): 9. Jahrestagung der Gl, Informatik-Fachberichte Bd. 19, Springer Verlag, Berlin et al. 1979, 274 - 284 Minnemann, J.: MAMBO - Erfahrungen bei der Entwicklung eines Methodenbanksystems. In: HMD - Handbuch der Modernen Datenverarbeitung 126/1985. Forkel Verlag, Stuttgart/Wiesbaden 1985, 95 -105 Rickert, R.: Konzeption von Methodenbanken zur Entscheidungsunterstützung. In: Krallmann, H. (Hrsg.): Unternehmensplanung und - Steuerung in den 80er Jahren. Springer Verlag, Berlin et al. 1982, 164 - 179 Schips, B.: Ein Beitrag zum Thema "Methodenbanken". In: Angewandte Informatik 11/1977,465 -470

SPLAN - Planungssprachen Lernziele Sie kennen die charakteristischen Merkmale von Planungssprachen und Kriterien, mit denen eine vergleichende Beurteilung durchgeführt werden kann. Sie kennen die grundsätzliche Vorgehensweise bei der Modellierung und Modellanalyse mit Planungssprachen. Sie können die Struktur einer Planungssprache und den Arbeitsablauf bei ihrer Verwendung beschreiben. Sie kennen die Verwendung von Planungssprachen in Entscheidungsunterstützungssystemen. Definitionen und Abkürzungen Anweisung (statement) = eine in einer beliebigen Programmiersprache abgefaßte Arbeitsvorschrift, die im gegebenen Zusammenhang, wie auch im Sinn der benutzten Programmiersprache, abgeschlossen ist. Arbeitsmatrix (working matrix) = eine Matrix, die vom Benutzer einer Planungssprache zur Bearbeitung einer bestimmten Aufgabe definiert wird. AS = Akronym für Application Software; eine von IBM angebotene Planungssprache (PC-Version: AS/2). DSS = Akronym für Decision Support System. Entscheidungsunterstützungssystem (decision support system) = ein Informationssystem mit dem Aufgabenschwerpunkt "Unterstützung schlecht strukturierter Aufgaben in Entscheidungsprozessen", abgekürzt: EUS. Führungsinformationssystem (executive information system) = eine synonyme Bezeichnung für Entscheidungsunterstützungssystem. Funktion (function) = eine Methode, die in einer Planungssprache mit einem Kommando aufgerufen und zum Ablauf gebracht werden kann. Identifizieren (identifying) = das eindeutige und unverwechselbare Bezeichnen, Erkennen oder Ansprechen eines Objekts. IFPS/Plus = Akronym für Interactive Financial Planning System/Plus; eine von Comeshare angebotene Planungssprache (PC-Version: IFPS/Personal). I N F P L A N = Akronym für Informations- und Planungssystem; eine von Siemens-Nixdorf Informationssysteme angebotene Planungssprache zur Anwendung in allen Funktionalbereichen und zur Unternehmens-Gesamtplanung. Matrix (matrix) = ein meist zweidimensionales, in Zeilen und Spalten gegliedertes Schema; die m Zeilen und n Spalten bestimmen die Dimension (auch: den Typ oder die Größe) der Matrix. Modell (model) = im Sinn der Planungssprachen mehrere Methoden, die gemeinsam zur Bearbeitung einer Planungsaufgabe verwendet werden. Modellieren (modelling) = die Tätigkeit des Abbildens eines Ausschnitts der Wirklichkeit in ein Modell. Planung (planning) = jedes vorausschauende, in die Zukunft gerichtete Handeln. Prozedur (procedure) = ein Programmbaustein, der aus einer vollständigen Anweisung besteht, die zur Lösung einer Aufgäbe erforderlich ist. Tabelle (table) = die übersichtliche Darstellung von Daten in Form von numerischen oder alphanumerischen Zeichen in einem Schema aus Zeilen und Spalten.

308

Methoden und Techniken der Feinprojektierung

Zweck der Planungssprachen Planungssprachen sind Programmiersysteme für den Teil des Methodensystems, mit dem Planungsaufgaben in betrieblichen Funktionalbereichen (z.B. Kostenund Budgetplanung, Finanz- und Investitionsplanung, Absatz- und Marketingplanung) und in der Unternehmens-Gesamtplanung unterstützt werden. Ihre besondere Ausrichtung auf diese Art von Aufgaben läßt sich unter anderem daran erkennen, daß die Dateneingabe meist tabellenorientiert erfolgt und die Verwendung von Matrizen bei Planungsaufgaben weit verbreitet ist. Durch die Orientierung auf Planungs- und Berichtsprozesse sind die Gestaltungsmöglichkeiten, die Planungssprachen bieten, im Vergleich zu höheren Programmiersprachen (vgl. Lerneinheiten SPROM und SOBOP) gering. Planungssprachen eignen sich primär für die Bearbeitung weniger, stark verdichteter Daten (was für Planungsaufgaben typisch ist), nicht jedoch für die Verarbeitung großer Datenmengen ("Massendaten"). Mit Abfragesprachen (vgl. Lerneinheit SVIER) kann der Benutzer Daten aus einer Datenbasis selektieren; sie bieten ihm aber nur wenig Möglichkeiten der Datenmanipulation. Methodenbanken (vgl. Lerneinheit SMEBA) kennen nicht die Einschränkung auf Planungsaufgaben; sie sind zwar den Planungssprachen ähnlich, ihr Anwendungsspektrum ist aber breiter. Planungssprachen bieten auch eine flexible, benutzernahe Sprachumgebung zur Entwicklung und Benutzung von Entscheidungsunterstützungssystemen (z.B. für Planungsaufgaben). Mit dem Einsatz von Planungssprachen werden folgende Ziele verfolgt: • schnelle und flexible Erstellung und Auswertung von Modellen; • geringe Kosten für die Modellerstellung und -pflege im Vergleich zu höheren Programmiersprachen; • leichte Kommunizierbarkeit der Ergebnisse zwischen Planer und Management. Die Erreichung dieser Ziele wird insbesondere durch die Eigenschaft von Planungssprachen unterstützt, die Erstellung und Auswertung von Modellen in einer Umgebung zu ermöglichen, die der natürlichen Sprache (meist Englisch) angeglichen und in ihren Darstellungsformen für Planungsaufgaben typisch ist. Charakteristik von Planungssprachen Charakteristische Merkmale von Planungssprachen sind: • • • • •

Verwendung von Matrizen; flexible Modellerstellung; eingebauter Funktionsvorrat; umfangreiche Möglichkeiten der Dateneingabe und Datenausgabe; einfache Benutzbarkeit.

Verwendung von Matrizen: Matrizen in Planungssprachen sind häufig dreidimensional (Spalten, Zeilen und Blätter); jeder Dimension ("Beschreibungsvektor") wird ein Name ("Beschreibungsvektor-Name") zugeordnet. In Abbildung SPLAN-1 hat der Beschreibungsvektor für die Spalten den Namen S-SPORT, der Beschreibungsvektor für die Zeilen den Namen Z-SPORT und der Be-

SPLAN - Planungssprachen

309

schreibungsvektor für die Blätter den Namen B-SPORT. Jeder Beschreibungsvektor gliedert sich in Indizes ("Beschreibungsvektor-Indizes"); mit den Indizes wird die Anzahl der Spalten, Zeilen und Blätter, also die Größe der Matrix, festgelegt. Als Namen für die Indizes können fachsprachliche Ausdrücke (z.B. die Bezeichnung von Kostenstellen, Artikeln und Regionen) oder Identnummern verwendet werden; die Identnummer entspricht der Stelle, an der der Index in der Dimension steht. Beispielsweise sind in der Matrix in Abbildung SPLAN-1 beim Spalten-Beschreibungsvektor der PREIS, die MENGE und die KOSTEN die fachsprachlichen Namen der Indizes. Über die Namen der Indizes kann jede Zelle der Matrix (jeder Werteplatz) identifiziert werden. Jeder Beschreibungsvektor und jede Matrix werden in eigenen Dateien abgelegt. Ein Beschreibungsvektor kann daher mehreren Matrizen zugeordnet werden. Die maximale Größe der Matrix ist von der verfügbaren Hauptspeicherkapazität und daher nicht von der Planungssprache, sondern vom verwendeten Betriebsmittel abhängig.

PREIS

MENGE KOSTEN

S-SPORT Abb. SPLAN-1: Dreidimensionale Matrix in Planungssprachen (Beispiel "M-SPORT") (Quelle: Siemens-Nixdorf Informationssysteme)

Flexible Modellerstellung: Die in Planungssprachen verwendeten Befehle sind der Planungsterminologie angepaßt. Sie bieten Prozeduren für die Formulierung, Änderung und Ablaufsteuerung von Modellen. Modelle können entweder vom Planungsfachmann erstellt werden, oder es wird auf vorhandene Modelle zurückgegriffen, die gegebenenfalls an die spezifischen Anforderungen angepaßt werden. Eingebauter Funktionsvorrat: Planungssprachen enthalten fertige Programme zur Unterstützung von Planungsaufgaben. Dazu zählen mathematische Funktionen (z.B. Grundrechenarten, Kumulierung, Minimal- und Maximalwertsuche, Rundungsoperationen), finanzmathematische Funktionen und Methoden der Inve-

310

Methoden und Techniken der Feinprojektierung

stitionsrechnung (z.B. Zins- und Tilgungsrechnung, interner Zinssatz, Kapitalwert, Amortisationsdauer) und statistische Methoden (z.B. Mittelwert, Varianz, Regressionsanalyse, Zeitreihenanalyse, Trendrechnung). Zur Unterstützung der Analyse und Auswertung der Ergebnisse von Planungsrechnungen sind in Planungssprachen statistische Methoden verfügbar, die ohne großen Programmieraufwand eingesetzt werden können. Möglichkeiten der Dateneingabe und Datenausgabe: Daten können nicht nur vom Benutzer in das Planungssystem eingegeben, sondern auch über Schnittstellen aus Dateien und Datenbanken übernommen werden. Die Möglichkeiten der Datenausgabe reichen von der Benutzung vorhandener Standardberichte bis zur Definition individueller Berichte, sowohl in Textform als auch in grafischer Form, von einfachen Kurvendiagrammen bis zu dreidimensionalen Grafiken. Einfache Benutzbarkeit: Die - im Vergleich mit höheren Programmiersprachen - einfache Benutzbarkeit von Planungssprachen wird vor allem durch die K o m m a n d o s p r a c h e ermöglicht; jede verfügbare Funktion wird durch ein Kommando aufgerufen ("Kommandoebene"). Mit Hilfe von Anweisungen kann jedes Kommando spezifiziert werden; es kann also definiert werden, wie die Funktion ausgeführt werden soll ("Anweisungsebene"). Aus Kommandos und Anweisungen bestehende Prozeduren können hinterlegt und mit einem Kommando wiederholt aufgerufen werden. Durch unterschiedliche Arbeitsmodi (z.B. Experten-Modus und Fachanwender-Modus) wird die Benutzbarkeit erleichtert. Im Fachanwender-Modus sind insbesondere geringere Kenntnisse über die Syntax der Kommandosprache erforderlich als im Experten-Modus. Bewertungskriterien für Planungssprachen Für die Bewertung von Planungssprachen können das Anwendungsgebiet, die Hardware- und Software-Technik, der Leistungsumfang, die Benutzbarkeit, die Kosten und sonstige Kriterien verwendet werden. Das Anwendungsgebiet beschreibt den Teil der betrieblichen Planungsaufgaben, auf den die Planungssprache auf Grund ihres Funktionsvorrats zugeschnitten ist (z.B. Kostenplanung und -kontrolle, Produktionsplanung, Marketingplanung). Die Hardware- und Software-Technik beschreibt: • die erforderliche Hardware und das erforderliche Betriebssystem (für viele Planungssprachen sind sowohl eine Mainframe- als auch eine PC-Version verfügbar, letztere hat im allgemeinen einen geringeren Leistungsumfang); • den Verarbeitungsmodus (Stapel- oder Dialogverarbeitung); • die Art der Übersetzung (compilierend oder interpretierend); • die verwendete Quellensprache; • die Schnittstellen zu anderen Programmiersprachen, zu Dateien bzw. zu Datenbanken; • die Größe der Arbeitsmatrix (maximale Anzahl der Zeilen, Spalten und gegebenenfalls Blätter).

SPLAN - Planungssprachen

311

Der Leistungsumfang beschreibt: • die Modellerstellung (Modellformulierungssprache, ihre programmiertechnischen Merkmale, vorhandene Hilfsfunktionen zur Modellerstellung wie Editierfunktionen, Syntaxprüfung, Testhilfen, Status-Auskunft); • die Dateneingabe (Eingabemedien; Art der Eingabe, wie Eingabe von Einzelwerten, zeilen- oder spaltenweise Eingabe; Hilfsfunktionen der Dateneingabe, wie formatfreie Eingabe und Generierung von Eingabedaten); • den Funktionsvorrat, also die Art und Anzahl der verfügbaren Methoden (einfache mathematische Funktionen, wie Grundrechenarten oder Wurzelziehen; komplexe mathematische Funktionen, wie exponentielle Funktionen oder Matrixfunktionen; finanzmathematische und Investitionsrechnungsmethoden, wie Kapitalwert oder interner Zinsfuß; statistische Methoden, wie Mittelwerte oder Korrelation; Prognosefunktionen, wie exponentielle Glättung oder gleitende Durchschnitte; Sensitivitätsanalyse; Risikoanalyse; OR-Methoden, wie Lineare Programmierung oder Netzplantechnik); • die Ablaufsteuerung (automatische Ablaufsteuerung durch das Betriebssystem, Ablaufsteuerung durch den Benutzer oder Ablaufsteuerung durch eine Kommandodatei); • die Datenausgabe (Ausgabemedien; Grafik; Standardberichte und individuelle Berichte, insbesondere die Möglichkeiten der Druckaufbereitung); • die Möglichkeit der Abspeicherung von Modellen, Dateien und Berichten unter einem Namen zur späteren Wiederverwendung. Die Benutzbarkeit beschreibt: • den Lernaufwand, d.h. die Zeit, die erforderlich ist, sich mit einer Planungssprache so vertraut zu machen, daß einfache Aufgaben ohne fremde Hilfe bearbeitet werden können; • die Lernhilfen, insbesondere durch verfügbare Schulungskurse, Trainingsmanuals und Built-in-Trainings; • die Verarbeitungshilfen (Hilfe-Funktion, Schlüsselwortkatalog, vorbesetzte Werte, Laien- und Expertenmodus). Die Kosten beschreiben: • die Beschaffungskosten; • die Wartungskosten. Sonstige Kriterien sind: • die Anzahl der Installationen; • der Zeitpunkt der Erstinstallation der gültigen Version; • die Erweiterbarkeit durch den Benutzer (z.B. mit Funktionen oder Fehlerprüfungen) und durch den Anbieter (z.B. weitere Funktionen, Grafikfahigkeit und Datenbankschnittstellen). Modellbildung und Modellanalyse Mit Planungssprachen lassen sich beliebige lineare und nicht-lineare Abhängigkeiten modellieren, sofern sie sich mit der Syntax der Modellierungssprache

312

Methoden und Techniken der Feinprojektierung

beschreiben lassen. Präferenzfunktionen von Entscheidern werden in den Modellen nicht explizit ausgedrückt; das Erreichen von Zielen ist entweder durch Messung der Zielerreichung oder von Proxy-Attributen festzustellen. Die Werte der exogenen Variablen ("Umweltvariablen") sind durch externe Daten oder durch festgelegte Aktionen vorgegeben. Im Unterschied zu Optimierungsmodellen (vgl. Lerneinheit OPMOD), kann bei Planungssprachen die Entstehung von Modellgrößen aus den originären Daten (wie sie z.B. in einer Datenbank gespeichert sind) bis hin zur Entstehung der Zielgrößen abgebildet und verfolgt werden. Die Modellbildung erfolgt mit Hilfe der Modellierungssprache, die - je nach Planungssprache - unterschiedlich ist. Die Modellogik wird zeilenweise durch Anlage von zwei- oder mehrdimensionalen Tabellen entwickelt. Die erste Dimension ist in der Regel die Zeit: Pro Periode (Jahr, Quartal, Monat) wird eine Spalte definiert. Die zweite bis n-te Dimension dienen der Definition von Variablen, Definitions- und Verhaltensgleichungen und ggf. von Anweisungen zur Eingabe, Ausgabe und Systemsteuerung. In einer zweidimensionalen Tabelle entspricht so eine Zeile dem Verlauf einer Variablen über der Zeit. Neben diesen Berechnungen in regulären Spalten können spezielle Spalten für Auswertungen der Periodengrößen (Kumulation, Abweichung usw.) definiert werden. Die Modelldaten werden im allgemeinen im Datei-Subsystem abgelegt, können aber auch in die Modellogik integriert sein. Bei der Modellanalyse werden eine Modellogik und eine Datei oder mehrere Dateien verknüpft. Die gewünschten Berechnungen werden über Kommandos initiiert. Sie liefern als Ergebnis eine Datei, deren Inhalt dem einer Tabelle von der Dimension der Modellogik entspricht. Die Trennung von Modellogik und Datei hat den Vorteil, daß ein Modell für mehrere unterschiedliche Dateien bzw. die Ergebnis-Datei eines Modells als Eingabe-Datei für andere Modelle verwendet werden kann. Das Berichtssystem erlaubt es, Daten auszuwählen und in einen Bericht oder in eine Grafik zu überführen. Form und Inhalt eines Berichts werden in einer Berichtsdatei festgelegt. Kommandos werden entweder interaktiv eingegeben, oder sie liegen auf einer Kommando-Datei vor ("Kommandoprozedur"). Eine Kommandoprozedur ist besonders dann zweckmäßig, wenn folgende Situation vorliegt: • Sich häufig wiederholende Sitzungen sollen schnell abgewickelt werden. • Das verwendete Modell ist komplex; es setzt sich aus mehreren einfachen Modellen zusammen. • Die Benutzer sind überwiegend ungeübt; sie sollen durch komplexe Analyseprozesse geführt werden. Weiterentwicklung von Planungssprachen Eine Weiterentwicklung von Planungssprachen sind Tabellenkalkulationssysteme. Die ersten Tabellenkalkulationssysteme stammen von D. Bricklin und R. Frankston. Anlaß für ihre Entwicklung war die Unzufriedenheit mit den in der Betriebswirtschaft üblichen Tabellen auf Papier. Der Arbeitsablauf mit einem Tabellenkalkulationssystem kann wie folgt beschrieben werden:

SPLAN - Planungssprachen

313

• Dem Benutzer wird das Fenster einer Matrix angeboten. • Der Benutzer kann jedes angebotene Matrixelement ("Zelle") formatieren und mit Werten besetzen. • Der Benutzer kann Regeln, nach denen die Inhalte mehrerer Zellen miteinander verknüpft werden, angeben. In weiter entwickelten Formen kann der Inhalt einer Zelle durch Suchen gefunden werden, wodurch sich Probleme, für deren Lösung es keinen Algorithmus gibt, durch einen Suchvorgang lösen lassen. Tabellenkalkulationssysteme sind heute auf den meisten PCs verfügbar; sie sind (insbes. wegen der besseren Benutzeroberfläche) vielfach für die individuelle Informationsverarbeitung geeigneter als Planungssprachen. Dennoch sind die Leistungsvorteile der Planungssprachen gegenüber Tabellenkalkulationssystemen unverkennbar, was sich an den folgenden Merkmalen und ihren unterschiedlichen Ausprägungen zeigt: • In Tabellenkalkulationssystemen werden Modelle (Logiken) und Daten zusammen, bei Planungssprachen werden sie getrennt verwaltet. • Tabellenkalkulationssysteme beschreiben Datenverknüpfungen zellenweise durch Formeln, Planungssprachen zeilen- und spaltenweise durch eine nichtprozedurale Modellierungssprache unter Einschluß von Makrodefinitionen (Funktionen, Unterprogramme usw.). • Die Datenstruktur von Tabellenkalkulationssystemen ist im allgemeinen zweidimensional, die von Planungssprachen ist mehrdimensional (meist dreidimensional). Dadurch können Daten leichter unter verschiedenen Gesichtspunkten dargestellt und manipuliert werden. • Planungssprachen verfügen über Schnittstellen zu Dateien und Datenbanken, Tabellenkalkulationssysteme im allgemeinen nicht (eine Ausnahme ist z.B. das Produkt MS Excel in Version 5.0). Daraus ergibt sich, daß Tabellenkalkulationssysteme für einfache, schnell zu bearbeitende Planungsaufgaben besser geeignet sind als Planungssprachen. Da viele Planungssprachen über Schnittstellen zu Tabellenkalkulationssystemen verfügen, können - je nach Aufgabe - die Vorteile beider Werkzeuge genutzt werden. Eine andere Weiterentwicklung der Planungssprachen führt zu Führungsinformationssystemen bzw. Entscheidungsunterstützungssystemen. Informationssysteme dieser Art lassen sich wie folgt kennzeichnen: • Schwerpunkt ist die multimediale Aufbereitung von Daten zur Erstellung von Berichten und Präsentationsgrafiken. • Ausnahmeberichte und Was/Wenn-Analysen werden gezielt unterstützt. • Die Architektur ist durch grafische Benutzeroberflächen, Datenaufbereitung auf Arbeitsplatzsystemen (meist MS-DOS-Rechner) und Datenhaltung auf Hintergrundrechnern gekennzeichnet. Demonstrationsbeispiel Es wird die Struktur und der Arbeitsablauf bei Benutzung der Planungssprache INFPLAN gezeigt. Der Funktions- und Leistungsumfang ist in mehrere Kom-

314

Methoden und Techniken der Feinprojektierung

ponenten gegliedert: Basis-Komponente, DV-Komponente, Methoden-Komponente, PLOT-Komponente und Datenanschluß-Komponente. • Die Basis-Komponente enthält: Funktionen zum Aufbau und zur Verwaltung von Matrizen sowie zum Einrichten und Pflegen von Arbeitsspeichern; Rechenfunktionen zur arithmetischen Verarbeitung (z.B. Logarithmen, Wurzelziehen); Funktionen zum Umstrukturieren von Matrizen wie Erweitern, Sortieren und Verdichten; Analysemethoden zum Aufbereiten von Daten (z.B. zum Ermitteln von Häufigkeiten und Abweichungen); Funktionen wie DRUCKE (zum Erstellen und Ausgeben von Listbildern), GRAFIK (zum Erstellen und Ausgeben von Balken- und Kurvendiagrammen), STARTE (zum Starten von Prozeduren) und COMPACT (zur Dialogverarbeitung von Matrizen). • Die DV-Komponente enthält die Ablaufsteuerung sowie Funktionen zum Aufbau und zur Bearbeitung von Bildschirmmasken. In Bildschirmmasken können konstante und variable Textfelder sowie Wertefelder definiert und Matrixelemente, Indizes, Variable und Texte aus Definitionsdateien verändert werden. • Die Methoden-Komponente enthält mathematisch-statistische Analysemethoden, Methoden zur Investitionsplanung und eine Schnittstelle zu METHAPLAN (vgl. Lerneinheit SMEBA). Beispiele für mathematischstatistische Methoden sind: Clusteranalyse, Korrelationsanalyse, Trendanalyse, Regressionsanalyse, Varianzanalyse, Faktorenanalyse und Diskriminanzanalyse. Mit Methoden der Investitionsrechnung bei gegebenen Ein- und Auszahlungsreihen können Abschreibungen, Kapitalwert, interner Zinssatz und Break-Even-Punkt ermittelt werden. • Mit den Funktionen der PLOT-Komponente werden die Werte einer Matrix in Form von mehrfarbigen Kurven-, Balken- oder Kreisdiagrammen auf einen Plotter oder Grafikbildschirm ausgegeben. Die Plot-Komponente enthält auch eine Schnittstelle zum Business-Grafik-System BUGRAF. • Die Datenanschluß-Komponente stellt Schnittstellen zu Dateien (SAM und ISAM) und zu Datenbanken (SESAM, UDS und CIS) zur Verfügung, die außerhalb von INFPLAN geführt werden. Damit können sowohl Daten aus INFPLAN in externe Dateien und Datenbanken ausgelesen als auch von diesen in INFPLAN eingelesen werden. Der typische Verlauf einer Arbeitssitzung mit INFPLAN sieht wie folgt aus: • Zunächst legt der Benutzer die Zeilen, Spalten und gegebenenfalls Blätter sowie die Größe seiner Arbeitsmatrix fest. Die Arbeitsmatrix wird dann mit Werten gefüllt, die entweder vom Benutzer eingegeben oder von einer Datei eingelesen werden. • Anschließend werden die Rechenanweisungen des Modells definiert. Der Benutzer kann den Ablauf mit Schleifen, mit bedingten Anweisungen und mit dem Einbau von Schaltern und Variablen flexibel gestalten. • Die den Benutzer interessierenden Modellergebnisse werden vom System nach der Durchrechnung am Bildschirm angezeigt. • Erscheinen die Resultate dem Benutzer zutreffend, kann er den Ausdruck ausgewählter Werte veranlassen.

SPLAN - Planungssprachen

315

• Mit der Funktionsmenge "Planung und Analysen" können Modellergebnisse weiter untersucht werden. In allen Phasen der Arbeitssitzung wird der Benutzer vom System unterstützt (z.B. mit der Ausgabe von Fehlermeldungen, Ergebnissen, Hinweisen oder Inhalten von Dateien). Durch den modularen Aufbau kann jede einzelne Phase einer Anwendung - unabhängig von anderen Teilen - angesteuert werden. Als Beispiel für die Benutzung von INFPLAN wird gezeigt, wie im "Fachanwender-Dialog" mit COMPACT Software für Abfragen aus Datenbeständen entwickelt wird. In einer Versicherung stehen Daten über Schadensfälle der Kategorien Haftpflicht-, Voll- und Teilkaskoversicherungen in verschiedenen Städten, die Regionen zugeordnet sind, zur Verfügung. Es besteht folgende Informationsnachfrage: • • • • •

Anzahl der Schadensfälle aller Versicherungsarten; Struktur der Schadensfälle nach einer ABC-Analyse; Verdichten der Schadensfälle nach Regionen; Visualisieren der Auswertungen mit einem Balkendiagramm; Anteile der Versicherungsarten am Gesamtschaden.

Abbildung SPLAN-2 zeigt die Ausgangsmatrix KFZ mit den Städten in den Zeilen und mit je einer Spalte für die drei Versicherungsarten HAFT, TEIL und VOLL. +

INFPLAN~ Matrix KFZ

rFommaridozeTleTn)

HAFT Ol-BREMEN 01-DUESS.DF Ol-DUISBURG . . . 01-GLS.KRCH 02-BOCHUM 02-ESSEN 02-KOELN 02-MANNHEIM .. 03-BERLIN 03-HAMBURG ... 03-HANNOVER .. 04-MUENCHEN..

.

. . . .

1.305 360 110 185 342 5.350 2.710 7.280 15.120 1.398 3.250 21.261

TEIL .. 412 208 60 .. . 20 131 4212 1 181 .. 3.807 .. 8.410 765 .. 1.812 .. . . . 1 2 . 7 1 0

Datum Ö8M89~ ZeitÍ4:n"Í5" +

VOLL, ... .... 1.331 782 ... 530 ... 805 ... 705 ... ... .... 2.561 ... .... 1.107 ... .... 1.966 ... .... 3.284 910 ... ... . . . . 3 . 2 3 5 ... .... 6.761

Kommando U M B A U SPALTE = (GESAMT NACH VOLL) Abb. SPLAN-2: Ausgangsmatrix

Nach der Spalte VOLL soll eine Spalte GESAMT angefügt werden. Das Kommando dafür lautet (vgl. Kommandozeile in Abbildung SPLAN-2): UMBAU SPALTE = (GESAMT NACH VOLL). Abbildung SPLAN-3 zeigt die mit der Spalte GESAMT ergänzte Ausgangsmatrix.

316

Methoden und Techniken der Feinprojektierung

INFPLAN Matrix KFZ Ol-BREMEN 01-DUESS.DF Ol-DUISBURG 01-GLS.KRC H 02-BOCHUM 02-ESSEN 02-KOELN 02-MANNHEIM 03-BERLIN 03-HAMBURG 03-HANNOVER 04-MUENCHEN

1 Kommandozeile(n)

HAFT

1.305 360 110 185 342 5.350 2.710 7.280 15.120 1.398 3.250 21.261

TEIL

412 208 60 20 131 4.212 1.181 3.807 8.410 765 1.812 12.710

Datum 08.08.89 Zeit 14:11:48

VOLL

1.331 782 530 805 705 2.561 1.107 1.966 3.284 910 3.235 6.761

GESAMT..

Kommando #GESAMT = #SUMME ( HAFT : VOLL ) IN ALLEN ZEILEN. Abb. SPLAN-3: Ergänzte Ausgangsmatrix A

Im nächsten Arbeitsschritt sollen die Werte der Spalte GESAMT berechnet werden. Dies erfolgt durch Eingabe des Kommandos (vgl. Kommandozeile in Abbildung SPLAN-3): #GESAMT = #SUMME (HAFT : VOLL) IN ALLEN ZEILEN. Das Zeichen # besagt, daß eine Rechenformel folgt. Das Ergebnis der Berechnung zeigt Abbildung SPLAN-4. +

f 5 ^ L Ä N MaÄx KFZ 01-BREMEN 01-DUESS.DF... 01-DUISBURG . 01-GLS.KRCH.. 02-BOCHUM.... 02-ESSEN 02-KOELN 02-MANNHEIM 03-BERLIN 03-HAMBURG . 03-HANNOVER 04-MUENCHEN

Datum"Ö8m89"äiTl4:13-07~ +

2 KommändozeTleYn)

HAFT

1.305 360 110 185 342 5.350 2.710 7.280 15.120 1.398 3.250 21.261

TEIL

412 208 60 20 131 4 212 1 181 3.807 8.410 765 1.812 12.710

VOLL

1.331 782 530 805 705 2.561 1.107 1.966 3.284 910 3.235 6.761

GESAMT.. 3.048 1.350 700 1.010 1.178 12.123 4.998 13.053 26.814 3.073 8.297 40.732

Kommando ABCANALYSE MERKMAL = GESAMT , ZEILENKLASSEN = ( 30;50;90), GRAFIK = ( TERMINAL ) , PROZENT = ( GESAMT )

+

+

Abb. SPLAN-4: Ergänzte Ausgangsmatrix B

In der Folge soll eine ABC-Analyse mit Grafik- und Tabellenausgabe angestoßen werden. Dies erfolgt durch die Eingabe des Kommandos (vgl. Kommandozeile in Abbildung SPLAN-4): ABCANALYSE MERKMAL = GESAMT, ZEILENKLASSEN = (30;50;90), GRAFIK = (TERMINAL) , PROZENT = (GESAMT). Durch dieses Kommando werden die Städte in drei Klassen geordnet; als Schwellenwert werden 30%, 50% und 90% des Gesamt-Schadensaufkommen angegeben. Es wird eine Lorenzkurve erzeugt, aus der z.B. ersichtlich ist, daß 28% der

SPLAN - Planungssprachen

317

Städte einen Anteil von 70% am Gesamt-Schadensaufkommen haben. Abbildung SPLAN-5 zeigt das Ergebnis der ABC-Analyse als Tabelle. Im nächsten Arbeitsschritt werden die Werte nach Regionen verdichtet (vgl. Kommandozeile in Abbildung SPLAN-5) usw.

04-MÜNCHEN... SU-KLASSE-01...

HAFT TEIL VOLL GESAMT.. GESAMT%.. 6.761 . ....40.732 . 21.261 .. ...12.710 .. 40.732 . 21.261 6.761 . ...12.710 ..

03 -BERLIN. SU-KLASSE-02...

.

02 -MANNHEIM.. 02 -ESSEN 03 -HANNOVER.. 02 -KOELN SU-KLASSE 0 3 . . .

7.280 3 807 5.350 4212 3.250 . 1 182 2.710 1 181 . . . . . 5 4 . 9 7 1 .. ...32.132

.

SU-REST SU-GESAMT

+

15.120 3.284 . ....26.814 8 410 •• 67.546 36.381 .. ...21.120 •• ....10.045 . .. .. .. .. ..

1.966 2.561 3.235 1.107 18.914

23

. ....13.053 . ....12.123 . 8.297 . 4.998 . ...106.017

3.700 5.063 . ....10.359 1 596 .. . . . . 5 8 . 6 7 1 .. ...33.728 .. ... 23.977 . ...116.376

Kommando SUMMIERE ZEILE = ( ? ? ? , 33? )

+

Abb. SPLAN-5: Ergebnis der ABC-Analyse

Forschungsbefunde Schneider et al. kommen auf Grund einer Analyse und einer vergleichenden Bewertung des Leistungsumfangs von 13 Planungssprachen zu folgenden Ergebnissen: • Dialogverarbeitung ist bei allen Planungssprachen realisiert. • Schnittstellen zu höheren Programmiersprachen sind bei allen Planungssprachen, zu Datenbanken nur bei einigen vorhanden. • Die meisten Planungssprachen arbeiten mit zweidimensionalen Matrizen; dreidimensionale Matrizen sind die Ausnahme. • Die Benutzerunterstützung bei der Modellerstellung ist sehr unterschiedlich entwickelt. • Alle Planungssprachen erlauben die Generierung von Eingabedaten, zumindest in Form der automatischen Wiederholung. • Alle Planungssprachen ermöglichen die grafische Berichtsausgabe; nur in Ausnahmefallen ist komplexe, mehrfarbige Grafik auf Plotter oder Bildschirm verfügbar. • Einige Planungssprachen erlauben die Spezifikation von Berichten nach Vorliegen der Ergebnisse; oft muß die Spezifikation bereits bei der Erstellung der Modellogik erfolgen. • Addition und Subtraktion gehören zum allgemeinen Leistungsumfang; weitere Befehle zur Dateibearbeitung (z.B. Sortieren und Kopieren) sind Besonderheiten.

318

Methoden und Techniken der Feinprojektierung

Aufgabenverweise Entwickeln des Methodensystems (Lerneinheit EMESY). Kontrollfragen 1. Welcher Zweck wird mit Planungssprachen verfolgt? 2. Welche charakteristischen Merkmale haben Planungssprachen? 3. Welche Kriterien können zur Bewertung des Leistungsumfangs von Planungssprachen verwendet werden? 4. Welche Bedeutung hat die Verfügbarkeit von Schnittstellen zu Datenbanken? 5. Worin besteht der Unterschied zwischen Planungssprachen und anderen Formen der individuellen Informationsverarbeitung? Quellenliteratur Humeltenberg, W.: Planungssprachen zur Entwicklung von Management-Support-Systemen. In: Krallmann, H. et al. (Hrsg.): Rechnergestützte Werkzeuge für das Management. Grundlagen, Methoden, Anwendungen. Schmidt Verlag, Berlin 1992, 73 - 107 Mertens, P. und Griese, J.: Integrierte Informationsverarbeitung 2 - Planungs- und Kontrollsysteme. 7. A„ Gabler Verlag, Wiesbaden 1993, 30 - 32 Schneider, St. et al.: Wesen, Vergleich und Stand von Software zur Produktion von Systemen der computerunterstützten Unternehmensplanung. Arbeitsberichte des Instituts für Informatik der Universität Erlangen-Nürnberg Bd. 16, Nürnberg 1983 Siemens-Nixdorf Informationssysteme (Hrsg.): Anwenderhandbuch INFPLAN. Bestellnummer U2846-J-Z87-1, München 1986 Siemens-Nixdorf Informationssysteme (Hrsg.): Benutzerhandbuch INFPLAN. Bestellnummer U1561-J-Z87-4, München 1986 Vertiefungsliteratur Naylor, Th. N. and Mann, M. H. (Ed.): Computer Based Planning Systems. Planning Executives Institute, Oxford/Ohio 1982 Siegmann, H.: Wesen, Vergleich und Stand von zehn ausgewählten kleinrechnerorientierten Planungssprachen. Arbeitsberichte des Instituts für Informatik der Universität Erlangen-Nürnberg Bd. 18, Nürnberg 1985

PAPER - Prinzipien der Arbeitsplatzergonomie Lernziele Sie kennen die Begriffe der Arbeitsplatzergonomie und ihre wichtigsten Prinzipien. Sie können Arbeitsplätze nach ergonomischen Anforderungen beurteilen und die Prinzipien der Arbeitsplatzergonomie zu ihrer Bessergestaltung anwenden. Sie erkennen, daß die ergonomischen Probleme - entgegen einer weit verbreiteten Auffassung - nicht gelöst sind, und daß mit der Verwendung neuer Technologien bislang unbekannte ergonomische Probleme sichtbar werden. Definitionen und Abkürzungen Abtastzeile (scan line) = der Aufbau einer Bildschirmzeile oder Bildschirmspalte durch horizontales oder vertikales Aneinanderfügen von Bildpunkten. Arbeitsplatz (workplace) = die kleinste Einheit einer Organisation, die durch die ihr zugeordnete Aufgabe, den oder die Aufgabenträger sowie die ihr zugeordneten Sachmittel gekennzeichnet ist. Auflösungsvermögen (resolving power) = die Anzahl der Bildpunkte je Flächeneinheit (Dimension: Pixel). Beleuchtungsstärke (illuminance) = der Lichtstrom pro beleuchteter Fläche bzw. Flächeneinheit (Dimension: Lux, abgek.: Ix). Bildwiederholfrequenz (refreshing rate) = die Frequenz, mit der das Bild der Kathodenstrahlröhre wiedererzeugt wird (Dimension: Hertz), cd = Akronym für Candela; Maßeinheit für Lichtstärke. dB = Akronym für Dezibel; Maßeinheit für Lautstärke. dB(A) = Akronym für Dezibel (A) = Maßeinheit für Lautstärke, bei deren Messung die hohen und tiefen Frequenzen weggefiltert werden, dpi = Akronym für dots per inch; eine Maßeinheit für Auflösungsvermögen. Ergonomie (ergonomics) = eine Interdisziplin, deren Ziel die Anpassung der Arbeitsorganisation (insbes. der Sachmittel) an die Eigenschaften und Bedürfnisse der menschlichen Aufgabenträger ist. Kontrast (contrast) = das Verhältnis der Leuchtdichten zweier nebeneinander liegender Flächen. Leuchtdichte (luminance) = der Quotient aus dem durch eine Fläche in einer bestimmten Richtung durchtretenden Lichtstrom und dem Produkt aus dem durchstrahlten Raumwinkel und der Projektion der Fläche auf eine Ebene, senkrecht zur betrachteten Richtung (DIN 66233); Maßeinheit: cd/m 2 . N = Abkürzung für Newton; Maßeinheit für Kraft, ppb = Akronym für parts per billion. Psychosomatik (psychosomatics) = die Lehre von den Wechselwirkungen zwischen seelischen Vorgängen und körperlichen (somatischen) Befindlichkeiten, psychosomatische Störung (psychosomatic disturbance) = eine Funktionsstörung oder eine Organveränderung, bei deren Entstehung komplexe psychophysiologische Prozesse (z.B. Streß) beteiligt sind. Reflexionsgrad (degree of reflectance) = das Verhältnis zwischen dem Lichtstrom, der von einer Oberfläche reflektiert wird, und dem Lichtstrom, der auf diese Oberfläche fällt.

320

Methoden und Techniken der Feinprojektierung

Zweck der Arbeitsplatzergonomie Im Zusammenhang mit der Systemplanung wird Ergonomie in die beiden - sich ergänzenden - Teilbereiche Arbeitsplatzergonomie ("klassische Ergonomie") und Kommunikationsergonomie ("kognitive Ergonomie", auch - wenig zutreffend - "Software-Ergonomie") gegliedert. Gegenstand dieser Lerneinheit sind die Prinzipien der Arbeitsplatzergonomie (zur Kommunikationsergonomie vgl. Lerneinheit PKOER). Zweck der Arbeitsplatzergonomie ist die optimale Abstimmung der Bedingungen des Arbeitsplatzes auf die physischen Anforderungen des Menschen. Die Arbeitsplatzergonomie soll dem Menschen als Benutzer von Techniksystemen die Aufgabenerfüllung erleichtern sowie zu seinem persönlichen Wohlbefinden und zur Steigerung von Arbeitszufriedenheit, Motivation, Produktivität und Wirtschaftlichkeit beitragen. Gestaltungsobjekt der Arbeitsplatzergonomie ist der Arbeitsplatz mit seinen Komponenten Aufgabe, Benutzer, Sachmittel (insbes. Informations- und Kommunikationstechnik) und Arbeitsplatzumgebung; diese Komponenten sind aufeinander abzustimmen. Die Prinzipien der Arbeitsplatzergonomie lassen sich präzisieren, wenn der Stand der Kenntnis durch wissenschaftliche Untersuchungen und/oder langjährige Erfahrungen ausreichend abgesichert ist. Sie führen dann zur Formulierang von Richtlinien, Empfehlungen und Bewertungskriterien. Wegen der Vielfalt derartiger Aussagen kann im folgenden nur auszugsweise auf sie eingegangen werden. In einem IuK-Projekt muß die einschlägige und aktuelle Literatur ergänzend herangezogen werden. Gestaltungsgegenstände der Arbeitsplatzergonomie Folgende Gestaltungsgegenstände der Arbeitsplatzergonomie sind bei der Informationssystem-Planung von besonderem Interesse: • die Ausstattung des Arbeitsplatzes: Tisch und Ablageflächen, Arbeitsstuhl, Arbeitsgeräte wie Tastatur, Bildschirm, Drucker, Telefon usw.; • die Arbeitsplatzumgebung: visuelle Umgebung, akustische Umgebung, thermische Umgebung. Der Prozeß der Arbeitsplatzgestaltung beginnt mit der Aufgabenanalyse (vgl. Lerneinheit ANIST) und endet mit dem Bestimmen des Technikbedarfs für den Arbeitsplatz (vgl. Lerneinheit BTECH). Bei der Aufgabenanalyse werden die physischen Anforderungen der Benutzer erfaßt. Die Entwicklung alternativer Prototypen des Arbeitsplatzes und ihre Bewertung gemeinsam mit den zukünftigen Benutzern ist empfehlenswert. In den meisten Fällen erweisen sich Lösungen als unbefriedigend, die sich an den statistischen Durchschnittswerten der menschlichen Physis orientieren. Arbeitshaltung Körperliches Unbehagen und Ermüdungserscheinungen werden vor allem durch ungünstige Blickwinkel, große Kontrastunterschiede zwischen wesentlichen

PAPER - Prinzipien der Arbeitsplatzergonomie

321

Wahrnehmungsobjekten, ungeeignete Tastatur-, Tisch-, und Stuhlhöhen, fehlende Bewegungsmöglichkeit und mangelnde Anpassungsfähigkeit des Arbeitsplatzes an unterschiedliche physische Anforderungen hervorgerufen. Falsche Arbeitshaltungen haben folgende Merkmale: Oberkörper zurückgelehnt, Hals nach vorn gebeugt, Arme nach vorne gestreckt, Unterarme und Hände auf der Höhe zwischen Schulter und Ellenbogen gehalten. Als optimale Arbeitshaltung wird empfohlen: Der Nacken soll, gemessen von der Kopf-Nacken-Achse zur Rumpflängen-Achse, nicht mehr als 20% des möglichen Beugungsradius nach vorn gebeugt sein; die Schultern sollen entspannt sein; die Oberarme sollen mit einem Ellenbogenwinkel von 90 Grad herabhängen; die Unterarme und die Hände sollen in horizontaler Position gehalten werden.

Reichweite und Sehentfernung Beim Entwickeln der Arbeitsorganisation (vgl. Lerneinheit EAORG) wird auch festgelegt, welche Sachmittel mit welcher Benutzungshäufigkeit an einem Arbeitsplatz verwendet werden sollen. Als Regel für deren Anordnung gilt, daß die am häufigsten benutzten Sachmittel innerhalb der Reichweite des Benutzers liegen sollen, sodaß sie mit auf dem Tisch aufgelegten Ellenbogen erreicht werden können. Diese optimale Reichweite umfaßt zwei sich vor dem Körper überschneidende Halbkreise (vgl. Abbildung PAPER-1), deren Radien (ca. 35 bis 45 cm) durch die Länge der Unterarme gebildet werden. Mit ausgestreckten Armen erhöhen sich die Radien auf rund 55 bis 65 cm; allerdings werden bei dieser Reichweite die Armmuskeln stärker belastet. Wenn der Benutzer diese Reichweite überschreiten will, muß er den ganzen Körper nach vorn bewegen.

322

Methoden und Techniken der Feinprojektierung

Für die optimale Sehentfernung können keine allgemein gültigen Gestaltungsrichtlinien angegeben werden. Sie hängt vor allem von der Zeichengröße ab. Entfernungen zwischen Auge und Wahrnehmungsobjekt bis 45 cm gelten als nahe, von 45 cm bis 100 cm als mittel und von mehr als 100 cm als weit. Ausstattung des Arbeitsplatzes Für die Gestaltung von Arbeitstischen für sitzende Benutzer gelten die folgenden Richtlinien: Die richtige Tischhöhe liegt dann vor, wenn der Benutzer aufrecht und entspannt sitzen kann; bei leicht vorgebeugter Haltung sollen die Unterarme bequem aufliegen und die Ellenbogen einen rechten Winkel bilden können. Schreibtische sollen eine Höhe von mindestens 630 mm bis zur Tischunterkante haben; die Höhe soll in sitzender Haltung leicht einstellbar sein. Die Beinraumtiefe am Fußboden soll mindestens 600 mm betragen, die seitliche Beinfreiheit mindestens 700 mm. Die Tischbeine sollen zurückgesetzt sein, damit sie die Knie des Benutzers nicht behindern, wenn er sich zum Tisch hin oder vom Tisch weg bewegt. Alle Kanten und Ecken sollen abgerundet sein. Bildschirmtische sollen unter Berücksichtigung folgender Empfehlungen ausgewählt werden (das Gleiche gilt für PC-Tische): Die Tischgröße soll für die Bildschirmeinheit ausreichend groß sein. Zwei unabhängig voneinander einstellbare Flächen sind zu empfehlen, eine für den Bildschirm und eine für die Tastatur. Alle Einstellungen des Bildschirmtischs sollen in sitzender Haltung leicht ausgeführt werden können. Wenn mehrere Benutzer den gleichen Bildschirm verwenden, sollen die Einstellungseinrichtungen des Bildschirmtischs mit Meßskalen versehen sein, damit eine Verstellung leicht und schnell erfolgen kann. Bei der Wahl von Druckertischen sind folgende Kriterien zu berücksichtigen: Standfestigkeit; Vibrationsdämpfung; an den Drucker angepaßte Größe und Form; Vorhandensein von Ablagemöglichkeiten für Papier unter dem Drucker; Vorhandensein von Papierauffang-Vorrichtungen hinter dem Drucker; ausreichende Beinfreiheit, damit sich der Benutzer zwischen Druckertisch, Bildschirmtisch und Schreibtisch bequem bewegen kann. Für die Bewertung des Arbeitsstuhls sind folgende Kriterien zu berücksichtigen: Stabilität und breite Standfläche; Sitzhöhe zwischen 390 mm und 540 mm einstellbar; Sitzfläche mit einer nicht zu dicken Auflage (beispielsweise aus Schaumstoff) versehen; Sitzflächenbreite mindestens 420 mm; Rückenlehne 360 mm bis 400 mm breit, mindestens 320 mm hoch und in einem Winkel von 10 Grad bis 25 Grad zur Vertikalen verstellbar. Bildschirm und Tastatur sollen getrennt sein. Die optimale Bildschirmgröße ist von der Art der zu verrichtenden Aufgabe, im wesentlichen von der darzustellenden Informationsmenge, abhängig. Ist der Bildschirm für eine bestimmte Aufgabe zu klein, steigen Informationsdichte und Suchzeit. Als geringe Bildschirmgröße gilt ein Darstellungspotential von 6 Zeilen zu je 40 Zeichen; mit großen Bildschirmen lassen sich etwa 30 Zeilen mit je 120 bis 130 Zeichen darstellen. Für die Textverarbeitung haben sich Bildschirme in DIN-A-4-Größe bewährt, da sie die vollständige Darstellung der üblicherweise verwendeten Seitengröße ermöglichen.

PAPER - Prinzipien der Arbeitsplatzergonomie

323

Die Positivdarstellung ist der Negativdarstellung vorzuziehen, weil der Kontrastwechsel zwischen Papier und Bildschirm angenehmer erlebt wird, weniger Maßnahmen bezüglich der Umgebungsbeleuchtung erforderlich sind und sich dadurch eine höhere Flexibilität in der Layout-Planung der Arbeitsplätze ergibt. Bildschirme sollen möglichst flimmerfrei sein; dies wird durch eine Phosphorschicht mit einer kurzen bis mittleren Nachleuchtdauer erreicht. Bei der Verwendung der Phosphorarten P4 (weiß leuchtend) und P39 (gelblichgrün leuchtend) soll die Bildwiederholfrequenz 50 Hz betragen. Bei P31 für Negativ-Bildschirme wird eine Bildwiederholfrequenz von 55 bis 60 Hz empfohlen. Die Bildwiederholfrequenz von Positiv-Bildschirmen soll 70 Hz nicht unterschreiten. Das Auflösungsvermögen des Bildschirms soll mindestens 10 bis 12 Abtastzeilen pro Zeichenhöhe betragen. Die Abtastzeilen sollen horizontal aufgebaut werden. Bei den meisten Bildschirmen werden Zeichen durch eine Punktmatrix gebildet. Die Form der Punkte kann rund oder quadratisch, soll aber nicht rechteckig sein. Der Abstand der Punkte zueinander soll so gering wie möglich sein, um die Kontinuität der Zeichenlinien zu gewährleisten. Die Dichte einer Punktmatrix von 7 x 9 Punkten stellt die Untergrenze für eine einwandfreie Erkennbarkeit dar. Eine Matrixgröße von 11 x 14 Punkten oder mehr wird empfohlen. Empfehlungen für die Zeichengröße orientieren sich an der Sehentfernung. Die Zeichenhöhe soll etwa 20 Bogenminuten betragen, das sind bei 600 mm Sehentfernung 4 mm. Für die Zeichenbreite wird ein Breiten-Höhen-Verhältnis von 1:6 bis 1:8 bei Positiv-Bildschirmen, von 1:8 bis 1:10 bei Negativ-Bildschirmen empfohlen. Der Zeilenabstand (vertikaler Abstand der Zeichen) soll zwischen 10% und 50% der Zeichenhöhe, der horizontale Abstand der Zeichen (Zeilenabstand) soll zwischen 25% und 100% der Zeichenhöhe betragen. Der optimale Zeichenkontrast auf Negativ-Bildschirmen erfordert bei einer Raumbeleuchtungsstärke von 300 Lux eine Zeichenleuchtdichte von 80 bis 160 cd/m 2 . Sie soll einstellbar sein, wobei die Zeichen auch bei größter Helligkeit noch lesbar sein müssen. Die Hintergrundleuchtdichte kann bis zu 20 cd/m 2 betragen. Bei einer Hintergrundleuchtdichte von 15 bis 20 cd/m2 beträgt das optimale Kontrastverhältnis zwischen Zeichen und Hintergrund 10:1. Der optimale Zeichenkontrast für Positiv-Bildschirme wird wie folgt definiert: Hintergrundleuchtdichte einstellbar bis 170 cd/m 2 und homogen über den ganzen Bildschirm; Kontrastverhältnis zwischen Zeichen und Hintergrund zwischen 1:8 und 1:12. Blendung, Spiegelung und statische Aufladung können durch Bildschirmfilter, die absorbierendes Glas oder Verbundglas verwenden, reduziert bzw. weitgehend vermieden werden. Dies wird durch die Antireflexbeschichtung des Glases bzw. Verbundglases auf beiden Oberflächen erreicht. Die Antireflexbeschichtung wurde für Fenster und Instrumente von Raumfähren entwickelt (HEA = High Efficiency Antireflection). Die elektrisch leitfähige HEA-Beschichtung auf der Rückseite führt statische elektrische Energie und 98% der Niederfrequenzstrahlung ab. Dies ist deshalb von Bedeutung, weil statische elektrische Felder an Bildschirmarbeitsplätzen - in Verbindung mit ungünstigem Raumklima und Ausstattungsmaterial - zu hohen Feldstärken führen, die sich durch Entladungsschocks und Ablagerungen geladener Luftteilchen an der Bildschirmoberfläche und an

324

Methoden und Techniken der Feinprojektierung

bestimmten Hautpartien des Menschen (Wange, Nase, Augen) negativ bemerkbar machen. Nicht empfehlenswert sind Kunststoffilter, Micro-Mash-Filter und Polarisationsfilter, weil sie zu einer Reduzierung der Flächenhelligkeit durch Absorption von Licht führen. Kriterien für die Bewertung der Qualität der Schreibmarke ("Cursor") sind Auffindbarkeit am Bildschirm, Verfolgbarkeit über den Bildschirm, Beeinträchtigungsfreiheit der unterlegten Zeichen und Unterscheidbarkeit von anderen Zeichen. Für die Tastatur gelten die folgenden Empfehlungen: • Das Tastatur-Layout soll das alphanumerische Feld in der Mitte vorsehen, rechts davon die Cursor- und Editiertasten sowie die numerische Tastatur. Die Funktionstasten können überall auf der Tastatur liegen. • Die Tastaturbelegung ist aufgabenabhängig. Daraus folgt, daß Tastaturen einen gewissen Grad an Flexibilität haben sollen. Die Belegung des alphanumerischen Feldes soll dem QWERTZ-Standard entsprechen. Das numerische Feld kann entweder eine "7-8-9, 4-5-6, 1-2-3, 0"-Belegung oder eine "0, 1-2-3, 4-5-6, 7-8-9"-Belegung (jeweils von links unten nach rechts oben gelesen) aufweisen, wobei sich die zweite Variante weitgehend durchgesetzt hat. • Eine maximale Tastaturhöhe von 30 mm zwischen der Tischplatte und der Tastenreihe ASDF... wird empfohlen. Der empfohlene Tastaturneigungswinkel liegt zwischen 5 Grad und 11 Grad. Höhe und Neigungswinkel sollen verstellbar sein (nur selten möglich). • Die Tastenform soll quadratisch, mit einer Seitenlänge von 12 bis 15 mm, sein. Der Tastenabstand ist auf 19,05 mm von Tastenmitte zu Tastenmitte standardisiert. Der Tastenhub soll zwischen 0,8 und 4,8 mm liegen. Die Beschriftung der Tasten soll klar definiert und hell sein; die Tasten selbst sollen eine matte Oberfläche haben. Tastaturen für Positiv-Bildschirme sollen von heller Farbe sein und eine kontrastreiche Beschriftung haben. Eine Tastenbetätigungskraft zwischen 0,25 N und 1,5 N ist optimal. Üblich sind rechteckige Tastaturen, bei denen die Tasten in geraden Reihen übereinander angeordnet sind. Diese Anordnung folgt dem Vorbild der Tastatur bei mechanischen Schreibmaschinen, bei denen sie wegen der mechanischen Verbindung der Tasten mit den Typenhebeln erforderlich war. Bei Computer-Tastaturen, bei denen durch den Tastenanschlag lediglich Kontakte geschlossen werden, ist dies nicht notwendig. Rechteckige Tastaturen haben unter ergonomischen Gesichtspunkten den Nachteil, daß sie eine statische Muskelbelastung hervorrufen, die durch die Abwinklung der Handgelenke nach außen ("Abduktion"), in Verbindung mit einer Drehung nach innen ("Pronation"), verursacht wird. Seit Jahren gibt es Vorschläge für Tastaturen, mit denen Abduktion und Pronation vermieden werden. Seit 1993 ist eine Tastatur (für den Apple Macintosh) verfügbar, die aus zwei verstellbaren Hälften, die sich bis zu einem Winkel von 30 Grad auseinanderziehen lassen, besteht. Die Tastatur kann so eingestellt werden, daß beide Unterarme und Hände jeweils eine gerade Linie bilden; die Leertaste bleibt in der Mitte. Ergänzt wird die Tastatur durch zwei Handauflageflächen, die sich abnehmen lassen. Höhe und Neigung der Tastatur lassen sich über verstellbare Füße regulieren.

PAPER - Prinzipien der Arbeitsplatzergonomie

325

Als ergonomisch zweckmäßigstes Zeigeinstrument hat sich die Maus durchgesetzt. Standard ist ein Auflösungsvermögen von max. 320 dpi, was bedeutet, daß beim Abtasten einer Strecke von einem inch von der Maus maximal 320 Impulse zum Bewegen der Schreibmarke geliefert werden. Dies ermöglicht ein sehr schnelles Positionieren der Schreibmarke. Ergonomisch problematisch ist, daß beim Bewegen der heute üblichen Maus das Armgewicht mit dem äußeren Handwurzelknochen auf der Arbeitsplatte abgestützt werden muß, weil die Rollkugel in der Mitte oder sogar in dem Teil der Maus untergebracht ist, der dem Benutzer zugewendet ist. Zweckmäßiger ist daher eine Konstruktion, bei der die Rollkugel in dem Teil der Maus untergebracht ist, die dem Benutzer abgewandt ist. Dadurch kann die Maus stärker mit den Fingern und muß weniger von der Mittelhand aus dem Gelenk heraus bedient werden, und die Abstützung des Armgewichts wird auf die Mittelhand verlagert. Eine länglich gerundete Form (statt der üblichen eckigen Form) stützt die Handfläche. Durch Verlagerung der Maustaste an die Mausspitze wird eine Bedienung mit jedem Finger kleiner wie großer Hände ermöglicht. Arbeitsplatzumgebung Bei der Gestaltung der Arbeitsplatzumgebung wird zwischen visueller Umgebung (insbes. Beleuchtung), thermischer Umgebung (insbes. Temperatur und Luftfeuchtigkeit) und akustischer Umgebung (Geräusche) unterschieden. Darüber hinaus soll bedacht werden, daß weitere Eigenschaften der Umgebung negative Einflüsse auf den Menschen haben können (z.B. elektromagnetische Strahlung). Visuelle Umgebung: Für die optimale beleuchtungstechnische Ausstattung von Arbeitsräumen zur Vermeidung von visuellem Unbehagen, Augenermüdung oder Sehstörungen gelten folgende Richtlinien: Der Raum soll eine Möglichkeit zur Dämpfung des Tageslichts (Vorhänge, Jalousien) aufweisen; die künstliche Raumbeleuchtung soll stark diffusen Charakter haben, frei von Blendungen sein und eine Beleuchtungsstärke von 200 bis 300 Lux bieten. Jeder Arbeitsplatz soll mit einer einstellbaren Zusatzleuchte ausgestattet sein. Der Reflexionsgrad des Bodens soll 0,2 bis 0,4 betragen, der der Decke 0,7 bis 0,8. Die hinter dem Bildschirm liegende Wand soll einen Reflexionsgrad von 0,4 bis 0,5 aufweisen, für die gegenüberliegende Wand und für die Oberfläche des Arbeitstischs werden Werte von 0,3 bis 0,45 empfohlen. Diese Richtlinien gelten für Negativ-Bildschirme, für Positiv-Bildschirme wurden, soweit bekannt, noch keine Empfehlungen entwickelt. Thermische Umgebung: Für sitzende Tätigkeiten ist eine Lufttemperatur (das ist die in einer Höhe von 75 cm über dem Fußboden in der Mitte eines geschlossenen Raumes gemessene Temperatur) zwischen 19 und 23 Grad Celsius optimal. Da für das Wärmeempfinden auch die Temperatur der Umschließungsflächen des Raumes bestimmend ist, wird beim Begriff "Raumtemperatur" neben der Lufttemperatur die Wärmestrahlung berücksichtigt; sie kann sowohl von wärmeabgebenden als auch von wärmeentziehenden Objekten verursacht werden. Heizkörper in der Umgebung sollen weder zu große Hitze abstrahlen, noch direkt auf den Benutzer gerichtet sein. Maximale Windgeschwindigkeiten zwischen 0,1 und 0,2 m/Sek. sind optimal. Die relative Luftfeuchtigkeit soll 30% bis 70% betragen. Raumtemperatur, Windgeschwindigkeit und relative Luftfeuchtigkeit zusam-

326

Methoden und Techniken der Feinprojektierung

men bestimmen die Qualität der thermischen Umgebung; sie wird als Effektivtemperatur bezeichnet. Einer bestimmten Effektivtemperatur (z.B. 25 Grad C) entsprechen unterschiedliche Kombinationen der drei Einflußfaktoren (z.B. 25 Grad C, 0,1 m/Sek. und 100%, aber auch 37 Grad C, 3,0 m/Sek. und 10%). Akustische Umgebung: Die normal laute menschliche Sprache bewegt sich im Bereich von 55 bis 65 dB(A) und übersteigt beim Schreien selten 80 bis 90 dB(A). Deshalb wird die Sprachverständlichkeit gestört oder unterbunden, wenn der Schallpegel 70 dB(A) oder mehr beträgt. Liegt der Schallpegel höher als 85 dB(A) ("Schädigungsbereich"), besteht die Gefahr der Schädigung des menschlichen Gehörs, bei mehr als 125 dB(A) ("Schmerzbereich") kann diese Schädigung sehr schnell eintreten und schwerwiegende Folgen haben. Die Geräuschentwicklung von Bildschirmventilatoren, die zur Wärmeabfuhr dienen, erreicht gelegentlich Werte von 60 dB(A) und mehr, was häufig als lästig empfunden wird und stört (z.B. bei Telefongesprächen). Matrix- und Typenraddrucker entwickeln häufig Schallpegel von 70 bis 80 dB(A); sie sollen daher ausschließlich in schalldichten Räumen oder unter Schallschluckhauben betrieben oder durch andere Drucker (z.B. Tintenspritzdrucker) ersetzt werden. Die Geräuschentwicklung der Plattenlaufwerke von PCs kann im Einzelfall störend sein. Nach der Arbeitsstättenschutzverordnung soll der Schallpegel so niedrig gehalten werden, wie dies nach Art des Betriebs möglich ist. Bei überwiegend geistigen Tätigkeiten sollen 55 dB(A), bei einfachen oder überwiegend mechanisierten Tätigkeiten 70 dB(A), bei allen sonstigen Tätigkeiten 85 dB(A) nicht überschritten werden. In Ausnahmefällen sind Abweichungen bis zu 5 dB(A) erlaubt. Sonstige Umgebungseinflüsse: Neue Technologien können weitere, zum Teil noch unbekannte negative Umgebungseinflüsse auslösen. Ein aktuelles Beispiel sind Laser-Drucker, die bezüglich der akustischen Umgebung problemlos sind, wegen der Ozon-Abgabe aber die Gesundheit beeinträchtigen können. Für Ozon am Arbeitsplatz wurde die "Maximale Arbeitsplatzkonzentration" (abgekürzt: MAK) von 100 ppb oder 0,1 cm 3 pro m 3 Luft bereits 1958 festgelegt. Dieser Wert führt, nach dem damaligen Stand der Kenntnis, auch bei wiederholter und langfristiger Einwirkung nicht zu einer Beinträchtigung der Gesundheit. Bei Laser-Druckern wird der Wert durch den Einbau von Filtern erreicht bzw. unterschritten. Die verwendeten Filtertypen sind unterschiedlich wirksam und bedürfen zumeist der Wartung (z.B. nutzen sich Aktivkohle-Filter ab). Nicht rechtzeitiger Filteraustausch kann dazu führen, daß die Abluft das Ozon (neben Staub und Tonerpartikeln) ungehindert in den Raum transportiert. Durch Tests an einem bestimmten Laser-Drucker konnte gezeigt werden, daß die Ozon-Emissionsrate mit Filter 5 Mikrogramm/min., ohne Filter 245 Mikrogramm/min. beträgt. Da der genannte Grenzwert heute umstritten ist und eindeutige Befunde zu den Auswirkungen der Ozonbelastung nicht vorliegen, sollten Laser-Drucker nicht in Räumen, in denen Menschen ständig arbeiten, installiert werden. Demonstrationsbeispiel Das Ergonomiezentrum Salzburg faßt die am häufigsten beobachteten Mängel bei der ergonomischen Gestaltung von Computer-Arbeitsplätzen und die sich daraus ergebenden Konsequenzen wie folgt zusammen:

PAPER - Prinzipien der Arbeitsplatzergonomie

327

• Falsche Aufstellung des Bildschirms; Fensterflächen im Blickfeld oder hinter der arbeitenden Person. Folge: Starke mentale Belastung. • Untaugliche Lichtverhältnisse. Folge: Augenprobleme, Konzentrationsschwierigkeiten. • Lichtquellen vor dem Arbeitsplatz installiert. Folge: Blendung, Augenprobleme. • Stühle, die dynamisches Sitzen nicht unterstützen. Folge: Rückenschmerzen, Verspannungen. • Nicht ausbaubare Arbeitstische mit fixen Ladenunterstützen (meist an beiden Seiten); Einschränkungen bei der Bildschirmaufstellung. Folge: Rückenschmerzen, Augenbeschwerden. • Schlechte Qualität der Bildschirme; Flimmern und falsche Farbgebung. Folge: Augenbelastung, Konzentrationsschwierigkeiten. • Trockene Luft. Folge: Vermehrt Erkältungskrankeiten, Augenprobleme und Hautbeschwerden. Diese und ähnliche Hinweise können als Prüfliste für eine explorative Vorstudie zur Untersuchung von Computer-Arbeitsplätzen verwendet werden. Lärm wird von Menschen als störend empfunden, wobei die Lautstärke nur eines von mehreren Kriterien ist, und zwar das, welches objektiv mit der Maßeinheit dB(A) gemessen wird. Mit 0 dB(A) ist die Hörschwelle auf der Meßskala fixiert. Die zehnfach stärkere Lautstärke ist mit 10 dB(A) festgelegt, die hundertfache mit 20 dB(A), die tausendfache mit 30 dB(A) usw. Die Schmerzschwelle liegt bei 130 dB(A). Dieser logarithmischen Skalierung entsprechend, bewirkt eine Verminderung der Lautstärke um nur 6 dB(A) eine Halbierung der Intensität des Schalls. Die durch das menschliche Ohr empfundene Reduzierung des Lärms um 50% setzt bei 10 dB(A) ein. Ein anderes Kriterium ist, ob man sich Geräuschen freiwillig aussetzt. Ob ein Geräusch als Lärm empfunden wird, ist also letztlich subjektiv. Forschungsbefunde Eine Erhebung von Gunnarson/Östberg über subjektive Beschwerden von Bildschirmbenutzern in einem großen schwedischen Versicherungsunternehmen, führte zu folgenden Ergebnissen (die Prozentzahlen geben den Anteil der Befragten an, die über die jeweiligen körperlichen Beschwerden klagten): Augen 55%; Rücken 53%; Kopf 30%; Schultern 25%; Handgelenk 18%; Nacken 15%. Nach Auffassung des Berufsverbandes der Augenärzte Deutschlands sind Bildschirmarbeitsplätze keine Gefahr für die Gesundheit (vgl. FAZ vom 22. 11. 1985, 10). Nach einer Studie des Verbandes hat die Bildschirmarbeit weder negative Auswirkungen auf Schwangere, noch ruft selbst eine mehrstündige konzentrierte Tätigkeit an Bildschirmarbeitsplätzen organische Veränderungen am Auge hervor. Eingeräumt wird allerdings, daß bei entsprechend veranlagten Menschen psychosomatische Störungen, wie Kopfschmerzen oder Magenverstimmungen, möglich sind. Hautärzte der Karolinska Klinik in Stockholm haben festgestellt, daß akneähnliche Hautausschläge bei Frauen, die täglich längere Zeit am Bildschirm arbei-

328

Methoden und Techniken der Feinprojektierung

ten, von den elektrostatischen Feldern der Bildschirmgeräte ausgelöst werden ("Welt am Sonntag" vom 14. 6. 1987, 13). Wie der Effekt zustande kommt, konnte noch nicht geklärt werden. Hautempfindliche Frauen sollen daher nur an Bildschirmen arbeiten, die mit einer Beschichtung versehen sind, welche die Abstrahlung der elektrostatischen Felder verhindert. Umstritten ist, ob elektromagnetische Felder im niederfrequenten Bereich (umgangssprachlich "Elektrosmog"), also unterhalb langer Radiowellen, schädlich sind. Häufig zitiert wird die Studie von Wertheimer/Leeper aus dem Jahre 1979, die erhöhte Leukämie bei Kindern feststellte, die mit ihren Eltern in der Nähe von Hochspannungsleitungen lebten. Das Kaiser Permanent Medical Care Program in Oakland veröffentlichte 1988 Ergebnisse einer Feldstudie. Bei 20% der untersuchten 1.583 schwangeren Frauen, mit einer Arbeitszeit von mehr als 20 Stunden/Woche am Bildschirm, wurde ein erhöhtes Fehlgeburtenrisiko festgestellt. Umstritten sind diese und ähnliche Befunde vor allem deshalb, weil sich die Ursachen der Beobachtungen nicht eindeutig zuordnen lassen. Die Reaktionen sind daher weltweit unterschiedlich. In Schweden wurden trotz widersprüchlicher Befunde Empfehlungen für strahlungsarme Bildschirme formuliert (die sog. MPR-Werte der Staatlichen Meß- und Prüfanstalt), die um ein Vielfaches unter den Werten in anderen Ländern liegen. Kollert/Donderer/Boikat kommen in einer Studie (1987) zu dem Ergebnis, daß schwache elektromagnetische Strahlung an Bildschirmgeräten als "favorisierter Auslöser" für Gesundheitsstörungen gelten muß. Das Institut für Strahlenhygiene des Bundesgesundheitsamtes (Neubiberg bei München) hat dazu kontrovers Stellung genommen, indem es erklärt, daß es "keinen kausalen Zusammenhang zwischen einer Emission ionisierender und nicht-ionisierender Strahlen aus Bildschirmgeräten und gesundheitlichen Risiken" gibt. Schaden ginge vielmehr von ungünstiger Arbeitshaltung, Sehproblemen und Streß aus. Die Hersteller haben in dieser unübersichtlichen Situation mit strahlungsarmen Bildschirmen reagiert, wobei sie sich an den MPR-Werten orientierten. Aufgabenverweise Entwickeln der Arbeitsorganisation (Lerneinheit EAORG). Kontrollfragen 1. Mit welchen Gestaltungsobjekten befaßt sich die Arbeitsplatzergonomie? 2. Welche Merkmale kennzeichnen falsche Arbeitshaltung am Bildschirmarbeitsplatz? 3. Welche Druckertechnologie kann unter ergonomischen Gesichtspunkten als optimal angesehen werden? 4. Durch welche Maßnahmen kann die ergonomische Qualität von Bildschirmtastaturen verbessert werden? 5. Zu welcher Schlußfolgerung können die widersprüchlichen Befunde zur Arbeitsplatzergonomie verdichtet werden? Quellenliteratur Berns, T. (Hrsg.): Die ergonomischen Prinzipien der Büroautomation. Der neueste Erkennmisstand sowie Richtlinien für die Humanfaktoren im Bürobereich. Verlag Ericsson Information Systems AB, Bromma 1984,11 - 76 Cakir, A. et al.: Bildschirmarbeitsplätze. Springer Verlag, Berlin et a. 1980 Mikuteit, H.-L.: "Computer machen krank". In: MACup 1/1991,12 - 16

PAPER - Prinzipien der Arbeitsplatzergonomie

329

Vertiefungsliteratur Cakir, A.: Bürobeleuchtung - ein neues Konzept nimmt Formen an. In: Office Management 2/1986, 166 - 173 Gunnarsson, E. and Östberg, O.: Physical and mental working environment in a terminal-based Computer system. In: Arbetarskyddsstyrelsen, August 1977, 35 (in Schwedisch) o.V.: Reizklima Büro. Ozonausstoß von Laserdruckern. In: Konsument. Das österreichische Testmagazin 1/1994, 17 - 19 Peters, T.: Arbeitswissenschaft für die Büropraxis. Ein Handbuch für Büro-Medizin und -Ergonomie. Schilling Verlag für Informationstechnik, Herne 1973 Schmidtke, H.: Ergonomische Bewertung von Arbeitssystemen - Entwurf eines Verfahrens. Hanser Verlag, München/Wien 1976 Schnauber, H.: Arbeitswissenschaft. Verlag Vieweg, Braunschweig 1979 Normen DIN 2137 Alphanumerische Tastaturen: Schreibmaschinentastatur, Belegung mit Schriftzeichen. DIN 2139 Alphanumerische Tastaturen: Tastenanordnung für Dateneingabe. DIN 33402 Teil 2: Körpermaße des Menschen; Werte. DIN 4549 Büromöbel: Schreibtische, Büromaschinentische und Bildschirmarbeitstische, Maße. DIN 5035 Teil 2: Innenraumbeleuchtung mit künstlichem Licht. Richtwerte für Arbeitsstätten. DIN 66234 Teil 1 - 7: Bildschirmarbeitsplätze.

PKOER - Prinzipien der Kommunikationsergonomie Lernziele Sie kennen den Zweck der Prinzipien der Kommunikationsergonomie und können ihre Gültigkeit für das Gestalten der Interaktionsaufgabe beurteilen. Sie können die Forderung nach einer einheitlich gestalteten Interaktionsaufgabe für unterschiedliche Sachaufgaben begründen. Sie kennen die Prinzipien der Kommunikationsergonomie gemäß DIN 66234 Teil 8 und die Prinzipien der Gestaltpsychologie. Sie können Kriterien für das Gestalten von Hilfe-Systemen nennen. Deßnitionen und Abkürzungen ACM = Akronym für Association for Computing Machinery. Benutzbarkeit (usability) = die Eigenschaft eines Systems, vom Menschen ("Benutzer") leicht erlernt und sicher verwendet werden zu können; häufig als "Benutzerfreundlichkeit" bezeichnet. Benutzeroberfläche (user interface) = der Teil der Benutzerschnittstelle, der für den Benutzer sichtbar ist. Synonym: Benutzungsoberfläche. Benutzerschnittstelle (user interface) = die Komponenten eines Mensch-Computer-Systems, über die der Benutzer mit dem Computersystem interagiert. Synonym: Benutzungsschnittstelle. Dialogsystem (dialog system) = ein in der DIN 66234 verwendetes Synonym für Benutzerschnittstelle. Gestalt (gestalt) = ein Schema oder Gebilde, das als Ganzes eine andere Qualität hat als seine Elemente und Strukturen und das auch dann erhalten bleibt, wenn seine Farbe, seine Größe und andere Eigenschaften verändert werden. Gestaltgesetz (gestalt gesetz) = eine Erklärung, wie sich aus Elementen und Strukturen "Gestalten" mit eigener Qualität ergeben. Gestaltpsychologie (gestalt psychology) = die "Schule der Psychologie", die psychische Prozesse, Erlebnisse und Handlungen nicht aus den Elementen, sondern als "gegliederte Ganze", den sog. Gestalten, zu erklären versucht; eine Richtung der Wahrnehmungspsychologie. Groupware (groupware) = eine Anwendungssoftware zur Unterstützung von Arbeiten, die für Gruppenarbeit typisch sind. Hilfe-System (help system) = der Teil eines Anwendungssystems, der dem Benutzer die Informationen zur Verfügung stellt, die ihn bei der aufgabengerechten Durchführung des Dialogs unterstützen. Interaktion (interaction) = die wechselseitige Beeinflussung des Handelns zwischen den Elementen eines Systems durch Kommunikation. Synonyme: Dialog, Wechselbeziehung. Interaktionsaufgabe (interaction task) = der Teil einer systemunterstützten betrieblichen Aufgabe, der nicht Sachaufgabe ist und der der Interaktion zwischen dem Benutzer und der Sachaufgabe dient. Kommunikationsergonomie (communications ergonomics) = der Teil der Ergonomie, der die psychischen (kognitiven und motivationalen) Eigenschaften des Menschen in das Gestalten der Interaktionsaufgabe einbezieht. Synonyme: kognitive Ergonomie, Software-Ergonomie.

PKOER - Prinzipien der Kommunikationsergonomie

331

Zweck der Prinzipien der Kommunikationsergonomie Die Arbeitsteilung zwischen dem Menschen und einem interaktiv genutzten Software-System führt zur Zerlegung der Arbeitsaufgabe in Sachaufgabe und Interaktionsaufgabe (vgl. Lerneinheit WAORG). Daraus folgt, daß der Mensch zwei Rollen als Aufgabenträger zur Aufgabenerfüllung übernimmt: die Rolle des Sachbearbeiters (der die Sachaufgabe durchführt) und die Rolle des Benutzers eines Software-Systems (der die Interaktionsaufgabe durchführt). Auf Grund des Zusammenhangs zwischen Sachaufgabe und Interaktionsaufgabe setzt die Erfüllung der Sachaufgabe die Erfüllung der Interaktionsaufgabe voraus. Da darüber hinaus jedes interaktiv genutzte Software-System in die Arbeitsorganisation (vgl. Lerneinheit EAORG) eingebettet sein muß, ist das Gestalten des SoftwareSystems auch Gestalten der Arbeitsorganisation. Prinzipien der Kommunikationsergonomie sind wissenschaftlich begründete Empfehlungen zum Gestalten der Interaktionsaufgabe, also Erkenntnisse der als Kommunikationsergonomie bezeichneten Wissenschaftsdisziplin. Sie wird häufig auch als Software-Ergonomie bezeichnet (was unpassend ist, weil nicht Software, sondern Kommunikation, genauer: Mensch-Computer-Kommunikation, das Objekt ergonomischer Gestaltung ist). Die Kommunikationsergonomie wird von mehreren Forschungsgebieten beeinflußt, die sich den Schwerpunkten technisch, kognitiv-psychologisch und arbeitswissenschaftlich zuordnen lassen. • Der technisch orientierte Schwerpunkt befaßt sich mit der Entwicklung der Dialogformen für die Mensch-Computer-Kommunikation (z.B. mit der direkten Manipulation); dabei werden - meist implizit - gewisse Annahmen über die Aufgaben und die Benutzer gemacht; im Mittelpunkt steht das Techniksystem. • Der kognitiv-psychologische Schwerpunkt betrachtet Mensch-Computer-Kommunikation primär unter den Bedingungen der menschlichen Wahrnehmung, des Denkens und Problemlösens sowie des Lernens. Hier steht der Mensch im Mittelpunkt. • Der arbeitswissenschaftliche Schwerpunkt sieht Mensch-Computer-Kommunikation als Teil der Arbeitsorganisation; organisierte menschliche Arbeit steht im Mittelpunkt. Das Ergebnis des Gestaltens der Interaktionsaufgabe ist der Teil des Software-Systems, der die Interaktion zwischen dem Menschen und dem Teil des SoftwareSystems ermöglicht, der die Lösung der Sachaufgabe unterstützt; er wird als Benutzeroberfläche bezeichnet. Damit kann der Zweck der Prinzipien der Kommunikationsergonomie auch so beschrieben werden: Sie unterstützen das Gestalten der Benutzeroberfläche nach ergonomischen Erkenntnissen so, daß sie weitgehend dem Problemlösungsverhalten des Menschen in seiner Rolle als Sachbearbeiter entspricht. Abbildung PKOER-1 zeigt die Architektur eines Software-Systems mit einer einheitlichen Benutzeroberfläche für die Interaktionsaufgabe bei unterschiedlichen Sachaufgaben. Für eine einheitliche Benutzeroberfläche bei unterschiedlichen Sachaufgaben sprechen folgende Argumente:

332

Methoden und Techniken der Feinprojektierung

• Vereinfachung des Gestaltens der Interaktionsaufgabe, weil die Besonderheiten unterschiedlicher Sachaufgaben nicht berücksichtigt werden müssen, vice versa; • Verwertung spezieller Fähigkeiten und Kenntnisse beim Gestalten der Interaktionsaufgabe einerseits und der Sachaufgaben andererseits; • Anwendbarkeit spezieller Erkenntnisse, die nur für das Gestalten der Interaktionsaufgabe oder nur für das Gestalten der Sachaufgaben von Bedeutung sind; • Verringerung des Entwicklungs- und Wartungsaufwands für die Benutzeroberfläche; • Zwang zu konsistenter Benutzung der Anwendungsprogramme; • Änderbarkeit der Benutzeroberfläche ohne Änderung der Anwendungsprogramme, vice versa. Damit können aus dem generellen Zweck der Prinzipien der Kommunikationsergonomie folgende Teilzwecke abgeleitet werden: Schaffung von Benutzbarkeit bezüglich der Interaktionsaufgabe (primärer Zweck) und Schaffung von Funktionalität bezüglich der Sachaufgaben (sekundärer Zweck).

Interaktionsaufgabe

Sachaufgaben

Schnittstelle

Abb. PKOER-1: Architektur eines Software-Systems mit einheitlicher Benutzeroberfläche

Gültigkeit kommunikationsergonomischer Prinzipien Aus kommunikationsergonomischen Prinzipien können grundsätzlich nur vage Gestaltungsrichtlinien abgeleitet werden, da Benutzbarkeit auf Benutzer ausgerichtet ist und es den Benutzer nicht gibt. Benutzer unterscheiden sich voneinander in ihren Kenntnissen, Fähigkeiten, Fertigkeiten und Gewohnheiten; sie unterscheiden sich auch - wenn ein Zeit räum betrachtet wird - in ihrem eigenen Verhalten (z.B. durch Ermüdung oder durch Lernen). Diese interindividuellen und intraindividuellen Unterschiede begründen die Forderung nach einem differentiell-dynamischen Gestalten der Benutzeroberfläche. Différentielles Gestalten heißt, die Unterschiede zwischen Benutzern beim Gestalten berücksichtigen; dynamisches Gestalten meint, auf unterschiedliches Verhalten jedes einzelnen Benutzers beim Gestalten eingehen. Kommunikationsergonomische Prinzipien sind auch deshalb vage, weil sie die Unterschiedlichkeit der Sachaufgaben nicht ausreichend beachten; möglicherweise gelten für unterschiedliche Sachaufgaben verschiedene Prinzipien. So ist trotz geringer Anwendungserfahrungen - erkennbar, daß für G r o u p w a r e

PKOER - Prinzipien der Kommunikationsergonomie

333

andere Prinzipien Gültigkeit haben als für Anwendungssoftware typischer "Einzelanwendungen", da sich die durch Groupware unterstützten Sachaufgaben ("kooperatives Arbeiten") grundlegend von den bei "Einzelanwendungen" typischen Sachaufgaben unterscheiden (z.B. müssen kommunikationsergonomische Prinzipien für Groupware Eigenschaften der Benutzeroberfläche fordern, welche die Kooperation zwischen den Partnern unterstützen). Aus kommunikationsergonomischen Prinzipien abgeleitete Gestaltungsrichtlinien sind nie vollständig, da sich die Techniksysteme (Hardware und Software) weiterentwickeln. Gestaltungsprinzipien können immer nur für Vorhandenes oder für zumindest Absehbares entwickelt werden. Kommunikationsergonomische Gestaltungsprinzipien geben daher nur an, wie etwas funktionieren könnte, nicht wie es funktionieren muß (nach T. Stewart). Grundlegende Voraussetzung für die praktische Durchsetzung der Prinzipien der Kommunikationsergonomie ist ein evolutionäres, prototyping-orientiertes Vorgehensmodell (vgl. Lerneinheiten PROSP und PROTY). Grundsätze der DIN 66234 Teil 8 Die in dieser Norm genannten Grundsätze wurden auf Grund der Ergebnisse einer schriftlichen Befragung von Software-Entwicklern formuliert (594 Befragte, Rücklaufquote 39%, Befragungszeitraum 1978). Die Befragten sollten 100 Systemeigenschaften bezüglich ihrer Relevanz für die Benutzbarkeit auf einer siebenstufigen Skala einschätzen. Benutzer wurden nicht befragt. Experimente zur Validierung der Befragungsergebnisse wurden nicht durchgeführt. Die Befragungsergebnisse wurden mit einer Faktorenanalyse ausgewertet. Dabei wurden sieben Faktoren extrahiert, die zusammen nur 43% der Varianz der Ergebnisse erklären. Die Grundsätze beschränken sich auf die Dialoggestaltung und sind als relativ allgemein formulierte Richtlinien, die durch Beispiele veranschaulicht werden, zu verstehen. Theoretische Grundlagen werden nicht vermittelt; weiterführende Literatur wird nicht angegeben. Ausdrücklich wird festgestellt, daß es nicht möglich ist, die Erfüllung der Grundsätze zu überprüfen, da es ein geeignetes Uberprüfungsverfahren nicht gibt. Die fünf Grundsätze der Dialoggestaltung nach DIN 66234 Teil 8 sind: Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität und Fehlerrobustheit. (Die nachfolgend mit " " gekennzeichneten Sätze sind der Norm wörtlich entnommen.) Grundsatz der Aufgabenangemessenheit. "Ein Dialog ist aufgabenangemessen, wenn er die Erledigung der Arbeitsaufgabe des Benutzers unterstützt, ohne ihn durch die Eigenschaften des Dialogsystems unnötig zu belasten. Tätigkeiten, die sich aus der technischen Eigenart des Dialogsystems ergeben, sollen im allgemeinen durch das System selbst ausgeführt werden. Der Dialog soll den Arbeitsaufgaben angepaßt sein. Bei der Dialoggestaltung sind insbesondere deren Komplexität sowie Art und Umfang der Information, die der Benutzer zu verarbeiten hat, zu berücksichtigen." Grundsatz der Selbstbeschreibungsfähigkeit. "Ein Dialog ist selbstbeschreibungsfähig, wenn dem Benutzer auf Verlangen Einsatzzweck und Lei-

334

Methoden und Techniken der Feinprojektierung

stungsumfang des Dialogsystems erläutert werden können, und wenn jeder einzelne Dialogschritt unmittelbar verständlich ist, oder der Benutzer auf Verlangen zu jedem Dialogschritt Erläuterungen erhalten kann. In Ergänzung zur Benutzerschulung sollen diese Erläuterungen dazu beitragen, daß sich der Benutzer für das Verständnis und für die Erledigung der Arbeitsaufgabe zweckmäßige Vorstellungen von den Systemzusammenhängen machen kann, z.B. über Umfang, Aufgaben, Aufbau und Steuerbarkeit des Dialogsystems, ... über Umgang mit Fehlermeldungen. Erläuterungen sollen an die allgemein üblichen Kenntnisse der zu erwartenden Benutzer angepaßt sein.... Beschreibungen sollen situationsabhängig gegeben werden, um ihren Wert für den Benutzer zu erhöhen." Grundsatz der Steuerbarkeit. "Ein Dialog ist steuerbar, wenn der Benutzer die Geschwindigkeit des Ablaufs sowie die Auswahl und Reihenfolge von Arbeitsmitteln oder Art und Umfang von Ein- und Ausgaben beeinflussen kann. Der Benutzer soll die Geschwindigkeit des Dialogs an seine individuelle Arbeitsgeschwindigkeit anpassen können... Die Eingabetätigkeit des Benutzers soll nicht durch unnötiges Warten auf die Ausgabe von Daten vorangegangener Dialogschritte aufgehalten werden. Soweit es die Arbeitsaufgabe erlaubt, soll der Benutzer während des Dialogs die Arbeitsmittel frei wählen und den Arbeitsweg selbst bestimmen können. Der Benutzer soll den Dialog jederzeit unterbrechen können, soweit es die Arbeitsaufgabe zuläßt. Nach einer Unterbrechung soll er ... entscheiden können, ob der Dialog an der Unterbrechungsstelle fortgeführt werden soll. Ist der Dialog wegen eines Systemausfalls unterbrochen worden, so ist ein Wiederaufnahmepunkt definiert durch den letzten Dialogschritt vor dem Systemausfall; es kann zweckmäßig sein, eine Wiederaufnahme zu einem weiter zurückliegenden Dialogschritt festzulegen Der Benutzer soll in für ihn leicht überschaubaren Dialogschritten vorgehen können; eine Zusammenfassung von Dialogschritten sollte dem Benutzer ermöglicht werden, wenn es von der Arbeitsaufgabe her sinnvoll ist." Grundsatz der Erwartungskonformität. "Ein Dialog ist erwartungskonform, wenn er den Erwartungen der Benutzer entspricht, die sie aus Erfahrungen mit bisherigen Arbeitsabläufen oder aus der Benutzerschulung mitbringen, sowie den Erfahrungen, die sie sich während der Benutzung des Dialogsystems und im Umgang mit dem Benutzerhandbuch bilden. Das Dialogverhalten innerhalb eines Dialogsystems soll einheitlich sein. ... Bei ähnlichen Arbeitsaufgaben soll der Dialog ähnlich gestaltet sein, damit er den Erwartungen des Benutzers hinsichtlich des gewohnten Arbeitsablaufs gerecht wird. Der Benutzer soll Erwartungen hinsichtlich seines Arbeitsablaufs auf Grund der Rückmeldungen des Dialogsystems bilden können. Die für die Führung des Dialogs relevanten Zustandsänderungen des Systems sind dem Benutzer mitzuteilen. ... Eingegebene Zeichen sollen im allgemeinen unmittelbar auf dem Bildschirm angezeigt werden, um die für die Eingabe erforderliche Aufmerksamkeit nicht durch verzögerte Ausgabe zu belasten. Ebenso sollen Positionierungen ... unmittelbar erfolgen. ... Wird der Dialog aus technischen Gründen unterbrochen, sollen dem Benutzer soweit wie möglich Art, Umfang und Dauer des Ausfalls mitgeteilt werden." Grundsatz der Fehlerrobustheit. "Ein Dialog ist fehlerrobust, wenn trotz erkennbar fehlerhafter Eingaben das beabsichtigte Arbeitsergebnis mit minimalem

PKOER - Prinzipien der Kommunikationsergonomie

335

oder ohne Korrekturaufwand erreicht wird. Dazu müssen dem Benutzer die Fehler zum Zwecke der Behebung verständlich gemacht werden. Eingaben des Benutzers dürfen nicht zu Undefinierten Systemzuständen oder zu Systemzusammenbrüchen führen. ... Wenn ein Fehler auf verschiedene Weise vom System behoben werden kann, sollten dem Benutzer Korrekturalternativen zur Auswahl angeboten werden, ohne die Möglichkeit zur Neueingabe auszuschließen. ... Wenn es der Arbeitsprozeß erlaubt, dürfen auf Anforderung des Benutzers Fehlermeldungen später ausgegeben werden, um seinen Denkprozeß nicht unnötig zu stören. Fehlermeldungen sind verständlich, sachlich und konstruktiv zu formulieren. Sie sollten einheitlich strukturiert werden ... Fehlermeldungen dürfen keine Werturteile enthalten. ... Der Benutzer sollte zwischen kurzen und umfangreichen Erläuterungen wählen können. Es kann zweckmäßig sein, die Erläuterungen mit einem Hinweis auf eine Stelle im Benutzerhandbuch zu versehen." Die ISO 9241 Part 10 orientiert sich stark an DIN 66234; teilweise wurden die DIN-Formulierungen ins Englische übersetzt. ISO 9241 kennt jedoch zwei weitere Grundsätze, nämlich Erlernbarkeit (learnability) und Individualisierbarkeit (individualization). Beide standen in der langjährigen DIN-Normungsdebatte zur Diskussion, wurden aber schließlich verworfen (vor allem deshalb, weil die Meinung vorherrschte, sie seien durch die anderen Grundsätze bereits abgedeckt, stellen also eine Art "übergeordneter Grundsatz" dar). Erlernbarkeit meint, daß das Dialogsystem den Benutzer durch verschiedene Lernstufen führt, um den Lernaufwand zu minimieren ("learning should be understood as a graceful evolution of increasing skill and knowledge ..."). Individualisierbarkeit meint, daß allen Benutzern die Möglichkeit geboten wird, die Benutzeroberfläche ihren persönlichen Bedürfnissen - in Abhängigkeit von einer bestimmten Arbeitsaufgabe anzupassen ("user's individual needs and skills for a given task"). Die gleichzeitige Verfolgung der Grundsätze führt in der Regel zu Konflikten. So haben Maßnahmen zur Verbesserung der Steuerbarkeit zumeist negative Auswirkungen auf die Selbstbeschreibungsfähigkeit, denn je mehr ein Benutzer das System seinen Bedürfnissen anpassen kann, umso uneinheitlicher und unübersichtlicher wird es. Einige Konflikte lassen sich durch geeignete Maßnahmen vermeiden oder zumindest verringern (z.B. durch ausgefeilte Hilfe-Systeme, die sowohl einen "Laien-Modus" als auch einen "Experten-Modus" zulassen). Abgesehen von dieser grundsätzlichen Feststellung bezüglich der Konflikte ist darauf hinzuweisen, daß viele Konflikte nur in Abhängigkeit von bestimmten Benutzern und/oder bestimmen Sachaufgaben entstehen. Dies weist auf die Notwendigkeit hin, die Konfliktsituation in jedem IuK-Projekt zu erheben und zu analysieren und die Dialoggestaltung an den Analyseergebnissen auszurichten. Entwurfsrichtlinien Die Gestaltung und die Bewertung von Benutzeroberflächen können auch anhand von Entwurfsrichtlinien erfolgen. Entwurfsrichtlinien enthalten allgemein formulierte Empfehlungen mit Beispielen, Erläuterungen und Referenzen. Sie haben eine geringere Allgemeingültigkeit als die Grundsätze, die in Normen niedergelegt sind. Die Macintosh User Interface Guidelines (Apple Computer, 1985), die Common User Access (IBM, 1989) und die Entwurfsrichtlinien von SNI (Sie-

336

Methoden und Techniken der Feinprojektierung

mens/Nixdorf 1990) sind Beispiele für Entwurfsrichtlinien. Sie bauen auf bestimmten Prinzipien auf (z.B. denen der direkten Manipulation) und sind stark durch empirische Befunde geprägt. Prinzipien der Gestaltpsychologie Visuelle Objekte werden vom Menschen nicht als eine Menge von Einzelobjekten wahrgenommen, sondern nach bestimmten Prinzipien wahrnehmungsmäßig zu Figuren zusammengesetzt erlebt ("Gestaltgesetze"). Den Figuren ist gemeinsam, daß - unter Ausnutzung der strukturell informationstragenden Figurenelemente redundante Figuren weggelassen werden können. Die informationstragenden Figurenelemente bestimmen das Objekt soweit, daß ihre Aufnahme durch den Menschen genügt, damit er sich ein vollständiges Bild von dem Objekt machen kann (in Abbildung PKOER-2 genügen z.B. die schwarzen Kreise zum Erkennen der Figur). Dies setzt allerdings voraus, daß sich die Figur deutlich vom Hintergrund abhebt und nicht zu komplex ist. "Figurenelemente" sind nicht nur grafische Symbole, sondern können auch Zeichenfolgen sein. Die wichtigsten Gestaltgesetze betreffen die Nähe, die Symmetrie und die Gleichartigkeit der Figurenelemente. • Gestaltgesetz der Nähe: Figurenelemente, die nahe beisammen angeordnet sind, werden als zu einem Block gehörig empfunden (Bild a in Abbildung PKOER-2); zusammengehörige Informationen sollen daher nahe beieinander angeordnet werden. • Gestaltgesetz der Nähe und der Symmetrie: Die Blockbildung wird durch symmetrisch angeordnete Figurenelemente verstärkt (Bild b in Abbildung PKOER-2); zusammengehörige Informationen sollen daher nahe beieinander und symmetrisch angeordnet werden. Dazu sind horizontale und vertikale Strukturelemente - wie Zeilen und Spalten einer Tabelle - gut geeignet. • Gestaltgesetz der Nähe, der Symmetrie und der Gleichartigkeit: Die symmetrischen Blöcke bilden durch die Anordnung gleichartiger Figurenelemente "prägnante Figuren" (Bild c in Abbildung PKOER-2); gleichartige Informationen sollen daher nahe beieinander und symmetrisch angeordnet werden.

° •*v n °

o # ® o • o • 0®

a

o o o o o o o o o

i ° o o o o

o

b

O

•

•

c

Abb. PKOER-2: Gesetze der Gestaltpsychologie

Die Anwendung der Gestaltgesetze bei der Dialoggestaltung (z.B. beim Gestalten von Masken und Menüs) führt zu übersichtlichen, gut strukturierten Benutzeroberflächen, deren Informationen vom Menschen leicht aufgenommen werden

PKOER - Prinzipien der Kommunikationsergonomie

337

können. Zusammengehörige Informationen sollen nahe beieinander liegen und eine symmetrische Figur bilden; innerhalb einer symmetrischen Figur sollen möglichst ähnliche Informationen angeordnet werden. Deshalb werden in einem Pull-down-Menü gleichartige Kommandos untereinander angeordnet und durch Leerzeile und Trennstrich zusammengefaßt (zur Anwendung der Gestaltgesetze bei der Maskentechnik vgl. das Demonstrationsbeispiel in Lerneinheit EAORG). Gestaltungskriterien für Hilfe-Systeme Auch bei selbstbeschreibungsfähigen Benutzeroberflächen kann der Benutzer in eine Situation kommen, in der er zur Fortführung des Dialogs Hilfe benötigt; diese soll ihm vom Software-System zur Verfügung gestellt werden ("Hilfe-System"). Je nach Konzeption des Hilfe-Systems kann dem Benutzer die Hilfe auf unterschiedliche Weise gegeben werden; Abbildung PKOER-3 zeigt eine Systematik von Hilfe-Systemen. Art der Hilfe

Erläuterung

Passive Hilfe

Der Benutzer fordert Hilfe-Information vom Hilfe-System ausdrücklich an (z.B. über ein Schlüsselwort), wenn er das Bedürfnis nach Hilfe hat. Das Hilfe-System erkennt das Bedürfnis des Benutzers nach Hilfe (z.B. wenn er einen Fehler macht), greift in den Dialog ein und bietet Hilfe-Information an. Das Hilfe-System berücksichtigt den aktuellen Stand der Interaktion nicht und erklärt durch Hilfe-Information nur feste Strukturen im Programm (so wie ein Handbuch). Das Hilfe-System berücksichtigt den aktuellen Stand der Interaktion und leitet Hilfe-Information aus dem Verhalten des Benutzers ab. Das Hilfe-System erzeugt für jeden Benutzer die gleiche Hilfe-Information. Das Hilfe-System erzeugt Hilfe-Information, die auf das Verhalten des einzelnen Benutzers oder zumindest auf das Verhalten von Benutzertypen abgestimmt ist.

Aktive Hilfe Statische Hilfe Dynamische Hilfe Gleichförmige Hilfe Individuelle Hilfe

Abb. PKOER-3: Systematik von Hilfe-Systemen (nach Bauer/Schwab)

Ein Hilfe-System soll die Eigenschaften aktiv, dynamisch und individuell haben, eine Forderung, die sich nur mit einem wissensbasierten Hilfe-System umfassend erfüllen läßt (zur Wissensbasierung vgl. Lerneinheit SWISS). Die Hilfe-Funktion soll nicht nur über den Bildschirm (z.B. aus einem Menü), sondern auch direkt über die Tastatur (z.B. über eine beschriftete Funktionstaste HILFE) angefordert werden können, damit sie jederzeit verfügbar ist. Hilfe-Information soll am Bildschirm in Fenstern angezeigt werden, sodaß die Ursache für die Hilfe-Anforderung sichtbar bleibt. Die Hilfe-Information soll verständlich und widerspruchsfrei formuliert sein. Zweckmäßig ist ein hierarchischer Aufbau des HilfeSystems, sodaß - je nach Benutzertyp und Arbeitssituation - Hilfe-Information mit unterschiedlichem Detaillierungsgrad angeboten werden kann.

338

Methoden und Techniken der Feinprojektierung

Demonstrationsbeispiel

XX XX

X

X

X

X

X

X

X X X

X X

X X

X

X

X

X

X

X

X X

X X

X

Fehlerrobustheit

XX XX X

Steuerbarkeit

XX

X

X

Datenträgerverwaltung: - Formatieren unformatierter Disketten - Wiedererkennen von Disketten - automatische Datenorganisation auf dem Speichermedium/ aussagefahige Inhaltsverzeichnisse - automatische Rückspeicherung von Texten - automatisches Laden von zugehörigen Anwendungsprogrammen bei Aufruf eines Dokuments Schutz vor unbeabsichtigtem Löschen: - Anforderung einer Löschbestätigung vor dem Löschen großer Dateien - Default-Insert-Modus zum Schutz vor versehentlichem Überschreiben von Text Antwortzeiten/Verarbeitungszeiten: - benutzergerechte Antwortzeiten - erwartungskonforme Verarbeitungszeiten - Drucken im Hintergrund Zeilenumbruch/Umformatieren von Seiten: - automatischer Zeilenumbruch - automatischer Seitenumbruch (auch während und nach Einfügeoperationen) Ausgewählte DV-spezifische Funktionen: zeichen-, wort-, Zeilen-, paragraph- und seitenweise Bewegungen der Schreibmarke zeichen, -wort-, satz-, paragraphweises Markieren von Texten Eingabe von Suchbegriffen durch Zeigen auf Buchstabenkombinationen im Text

Erwartungskonformität

^^

XX

^

XX

Kriterien zum Gestalten und Bewerten der Selbstverwaltung

X

— G r u n d s ä t z e nach DIN 66234

Aufgabenangemessenheit Selbstbeschreibungsfähigkeit

Gierlach/Jankowski zeigen am Beispiel der Textverarbeitung die Notwendigkeit der Präzisierung der Grundsätze der DIN 66234 Teil 8. Sie analysieren dazu die Merkmale von Textverarbeitungssystemen und deren ergonomische Auswirkungen, leiten Kriterien zum Gestalten bzw. zum Bewerten ab und ordnen diese den DIN-Grundsätzen zu. Abbildung PKOER-4 zeigt die Kriterien zum Gestalten und Bewerten der Selbstverwaltung des Systems (in den Zeilen) und die DINGrundsätze (in den Spalten); die Elemente der Matrix machen Aussagen darüber, welche DIN-Grundsätze durch welche Kriterien präzisiert werden können.

X

Abb. PKOER-4: Präzisierung der DIN-Grundsätze am Beispiel Textverarbeitung (Quelle: Gierlach/Jankowski)

X X

PKOER - Prinzipien der Kommunikationsergonomie

339

Forschungsbefunde Nielsen/Molich (zitiert nach Wandmacher) schlagen eine als "heuristische Evaluation" bezeichnete Methode zur Bestimmung der Benutzbarkeit anhand von Merkmalen der Benutzeroberfläche vor. Dabei versuchen Beurteiler durch "nicht-analytische Anschauung", ohne systematisches Anwenden von Kriterien, die für die Benutzbarkeit kritischen Eigenschaften von Benutzeroberflächen ("Schwachstellen") zu entdecken. Empirische Tests von sechs Benutzeroberflächen zeigten, daß drei Beurteiler zusammen im Durchschnitt 71% der als schwerwiegend und 59% der als leichter eingestuften Schwachstellen entdeckten. Für einen Beurteiler allein lagen die Werte bei 42% bzw. 32%. Jeffries et al. verglichen die heuristische Evaluation mit anderen Methoden (Beurteilung anhand von Entwurfsrichtlinien, Modellierung der Aufgabenbearbeitung, Erhebung von Leistungsdaten bei der Benutzung). Mit der heuristischen Evaluation entdeckten die vier Beurteiler die meisten für die Benutzbarkeit kritischen Eigenschaften der Benutzeroberflächen. Auch das Verhältnis von Aufwand (insbes. Beurteilungszeit) und Ertrag (gemessen als Anzahl der entdeckten Schwachstellen) war bei dieser Methode am günstigsten. Aufgabenverweise Entwickeln der Arbeitsorganisation (Lerneinheit EAORG); Entwickeln des Methodensystems (Lerneinheit EMESY). Kontrollfragen 1. Welchem Zweck dienen die Prinzipien der Kommunikationsergonomie? 2. Warum wird eine einheitliche Benutzeroberfläche für unterschiedliche Anwendungsprogramme gefordert? 3. Welche Prinzipien der Kommunikationsergonomie sind in DIN 66234 Teil 8 definiert? 4. Welche Bedeutung haben die Gestaltgesetze für das Gestalten der Benutzeroberfläche? 5. Nach welchen Gesichtspunkten können Hilfe-Systeme systematisiert werden? Quellenliteratur Ackermann, A.: Empirie des Softwareentwurfs: Richtlinien und Methoden. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988, 253 - 276 Gierlach, D. und Jankowski, R.: Operationalisierung der Grundsätze ergonomischer Dialoggestaltung nach DIN 66234 Teil 8 - Beispiel Textverarbeitung. In: Angewandte Informatik 5/ 1989, 189-196 Koch, M. et al.: Software-Ergonomie. Gestaltung von EDV-Systemen - Kriterien, Methoden und Werkzeuge. Springer Verlag, Wien/New York 1991 Maaß, S.: Software-Ergonomie - Benutzer- und aufgabenorientierte Systemgestaltung. In: Informatik Spektrum 4/1993, 191 - 205 Meinhard, A. und Lorenz, V.: Unterstützung des Benutzers durch Hilfesysteme. In: Angewandte Informatik 11/1986,475 - 479 Streitz, N. A.: Fragestellungen und Forschungsstrategien der Software-Ergonomie. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/ New York 1988, 3 - 24 Wandmacher, J.: Software-Ergonomie. Verlag de Gruyter, Berlin et al. 1993

340

Methoden und Techniken der Feinprojektierung

Vertiefungsliteratur Ackermann, D. und Ulich, E. (Hrsg.): Software-Ergonomie '91. Benutzerorientierte SoftwareEntwicklung. Verlag Teubner, Stuttgart 1991 Apple Computer (Ed.): Human Interface Guidelines - The Apple Desktop Interface. AddisonWesley Publ. Company, Reading/MA. et al. 1988 Balzert, H. et al.: Fenstersysteme im Vergleich - Architektur, Leistungsfähigkeit und Eignung für die Anwendungsentwicklung. In: Bullinger, H.-J. (Hrsg.): Software-Ergonomie '85. MenschComputer-Interaktion. Verlag Teubner, Stuttgart 1985,42 - 52 Bauer, J. and Schwab, Th.: Propositions on Help-Systems. In: Angewandte Informatik 1/1987, 23-29 Fischer, G.: Kognitionswissenschaft - Ein Bindeglied zwischen Informatik und Psychologie. In: Schauer, H.: und Tauber, M. J. (Hrsg.): Informatik und Psychologie. Oldenbourg Verlag, München/Wien 1982, 169 - 193 Metzger, W.: Gesetze des Sehens. Verlag Kramer, Frankfurt/M. 1975 Oppermann, R. und Reiterer, H.: Evaluation von Benutzerschnittstellen. In: WKISCHAFTSINFCRMAIIK 3/1992, 283 - 293 Rock, I.: Wahrnehmung. Vom visuellen Reiz zum Sehen und Erkennen. Verlag Spektrum der Wissenschaft, Heidelberg o.J. Normen DIN 66234 Teil 8: Bildschirmarbeitsplätze. Grundsätze ergonomischer Dialoggestaltung. ISO 9241 Part 10: Ergonomie Dialogue Design Criteria. Version 3, Committee Draft, Dec. 1990

KRYPT - Kryptographische Verschlüsselungsmethoden Lernziele Sie kennen die Vorgehensweise bei der Verschlüsselung von Klartext durch kryptographische Methoden. Sie kennen Vertauschung und Substitution sowie die Vorgehensweise der Verschlüsselung bei kombinierten Verschlüsselungssystemen. Sie können das Problem der Verlagerung des Schutzes von den Daten auf den Schutz der Schlüssel einschätzen und von dort her den Ansatz der PublicKey-Systeme beurteilen. Sie erkennen die Besonderheit der Wirkungsweise kryptographischer Verschlüsselung gegenüber anderen Sicherungsmaßnahmen. Definitionen und Abkürzungen Algorithmus (algorithm) = ein Lösungsverfahren für eine Klasse gleichartiger Aufgaben, bestehend aus einer eindeutigen, endlichen Folge von Operationen. DEA = Akronym für Data Encryption Algorithm. DES = Akronym für Data Encryption Standard, entwickelt von C. Meyer. Entschlüsselung (deciphering) = das Überführen eines Schlüsseltexts in den Klartext; der zur Verschlüsselung inverse Vorgang. Häufigkeit (frequency) = die Anzahl der Fälle je Bezugsgröße, in denen ein bestimmtes Merkmal beobachtet werden kann (z.B. die Anzahl der gleichen Buchstaben des verwendeten Alphabets in einem Text). Klartext (clear text) = die unverschlüsselten Daten, Texte usw., die durch kryptographische Verschlüsselung in einen Schlüsseltext überführt werden. Kryptoanalyse (crypto analysis) = die Lehre (die Wissenschaft) von der unbefugten Entschlüsselung, deren Zweck nicht die Anleitung zum Mißbrauch, sondern die Entdeckung von Schwachstellen der Verschlüsselung ist. Kryptographie (cryptography) = die Lehre (die Wissenschaft) des Erstellens von Geheimbotschaften, insbesondere der dafür verwendeten Methoden. Kryptologie (cryptology) = die Kryptographie und die Kryptoanalyse. Kryptosystem (crypto system) = Abkürzung für kryptographisches Verschlüsselungssystem. NBS = Akronym für National Bureau of Standards. RSA = Akronym für das 1977 entwickelte Public-Key-System, benannt nach den Anfangsbuchstaben der Zunamen der Entwickler Rivest, Shamir und Adleman. Schlüssel (key) = eine Variable zur Bildung und zur Auswahl von Verschlüsselungsschritten in einem Verschlüsselungssystem. Synonym: Chiffrierschlüssel. Schlüsselraum (key domain) = die Anzahl der theoretisch möglichen Schlüssel bei gegebenem Schlüsseltext und bekanntem Algorithmus. Schlüsseltext (cipher text) = die aussagelosen Daten, Texte usw., die durch kryptographische Verschlüsselung erzeugt werden. Synonyme: Geheimtext, Geheimbotschaft. Substitution (substitution) = das Ersetzen von Zeichen durch andere Zeichen. Verschlüsselung (encryption, ciphering) = das Überführen eines Klartexts in einen Schlüsseltext. Verschlüsselungsalgorithmus (cipher algorithm) = ein Algorithmus zur Transformation von Klartext in Schlüsseltext und umgekehrt.

342

Methoden und Techniken der Feinprojektierung

Zweck der kryptographischen Verschlüsselung Klartexte sollen so verschlüsselt werden, daß der für die unbefugte Entschlüsselung erforderliche Aufwand größer ist als der Nutzen der Information, den Unbefugte aus der Entschlüsselung ziehen können. Zur Lösung dieser Aufgabe werden kryptographische Verschlüsselungssysteme verwendet. Gegenstand der Verschlüsselung sind Klartexte, die auf Speichern liegen und/oder auf Netzen transportiert werden. Die für die Anwendung entscheidende Besonderheit der kryptographischen Verschlüsselung liegt darin, daß sie eine Sicherungsmaßnahme ist, die auch in einer unsicheren Anwendungsumgebung wirksam ist. Dies heißt folgendes: Auch wenn Sicherungsmaßnahmen einer äußeren Sicherungsschale durchbrochen oder umgangen werden (z.B. durch einen erfolgreichen Intrusionsversuch, der zum Entwenden des Speichermediums führt), bleibt der Schutz der verschlüsselten Datenbestände voll aufrecht. Kryptologie kann daher auch als die Lehre (die Wissenschaft) von der Datensicherheit in einer unsicheren Umgebung aufgefaßt werden. Verarbeitungssysteme und Netze, die sich mit organisatorischen und physischen Sicherungsmaßnahmen nicht ausreichend schützen lassen, können durch kryptographische Verschlüsselung gesichert werden. Grundmodell der kryptographischen Verschlüsselung Komponenten eines Verschlüsselungssystems sind ein Algorithmus ("Verschlüsselungsverfahren") und ein Schlüssel ("Parameter des Verschlüsselungsverfahrens"), die in bestimmter Form definiert und in Verbindung mit einander eingesetzt werden. Im allgemeinen werden ein relativ kurzer Schlüssel (etwa 8 Byte) und ein extrem komplexer Algorithmus verwendet. Ein kurzer Schlüssel ist zweckmäßig, weil er sich gut merken läßt (er braucht i.a. nicht notiert zu werden) und weil seine Übermittlung einfach ist. Abbildung KRYPT-1 zeigt das Grundmodell kryptographischer Verschlüsselung.

Abb. KRYPT-1: Grundmodell kryptographischer Verschlüsselung (Quelle: nach IBM)

Bei der Beurteilung der Sicherheit der Verschlüsselung soll davon ausgegangen werden, daß ein Angreifer das Verschlüsselungsverfahren kennt, nicht aber den

KRYPT - Kryptographische Verschlüsselungsmethoden

343

Schlüssel. Eine Verschlüsselung, deren Wirksamkeit auf die Geheimhaltung des Algorithmus angewiesen ist, hat erhebliche Mängel (z.B. weil sie von vielen Teilnehmern in einem Netz verwendet wird, weil sie erraten werden kann und weil sie zumindest der Entwickler kennt). Wird das Verschlüsselungsverfahren bekannt und muß es daher gewechselt werden, sind davon viele Anwender betroffen; der Wechsel ist aufwendig. Der Schlüssel wird dagegen zufällig gewählt; er kann ohne großen Aufwand verändert werden. Jedes Verschlüsselungsverfahren verwendet ein Alphabet, in dem Klartexte und Schlüsseltexte abgefaßt werden (z.B. die 26 Buchstaben des gewöhnlichen Alphabets, wobei zwischen Groß- und Kleinschreibung nicht unterschieden wird, oder die 256 Bytes von hexadezimal 00 bis FF bei binär gespeicherten Daten). Bei der monoalphabetischen Verschlüsselung wird ein Buchstabe des Klartextes stets auf den gleichen Buchstaben des Schlüsseltextes abgebildet. Eine Variante ist das Verschlüsseln von Buchstabenpaaren. Bei der polyalphabetischen Verschlüsselung wird ein Buchstabe des Klartextes nicht stets auf den gleichen Buchstaben des Schlüsseltextes abgebildet. Dadurch kann die Häufigkeit der einzelnen Buchstaben so verschleiert werden, daß die gängige Attacke der Häufigkeitsanalyse wirkungslos bleibt. Vertauschung und Substitution Vertauschung und Substitution sind die Grundformen der verwendeten Algorithmen. Bei der Vertauschung werden Zeichen anders angeordnet, ohne daß ihre Identität verändert wird (z.B. wird aus CRYPTOGRAM die Buchstabenfolge RCPYOTGRMA). Zur Vertauschung können Schlüssel verwendet werden. Bei der Substitution werden Buchstaben des Klartextes durch andere Buchstaben ersetzt; sie erfordert die Verwendung eines Schlüssels. Abbildung KRYPT-2 zeigt die Substitution an einem sehr einfachen Beispiel. Der Algorithmus besteht darin, jeden Buchstaben des Klartextes durch den Buchstaben zu ersetzen, der sich durch ein vom Schlüssel gesteuertes Verschieben im Alphabet ergibt (z.B. wird der erste Klartextbuchstabe um 8 Stellen, der zweite um 1 Stelle und der dritte um 13 Stellen verschoben; beim vierten wird wieder von vorn begonnen). AB C D E F G H I

JKLMNOPQRSTUVWXYZ

I I JKLMNOPQRS TUVWXYZABCDEFGH B BCDEFGHIJKLMNOPQRSTUVWXYZA M MNOPQRS TUVWXYZABCDEFGH I JKL Klartext Schlüssel Verschlüsselter Text

CRYPTOGRAM I BMI BMI BMI KSKXUAOSMU

Abb. KRYPT-2: Verschlüsselung durch Substitution (Quelle: nach IBM)

Das Beispiel zeigt auch, daß die Mächtigkeit des Schlüsselraums gering ist, wenn der Schlüssel kurz ist. Wird das verwendete Alphabet durch die Zahlen 0 bis 25 dargestellt, so ist der Algorithmus die Addition von Klartext und zyklisch wiederholtem Schlüssel modulo 26.

344

Methoden und Techniken der Feinprojektierung

Verschlüsselungssysteme nutzen meist eine Kombination von Vertauschung und Substitution ("kombinierte Verschlüsselungssysteme"). Kombinierte Verschlüsselungssysteme wenden z.B. folgende Verfahrensschritte an: Zunächst wird jedes Zeichen des Klartexts mittels Substitution durch ein oder zwei andere Zeichen ersetzt. Anschließend wird zusätzlich durch Vertauschung verschlüsselt. Komplexe Algorithmen bestehen aus mehreren Substitutionen und Vertauschungen. Vorgehensweise bei kombinierten Verschlüsselungssystemen Zunächst wird eine zweidimensionale, quadratische Matrix A = (m,m) eingeführt. m wird so dimensioniert, daß m x m mindestens gleich der Mächtigkeit des Zeichenvorrats ist, aus dem Klartexte formuliert werden (z.B. ist bei 36 Buchstaben und Ziffern m mindestens 6). Alle Zeichen des Zeichenvorrats werden beliebig in die Felder von A eingeordnet. Die Zeilen und die Spalten von A werden mit beliebigen (unterschiedlichen) Zeichen des verwendeten Zeichenvorrats belegt. Für jedes Zeichen des Klartexts erfolgt die Verschlüsselung in drei Schritten (vgl. dazu auch das Demonstrationsbeispiel): • Erster Schritt: Aufsuchen des Zeichens in A und Entnehmen der zugeordneten Zeilen- und Spaltenbezeichnung; jedes Zeichen wird also durch zwei Zeichen substituiert. • Zweiter Schritt: Anordnen der Substitutionsergebnisse zeilenweise in einer Zeilenlänge, die gleich ist der Anzahl der Zeichen des Schlüssels. • Dritter Schritt: Verändern des Zwischenergebnisses aus dem zweiten Schritt durch Vertauschung und unter Verwendung des Schlüssels. Zur Entschlüsselung müssen also die Matrix A und der Schlüssel bekannt sein. Schlüsselsysteme Zur Erhöhung der Sicherheit werden mehrere verschiedene Schlüssel verwendet, die häufig ausgewechselt werden (sog. Hierarchie von Schlüsseln mit unterschiedlicher Geltungsdauer). Alle Schlüssel werden selbst wieder verschlüsselt. Sensitive Schlüssel (im Klartext) und der Algorithmus sind in einer nicht zugänglichen, nur über elektronische Signalleitungen gesteuerten Krypto-Hardware-Einheit, alle übrigen Schlüssel sind verschlüsselt im Datensystem gespeichert. Es werden also zwei Arten von Schlüsseln unterschieden: • Schlüssel zur Verschlüsselung/Entschlüsselung von Daten (datenchiffrierende Schlüssel); • Schlüssel zur Verschlüsselung/Entschlüsselung von Schlüsseln (schlüsselchiffrierende Schlüssel); diese werden in Primärschlüssel (schützen Datenschlüssel in einem Knoten) und Sekundärschlüssel (schützen Datenschlüssel bei Verlassen eines Knotens) unterteilt. Durch diese Abgrenzung wird eine größere Resistenz der Schlüssel gegenüber Schlüsselangriffen erreicht. Kryptographische Verschlüsselungssysteme können auf drei Systemebenen implementiert werden:

KRYPT - Kryptographische Verschlüsselungsmethoden

345

• Leitungsverschlüsselung: Die Daten werden im Transportsystem verschlüsselt und entschlüsselt. • Private Verschlüsselung: Die Verschlüsselung wird in jedem Einzelfall vom Benutzer gesteuert. • Ende-zu-Ende-Verschlüsselung: Die Daten werden bei ihrer Entstehung beim Sender verschlüsselt und beim Empfänger entschlüsselt. Nur die Ende-zu-Ende-Verschlüsselung umfaßt das Informationssystem als Ganzes, sie wird daher auch als integrierte Verschlüsselung bezeichnet. Data Encryption Standard Der DES wurde zwischen 1968 und 1975 von C. Meyer bei IBM entwickelt und 1977 vom NBS und 1981 von der ANSI unter der Bezeichnung DEA genormt. Der DES arbeitet mit einem 64-Bit-Schlüssel (davon 8 Prüfbits). Verschlüsselt werden 64-Bit-Blöcke. Kürzere Klartexte können aufgefüllt werden (am besten mit zufälligen Zeichen). Längere Klartexte werden "zerhackt"; der letzte Block wird gegebenenfalls wieder aufgefüllt. Es wird ein komplexer mathematischer Algorithmus verwendet. Die Norm verlangt die Hardware-Implementierung des Algorithmus. Jeweils 8 Byte Klartext werden unabhängig voneinander verarbeitet (sog. Blockverschlüsselung). Bei der Blockchiffre mit Blockverkettung wird der Eingabedatenblock mit dem Ausgabedatenblock des zuletzt behandelten Blocks logisch verknüpft (z.B. mit XOR-Funktion) und dann erst dem Algorithmus (jeweils 8 Byte Eingabedaten) unterworfen. Der verschlüsselte Text wird damit gegenüber Häufigkeitsanalysen wesentlich unempfindlicher. Vorteile des DES sind seine große Sicherheit (es ist bisher noch nicht gelungen, sie in Frage zu stellen) und seine hohe Geschwindigkeit. Handelsübliche DESChips verschlüsseln etwa 500 Kbit/Sek.; die höchste bekannte Geschwindigkeit sind 200 Mbit/Sek. Kritisch ist der kleine Schlüsselraum; es gibt nur 256 verschiedene Schlüssel. Das systematische Austesten des Schlüsselraums ist mit schnellen Parallelrechnern theoretsich möglich. Diffie/Hellman haben 1977 ausgerechnet, daß ein Parallelrechner mit 106 Prozessoren, von denen jeder pro Sekunde 106 Schlüssel ausprobiert, Kosten von rd. US$ 50 Mill. verursachen und etwa 20 Stunden benötigen würde, um den Schlüsselraum systematisch auszutesten. Verschlüsselungssystem mit offenem Schlüssel Das als Public-Key-System bekannt gewordene Kryptosystem versucht, folgendes Problem zu lösen: Bei traditionellen, symmetrischen Verschlüsselungssystemen ohne zentrale Schlüsselverwaltung verlagert sich das Problem des Schutzes der Daten zum Problem des Schutzes der Schlüssel. Dies gilt besonders dann, wenn die Kommunikationspartner örtlich verteilt sind und nicht über einen sicheren Kommunikationskanal zur Übertragung der Schlüssel verfügen, sondern öffentliche Transportdienste in Anspruch nehmen müssen. Daher arbeitet ein Public-Key-System (bekanntester Vertreter ist RSA) mit zwei unterschiedlichen Schlüsseln; es wird deshalb auch als asymmetrisches Verschlüsselungssystem oder unsymmetrisches Verschlüsselungssystem bezeichnet.

346

Methoden und Techniken der Feinprojektierung

Jeder Teilnehmer eines Kommunikationssystems verfügt über zwei Schlüssel, einen öffentlichen Schlüssel (public key) und einen mit diesem korrespondierenden geheimen Schlüssel (secret key). Beide werden nach bestimmten mathematischen Regeln von einem gemeinsamen Ausgangsschlüssel abgeleitet. Zur Verschlüsselung einer Nachricht für einen bestimmten Empfänger E verwendet der Sender S den öffentlichen Schlüssel von E, den er einem Register entnehmen kann, das jedem zugänglich ist. Nur E kann mit seinem geheimen Schlüssel die Nachricht entschlüsseln. Da der öffentliche Schlüssel vom Sender zum Senden verwendet wird, heißt er auch Sendeschlüssel, der vom Empfänger verwendete geheime Schlüssel heißt auch Empfangsschlüssel. Beide Kanäle, der Kanal zur Verteilung der Schlüssel und der Kanal zur Übertragung der Nachrichten, dürfen unsicher sein. Voraussetzung für die Wirksamkeit des Systems ist, daß der Empfangsschlüssel aus dem Sendeschlüssel mit einem vertretbarem Aufwand nicht abgeleitet werden kann. Besondere Eignung besitzt das asymmetrische Verschlüsselungssystem für die elektronische Unterschrift. Die zu unterschreibende Nachricht wird mit dem Geheimschlüssel des Unterschreibenden verschlüsselt und kann vom Empfänger mit dem offenen Schlüssel entschlüsselt werden. Die elektronische Unterschrift enthält mit dem Geheimschlüssel das persönliche Merkmal des Unterschreibenden. Da der unterschriebene Text in die Unterschrift einbezogen ist, wird jede Änderung des Textes vom Empfänger erkannt. Praktikabel wird dieses Verfahren in Verbindung mit der Chipkarte (z.B. zur Sicherung der Zugriffsberechtigung auf ein zentrales Computersystem). Kryptoanalytische Angriffe Ziel kryptoanalytischer Angriffe ist es letztlich, aus einem bekannten Geheimtext den zugehörigen Klartext abzuleiten. Im einfachsten Fall eines Angriffs wird angenommen, daß der Angreifer den Geheimtext zur Verfügung hat und daß er durch Ausprobieren aller möglichen Schlüssel versucht, den Klartext abzuleiten ("Angriff mit bekanntem Geheimtext"). Dabei wird von der vermuteten Sprache des Klartextes ausgegangen. Von dieser Sprache sind die Häufigkeiten der Buchstaben bekannt oder können leicht aus beliebigen Klartexten abgeleitet werden. Häufig kennt der Angreifer mehr als nur den Geheimtext (z.B. weiß er, wovon der Klartext handelt und/oder wie er gegliedert ist); er kann dann ein Stück Klartext rekonstruieren. Von dem bekannten Klartext ausgehend wird versucht, den verwendeten Schlüssel herauszufinden ("Angriff mit bekanntem Klartext"). Die Analyse dieser beiden Angriffe führt zu dem Schluß, daß der Schlüssel so gewählt werden soll, daß der Schlüsselraum möglichst groß ist. Demonstrationsbeispiel Abbildung KRYPT-3 zeigt die Vorgehensweise bei der Verschlüsselung des Klartexts CRYPTO durch Vertauschung und Substitution sowie die Entschlüsselung dazu. Zur Definition der Matrix A wird ein Zeichenvorrat von 36 Zeichen unterstellt, sodaß m = 6 ist.

KRYPT - Kryptographische Verschlüsselungsmethoden

A D F G V X

A|D G: 7 Aj 1 C: 3 H; 8 K; L TjUj

347

F| G|V|X Klartext: C R Y P T O Ei 5 ; R;M Substitutionszeichen: FA AV DG VG XA VF N; Y| B! 2 » » ' T 1 Di 4 ] Fi 6 Fi A! Aj vi Dj G I [ 9 \ J iO V; Gjxj A: V: F Ö"i P ! Qi S V:W|X:Z Schlüssel: Schlüsseltext:

DV AG FV VA GF AX 1

2

3

4

W^J

5

6

Abb. KRYPT-3: Verschlüsselung durch Vertauschung und Substitution (Quelle: nach IBM)

Man verfolge die Verschlüsselung beispielhaft: Man nimmt das erste Zeichen des Klartextes, das ist C, und sucht die Position von C in M. Man entnimmt für C die Substitutionszeichen F (Zeilenbezeichnung) und A (Spaltenbezeichnung). Für das zweite Zeichen des Klartextes R findet man A und V, für das dritte Zeichen des Klartextes Y findet man D und G usw. Man stellt diese Zeichenfolge in eine Zeile; die Zeilenlänge entspricht der Länge des verwendeten Schlüssels, der 326415 ist. Die weiteren Substitutionszeichen werden in einer zweiten Zeile angeordnet. Die Semantik des Schlüssels wird so interpretiert, daß seine Ziffern die Ordnung der Zeichenfolge in den Zeilen bedeuten, wobei übereinander stehende Zeichen zusammengefaßt werden. Dementsprechend erfolgt die Vertauschung: Die Zeichen D und V werden im Schlüsseltext an die erste und zweite Stelle, die Zeichen A und G werden im Schlüsseltext an die dritte und vierte Stelle gesetzt usw. Alles übrige ergibt sich aus Abbildung KRYPT-3. Die Ziffernfolge im Schlüssel kann durch Mnemos ersetzt werden, wenn deren Zeichen unterschiedlich sind. Im Demonstrationsbeispiel könnte der Schlüssel GERMAN heißen, wobei die ordinale Ordnung der Buchstaben ihrer Stellung im Alphabet entspricht. Als Schlüsseltext ergibt sich dann: DVAGFVVAGFAX. Aufgabenverweise Entwickeln des Sicherungssystems (Lerneinheit ESICH). Kontrollfragen 1. Aus welchen Komponenten besteht das Grundmodell kryptographischer Verschlüsselung? 2. Was heißt "Vertauschung" und was heißt "Substitution"? 3. Wie bestimmt sich die Anzahl Zeilen und Spalten und wie sind sie zu bezeichnen, wenn die zur Substitution verwendete Matrix A quadratisch ist? 4. Wie schützt man sich gegen Angriffe auf Schlüssel? 5. Welche Schlüsselkonzeption wird beim Public-Key-System verwendet? Quellenliteratur Bauer, F. L.: Kryptologie. Methoden und Maximen. Springer Verlag, Berlin et al. 1993 Celler, W.: Mehr Datensicherheit durch Kryptographie. IBM-Nachrichten 34/1981,31 - 35 IBM (Ed.): Introduction to Cryptography - Student Text. Poughkeepsie/N.Y. 1981 Pommerening, K.: Datenschutz und Datensicherheit. B.I. Wissenschaftsverlag, Mannheim et al. 1991

348

Methoden und Techniken der Feinprojektierung

Vertiefungsliteratur Beth, T. et al.: Kryptographie - Eine Einführung in die Methoden und Verfahren der geheimen Nachrichtenübermittlung. Verlag Teubner, Stuttgart 1983 Diffle, W. and Hellman, M. E.: New Directions in Cryptography. In: IEEE Transactions on Information Theory 22/1976, 644 - 654 IBM (Ed.): Data Security through Cryptography. IBM Form GC22-9062 Meyer, C. H. und Matyas, S. M.: Cryptography - A New Dimension in Computer Data Security. New York 1982 Rivest, R. et al.: A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. In: Communications of the ACM 2/1978, 120 - 126 Ryska, N. und Herda, S.: Kryptographische Verfahren in der Datenverarbeitung. Springer Verlag, Berlin et al. 1980

Der Prozeß der Installierung Strategische Informationssystem-Planung V//W/WM///MSS/?,

| Planungsziele 2 Der Prozeß der Vorstudie Sä

Der Prozeß der Feinstudie yW/W/W//» Gmndkonzeption^ Der Prozeß der Grobprojektierung y f f f f f f f f f f r r f f f f f ff

>>}»>/»/.

; Logisches Modell % Sollzustand % Der Prozeß der Feinprojektierung

ä>

I

^

Physisches Modell ¿j Sollzustand, Der Prozeß der Installierung

< Produktives i £Irfoimationss^stem;

350

Der Prozeß der Installierung

Gegenstand des folgenden Kapitels ist der Teil des kooperativen und kreativen Arbeitsprozesses Systemplanung, der nach dem in diesem Lehrbuch verwendeten Phasenmodell als Installierung bezeichnet wird. Ausgehend vom Ziel der Installierung, werden im ersten Teil des Kapitels ihre Aufgaben entwickelt und die zur Unterstützung der Aufgabendurchführung verwendeten Methoden und Techniken charakterisiert. Anschließend werden die Aufgaben der Installierung im Detail erläutert. Im zweiten Teil des Kapitels werden die Methoden und Techniken der Installierung dargestellt. Die Zusammenhänge zwischen den Aufgaben der Installierung einerseits und ihren Methoden und Techniken andererseits werden durch Methodenverweise bzw. Aufgabenverweise verdeutlicht. Ergebnis der Installierung ist das produktiv verwendbare Informationssystem; der Prozeß der Systemplanung ist mit dem Vorliegen dieses Ergebnisses beendet. Aufgaben der Installierung ZAMIN VORIN DURIN

- Ziel, Aufgaben und Methodik der Installierung - Vorbereiten der Installierung - Durchführen der Installierung

.351 .359 ,366

Methoden und Techniken der Installierung VINST - Vorgehensweise bei der Installierung DAKON - Methoden der Datenkonvertierung.. PRADA - Methoden der Programmadaption...

372 .379 ,386

ZAMIN - Ziel, Aufgaben und Methodik der Installierung Lernziele Sie wissen, was Installierung in der Systemplanung bedeutet, und Sie können daraus die Aufgaben der Installierung ableiten. Sie können diese Aufgaben zweckmäßig strukturieren. Sie kennen die Methoden der Installierung und können sie erläutern. Sie wissen, was sich hinter der Bezeichnung Migration verbirgt. Sie kennen die Besonderheiten der Migration von Daten und Programmen im Vergleich zur Installierung als Phase der Systemplanung. Definitionen und Abkürzungen Anwendungsumgebung (application environment) = der vorhandene Bestand an Informationssystemen, in den ein Informationssystem eingefügt wird. Ausgangsplattform (basis platform) = eine Plattform, von der weg migriert wird. Client/Server-Architektur (client/server architecture) = eine Architektur, bei der sich zwei Komponenten in einer Dienstbenutzer/Dienstleister-Beziehung ("Client/Server-Beziehung") befinden, wobei die Zuteilung der Rolle als Dienstbenutzer ("Client") bzw. als Dienstleister ("Server") von Prozedur zu Prozedur unterschiedlich sein kann. G M D = Akronym für Gesellschaft für Mathematik und Datenverarbeitung. Installierungszeit (installation period) = die Zeitspanne zwischen dem Abschluß der Feinprojektierung und der Verfügbarkeit des produktiv verwendbaren Informationssystems bei den Benutzern. Installierungsziel (installation goal) = die Beschreibung eines bestimmten Zustands der Installierung, der angestrebt werden soll (z.B. bezüglich der Termine und der Kosten der Installierung). Konflikt (conflict) = eine durch Interessensgegensätze gekennzeichnete Beziehung zwischen Individuen und Gruppen. Konfliktmanagement (conflict management) = die Aufgabe des Informationsmanagements, Konflikte bei der Systemplanung zu erkennen, zu beherrschen und zu lösen. Nutzungsphase (usage phase) = die Phase im Lebenszyklus eines Informationssystems, die mit seiner Installierung beginnt und mit seiner Ablösung endet, offenes System (open system) = ein Computer, der insbesondere wegen der Eigenschaften seines Betriebssystems mit Computern anderer Hersteller zusammenarbeiten kann (interoperability), dessen Anwendungssoftware auf andere Computer übertragen (portability) und der in allen Größen konfiguriert werden kann ist (scalability). Plattform (platform) = eine einheitliche, für bestimmte Anwendungen spezifische Schnittstelle, die von der Funktionalität der zugrunde liegenden Schichten abstrahiert, proprietäres System (proprietary system) = das Gegenteil von einem offenen System. Synonym: geschlossenes System. Zielplattform (target platform) = eine Plattform, auf die hin migriert wird.

352

Aufgaben der Installierung

Ziel der Installierung Das generelle Sachziel der Systemplanung besteht darin, dem Auftraggeber - und damit letztlich den Benutzern - ein produktiv verwendbares Informationssystem zur Verfügung zu stellen. Entsprechend der Phasengliederung der Systemplanung (siehe Lerneinheit ZAMSP) sind aus dem Sachziel die Ziele der Phasen abzuleiten, hier also das Ziel der Installierung. Aus dem Ziel der Installierung sind deren Aufgaben abzuleiten sowie die zur Durchführung der Aufgaben anzuwendenden Methoden und Techniken zu bestimmen. Dies setzt eine Klärung dessen voraus, was in der Systemplanung unter "Installierung" als Prozeß bzw. unter "Installation" als Tätigkeit zur Abwicklung des Prozesses verstanden wird. Objekt der Installierung ist das Informationssystem, das durch ein IuK-Projekt geschaffen wurde, als Ganzes im Sinn von Mensch/Aufgabe/Technik-System. Die Betrachtung nur einzelner Komponenten dieses Systems (z.B. nur der Hardware) oder der Ergebnisse einzelner Teilprojekte (z.B. des Methodensystems in Form von Anwendungsprogrammen) reicht nicht aus, um das Phänomen der Installierung zu erklären. Installierung meint etwas Ganzheitliches, etwas, das das geschaffene Informationssystem als Ganzes betrifft. Ein weiteres Merkmal der Installierung ist, daß das Informationssystem so in die Nutzungsphase überführt werden soll, daß es den definierten Anforderungen der Aufgaben und der Aufgabenträger entspricht, das heißt, daß es produktiv verwendet werden kann. Ziel der Installierung ist daher die vollständige, den Planungszielen entsprechende Einfügung eines neu geschaffenen oder wesentlich veränderten Informationssystems in eine bestehende Informationsinfrastruktur. Die Einfügung erfolgt selbst wieder unter Beachtung bestimmter Formalziele, nämlich der Installierungsziele. Installierungsziele sind Formalziele, die sowohl mit den Projektzielen als auch mit den Aussagen der Informatik-Strategie abgestimmt sein müssen. Sie lassen sich in die Zielarten Terminziele, Kostenziele, Leistungsziele, Qualitätsziele und Akzeptanzziele einteilen. (Für eine feinere Zielplanung kann die in Lerneinheit PROPL gegebene Gliederung verwendet werden.) • Terminziele legen fest, (bis) zu welchen Zeitpunkten und/oder in welchen Zeiträumen bestimmte Aufgaben der Installierung durchzuführen sind (z.B. Zeitpunkt der Systemübergabe, Dauer der Installierung). • Kostenziele legen fest, mit welchen Kosten maximal welche Aufgaben der Installierung durchzuführen sind (z.B. Kosten für Benutzerschulung, Abstellung von Mitarbeitern, Beratung und Service). • Leistungsziele beschreiben die Art und den Umfang der Aufgaben der Installierung (z.B. Anzahl der zu schulenden Benutzer, Umfang der zu konvertierenden Datenbestände und Programme). • Qualitätsziele legen fest, nach welchen Gütekriterien die Durchführung der Installierungsaufgaben erfolgen soll und woran sie gemessen wird (z.B. Anzahl zulässiger Fehler). • Akzeptanzziele beschreiben die erwartete Einstellung und das Verhalten der Anwender und Benutzer im Umgang mit dem Informationssystem während der Installierung.

ZAM1N - Ziel, Aufgaben und Methodik der Installierung

353

Einige der Installierungsziele sind in der Regel konfliktär. In einer verdichteten Betrachtung läßt sich diese Situation auf den Gegensatz "Risiko vs. Kosten" zurückführen. Das heißt folgendes: Mit sinkender Bereitschaft des Managements, geeignete Installierungsmaßnahmen zu ergreifen, steigen das Akzeptanzrisiko und das Qualitätsrisiko, vice versa. Zwischen Risiko und Kosten ein Gleichgewicht herzustellen, ist ein typisches Optimierungsproblem der Installierung. In der Regel wird mit der Installation eines Informationssystems ein bestehendes Informationssystem überflüssig. Daher ist auch das Ersetzen eines vorhandenen Informationssystems ein wesentliches Merkmal der Installierung. Schließlich ist auch der Integrationsaspekt für die Klärung des Installierungsbegriffs von Bedeutung, da jedes neu geschaffene Informationssystem in die vorhandene Anwendungsumgebung so eingefügt werden muß, daß ein reibungsloses Zusammenwirken möglich ist. Es liegt auf der Hand, daß diese Integration Maßnahmen erfordert, die weit über das hinausgehen, was aus der Sicht eines einzelnen IuKProjekts verantwortet werden kann. Dies führt zu der Forderung, das Produkt der Systemplanung aus der Verantwortung des Projektmanagements in die Verantwortung des Informationsmanagements zu übergeben, so wie zu Beginn der Systemplanung die Planungsaufgabe aus der Verantwortung des Informationsmanagements in die des Projektmanagements übergegangen ist. Eine Fortdauer der Projektverantwortung des Projektmanagements, im Extremfall bis zum Ende des Lebenszyklus, ist nicht zweckmäßig; sie widerspricht auch dem Projektgedanken. Abbildung ZAMIN-1 veranschaulicht den Übergang von der Projektverantwortung zur Gesamtverantwortung. Informationsfunktion

i

i

Strategisches Informationsmanagement

?

V

J

Informationsinfrastruktur BASY

Planungsergebnisse

ANSW BASY PERS SONST

PERS

SONST

= Anwendungssoftware = Basissysteme = Personal = sonstige Infrastruktur

Abb. ZAMIN-1: Zusammenhang zwischen Systemplanung und Informationsmanagement

Die manchmal verwendete Bezeichnung "Einführung" (statt Installieren bzw. Installation) wird hier vermieden, weil sie mißverständlich ist. Die Verwendung der Bezeichnung "Implementierung" (oder sogar "Implementation") wird hier wegen der inhaltlich abweichenden Bedeutung in der Systementwicklung als "physische Realisierung" - vermieden. Eine Anpassung der Bezeichnung durch adjektivische Zusätze (z.B. "organisatorische Implementierung") wird in anderen

354

Aufgaben der Installierung

Disziplinen verwendet (z.B. in der Betriebswirtschaftslehre, vgl. Marr/Kötting); sie hat sich in der Wirtschaftsinformatik nicht durchgesetzt. Migration In einem engen Zusammenhang mit den Aufgaben, Strategien, Methoden usw. der Installierung steht die "Migration", eine aus dem Englischen ins Deutsche übernommene Bezeichnung für den koordinierten Übergang von einer bestehenden Ausgangsplattform auf eine Zielplattform. Die Investitionen in die Informationsinfrastruktur (z.B. Anwendungssoftware, Datenbestände, Peripheriegeräte ebenso wie Arbeitsorganisation und Fertigkeiten und Fähigkeiten der Mitarbeiter) sollen geschützt werden. Migration ist im Zusammenhang mit der Installierung des neu geschaffenen Informationssystems immer dann von Bedeutung, wenn wesentliche Komponenten der Informationsinfrastruktur ersetzt werden, insbesondere die Hardware-Plattform einschließlich Betriebssystem und das Datenverwaltungssystem (bzw. wenn von einem konventionellen Dateisystem auf ein Datenbanksystem oder von einem vor-relationalen Datenbanksystem auf ein relationales Datenbanksystem übergegangen wird). Mit der Datenmigration wird häufig gleichzeitig eine Programmigration verfolgt, das heißt die Umstellung von Anwendungssoftware, die in einer prozeduralen Programmiersprache implementiert ist (z.B. COBOL), auf eine nicht-prozedurale Programmiersprache (z.B. NATURAL). Treiber dieses Prozesses ist die Datenmigration, der die Programmigration folgt (und nicht umgekehrt). Das Ablösen der Ausgangsplattform ist häufig deshalb erforderlich, weil die Weiterentwicklung und Lieferung ihrer Produkte eingestellt wurden, aber auch deshalb, weil weiter verfügbare Produkte aus strategischen Gründen migriert werden sollen (z.B. soll von einem proprietären auf ein offenes System übergegangen werden). Ein heute typischer Migrationstrend geht von Mehrplatzsystemen zu Client-Server-Architekturen und von hierarchischen zu relationalen Datenbanksystemen. Formale Migrationsziele, die dabei verfolgt werden, sind die Verbesserung der Leistungsfähigkeit, der Qualität und der Wirtschaftlichkeit der Informationsverarbeitung. Entscheidend dafür, ob gesetzte Migrationsziele erreicht werden, sind die für die Migration verfügbaren und verwendeten Werkzeuge. Die Werkzeuge sollen möglichst den Gesamtprozeß der Migration, der in mehreren Phasen (Analyse, Planung und Durchführung) abläuft, unterstützen. Einzelheiten zur Migration werden in Lerneinheit DAKON ("Datenmigration") und Lerneinheit PRADA ("Programmigration") behandelt. Weitere Aspekte der Migration werden beim Informationsmanagement erläutert (vgl. Lerneinheit DATEM im Band "Informationsmanagement"). Aufgaben der Installierung Von dem Ziel der Installierung ausgehend und unter Berücksichtigung der Methodik der Systemplanung (vgl. Lerneinheit ZAMSP), können die Aufgaben der Installierung wie folgt gegliedert werden: • Vorbereiten der Installierung (vgl. Lerneinheit VORIN); • Durchführen der Installierung (vgl. Lerneinheit DURIN) .

ZAMIN - Ziel, Aufgaben und Methodik der Installierung

355

Zur Begründung dieser Gliederung halte man sich folgendes vor Augen: • Installierungsaufgaben können an sehr unterschiedliche Voraussetzungen gebunden sein, die im Systemplanungsprozeß zu verschiedenen Zeitpunkten, an unterschiedlichen Stellen oder in Form von Zwischen- oder Endergebnissen vorliegen. • Die Bearbeitung von Installierungsaufgaben kann selbst Voraussetzung für die Bearbeitung von anderen Aufgaben der Systemplanung sein (z.B. muß ein Basissystem installiert sein, damit Prototyping eingesetzt werden kann). • Projektziele, insbesondere Zeitziele, können es erforderlich machen, Installierungsaufgaben "vorzuziehen", sofern die Voraussetzungen für ihre Bearbeitung gegeben sind. • Die verfügbaren Kapazitäten für die Installierung (z.B. die Personalkapazität) erfordern eine zeitliche Verteilung der Installierungsaufgaben. Die Aufgaben des Vorbereitens der Installierung müssen planmäßig so in den Prozeß der Systemplanung eingefügt sein, daß der Umfang der Aufgaben, die erst nach Abschluß der Feinprojektierung durchgeführt werden können, möglichst gering gehalten wird. Ziel dieser Vorgehensweise ist es, die Installierungszeit zu minimieren. Die Aufgaben des Durchführens der Installierung können erst dann bearbeitet werden, wenn die Feinprojektierung vollständig abgeschlossen ist und wenn alle notwendigen Vorbereitungsmaßnahmen für die Installierung durchgeführt wurden.

J

1 Personal

S777777777777777777777777?*.

Vorbereiten der Installierung VORIN

Logisches Modell Sollzustand *«///////////////////////*

l Räume

1 Organisation Geräte

¿Physisches Modell? \ Sollzustand |

Programme Durchfuhren der Installierung DURIN I

Durchführen Abnahmetest

Start der Verarbeitung

Daten s?//////////////////////?*

^Physisches Modell t Sollzustand

Bewerten und Anpassen

1 Ubergeben und Abschlußarbeiten

* Produktives Informationssystem

lv/ss/,/sss/ssss////sss//////£

Abb. ZAMHM-2: Der Prozeß der Installierung

Abbildung ZAMIN-2 zeigt die Aufgaben der Installierung als groben Arbeitsablauf und gibt die Lerneinheiten an, in denen die Aufgaben erläutert werden. Die bisherigen Überlegungen haben gezeigt, daß die Installierung von sachlichen und

356

Auf gaben der Installierung

von personalen Einflüssen bestimmt wird. Sowohl die Aufgaben als auch die Methoden der Installierung müssen auf beide Einflußfaktoren Rücksicht nehmen. Methoden der Installierung Grundsätzliche Bedeutung hat die Vorgehensweise bei der Installierung (vgl. Lerneinheit VINST). Von der Vorgehensweise der Installierung ausgehend, werden die Methoden der Datenkonvertierung (vgl. Lerneinheit DAKON) und der Programmadaption (vgl. Lerneinheit PRADA) erläutert. Alle Zwischenprodukte und Produkte der Systemplanung werden projektbegleitend getestet (vgl. Lerneinheit TESTM) und dokumentiert (vgl. Lerneinheit DOKUM). Eine "Testphase" und eine "Dokumentationsphase", wie sie in manchen Vorgehensmodellen verwendet werden, sind unzweckmäßig. Die Besonderheit der Testmethoden und ihrer Anwendung im Prozeß der Installierung besteht in der überragenden Bedeutung des Integrationstests, mit dem die Einfügung des Informationssystems in die bestehende Anwendungsumgebung unterstützt wird (vgl. Lerneinheit DURIN). Demonstrationsbeispiel Es werden die Aufgaben genannt, die bei einer Migration abgearbeitet wurden. Bei dieser Migration wurden in der Bezirksdirektion Wiesbaden der GEMA Gesellschaft für musikalische Aufführungen mit Sitz in mehreren Großstädten in Deutschland vier QUATTRO-Systeme gegen ein System RM600 (120 Bildschirm-Arbeitsplätze, 16 Drucker, Betriebssystem SINIX) ausgetauscht. Folgende Aufgaben wurden abgearbeitet (die in der Originalquelle verwendeten, nicht immer eindeutigen Bezeichnungen wurden nicht verändert): • • • • • • • • • • • • • • • • •

Einweisung der Programmierabteilung; Einweisung des DV-Personals der Bezirksdirektionen; Umstellung der GEMA-spezifischen Programme; Migration der Daten aus der Bezirksstelle Wiesbaden; Installation der RM600 im Migrationszentrum Paderborn; Aufbereitung des Systems mit gleichzeitiger Einweisung des DV-Personals; Test der GEMA-Applikation nach einem vorgegebenen Testplan; Einarbeitung der Sachbearbeiter; Test der Drucker, PC-Integration und Test der Funktion Bankclearing; Umrüstung der Bildschirm-Arbeitsplätze und der Drucker; Parallellauf des Systems vor Ort; Einweisung weiterer Sachbearbeiter an der RM600; Abzug der Echtdaten von den QUATTRO-Systemen und Übertragung auf die RM600; Umrüstung der übrigen Bildschirm-Arbeitsplätze und Drucker; Anschluß der Bildschirm-Arbeitsplätze und Drucker an die RM600; Test vor Inbetriebnahme; Inbetriebnahme und Beginn des Echtbetriebs.

Die Aufgabenliste zeigt, daß ein Teil der Migrationsarbeiten in einem "Migrationszentrum", also nicht "vor Ort", durchgeführt wurde. Dies ist besonders dann

ZAMIN - Ziel, Aufgaben und Methodik der Installierung

357

angebracht, wenn mit der Migration nicht nur die Hardware-Plattform, sondern auch die Funktionalität der Anwendungsprogramme verändert oder erweitert wird. Forschungsbefunde Die Organisationsforschung bemüht sich, die potentiellen Einflußgrößen auf den Installierungserfolg und die zwischen diesen bestehenden Wirkungszusammenhänge zu erfassen. Besondere Beachtung fanden bisher "Macht" und "Barrieren" als Installierungsfaktoren. Im Ergebnis wird nach Marr/Kötting festgestellt, daß angesichts unterschiedlicher Interessen der Beteiligten Machtanwendung im Rahmen des Installierungsprozesses unvermeidlich ist. Da Machtanwendung zur Bildung von Gegenmacht führt, treten Konflikte auf. Zur Erreichung der Installierungsziele sind daher die Art und Weise der Machtausübung und das Konfliktmanagement entscheidend. Die Barriere von besonderer Bedeutung für den Installierungserfolg sind personale Widerstände, denen gegenüber technische, zeitliche, finanzielle usw. Barrieren relativ bedeutungslos sind. Menschliches Verhalten ist meist durch das Bestreben gekennzeichnet, den status quo aufrecht zu erhalten, wenn nicht positiv bewertete Veränderungsergebnisse eindeutig erkennbar sind. Die Ursachen personaler Widerstände sind vielschichtig (z.B. Furcht vor Steigerung der Leistungsanforderungen, Reduzierung des Handlungsspielraums und Verfall von Qualifikationspotentialen); sie sind (nach K. Bleicher) sach-rationaler oder sozio-emotionaler Art. Nach Kirsch et al. stellen sich personale Widerstände umso stärker ein, je weiter der Installierungsprozeß voranschreitet. Es wird dann zunehmend erforderlich, "Marketing-Aktivitäten" zu entfalten, um die Gefahr des Scheiterns des Installierungsprozesses zu vermeiden. Als wichtigstes Merkmal einer zweckmäßigen Installierungsstrategie wird der Partizipationsgrad angesehen, das heißt das Ausmaß, in dem die von der Installierung betroffenen Aufgabenträger in den Prozeß der Systemplanung einbezogen wurden (vgl. Lerneinheit BEBET im Band "Informationsmanagement"). Ist der Partizipationsgrad gering, ist es zweckmäßig, den Installierungsprozeß mit Teillösungen zu starten, um in einem iterativen Prozeß die Betroffenen schrittweise zur Anpassung zu zwingen. "Taktische Teillösungen" passen später möglicherweise nicht mehr schlüssig in das Gesamtkonzept. Erfolgversprechender ist eine starke Partizipation, insbesondere dann, wenn die Betroffenen unternehmerisch denken und handeln. Kontrollfragen 1. Worin besteht das Ziel der Installierung? 2. Durch welche Merkmale ist der Prozeß der Installierung gekennzeichnet? 3. Aus welchen Gründen werden die Aufgaben der Installierung in "Vorbereiten der Installierung" und "Durchführen der Installierung" gegliedert? 4. Welche Aufgaben sind beim Vorbereiten der Installierung zu bearbeiten? 5. Welche Aufgaben sind beim Durchführen der Installierung zu bearbeiten?

358

Aufgaben der Installierung

Quellenliteratur Krüger, W.: Organisatorische Einführung von Anwendungssystemen. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990, 275 - 288 Marr, R. und Kötting, M.: Implementierung, organisatorische. In: Frese, E. et al. (Hrsg.): Handwörterbuch der Organisation. 3. A„ Poeschel Verlag, Stuttgart 1992, 827 - 841 Spillner, A.: Das aktuelle Schlagwort: Integrationstest. In: Informatik Spektrum 5/1992, 293 - 294 Walk, Ch.: Aufgaben und Methoden eines Migrationszentrums. In: WIRTSCHAFISINFORMAIK 4/1993,311 -319 Vertiefungsliteratur Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. A., Oldenbourg Verlag, München/Wien 1992 Kirsch, W. et al.: Das Management des geplanten Wandels von Organisationen. Poeschel Verlag, Stuttgart 1979

VORIN - Vorbereiten der Installierung Lernziele Sie kennen die Aufgaben der Installierungsvorbereitung. Sie können diese Aufgaben erläutern und in geeigneter Weise in den Prozeß der Systemplanung einfügen. Sie erkennen den Zusammenhang zwischen dem Bedarf an Installierungsvorbereitung und dem Zustand der Informationsinfrastruktur. Sie erkennen, wie der Bedarf an Installierungsvorbereitung durch die Methodik der Systemplanung beeinflußt werden kann. Definitionen und Abkürzungen Ablauforganisation (process Organization) = der Teil der Organisation, der die raum-zeitliche Strukturierung der zur Aufgabenerfüllung erforderlichen Arbeitsgänge zum Gegenstand hat. Benutzerbeteiligung (user involvement) = der Bereich der Partizipation, der auf dem Konsens der Beteiligten beruht, also nicht durch kodifizierte Regelungen ("Mitbestimmung") bedingt ist. Synonym: Benutzermitwirkung. Datenorientierung (data orientation) = die Vorgehensweise bei der Systemplanung, die den Entwurf des Datensystems zum Ausgangspunkt des Systementwurfs macht. Durchdringungsgrad (degree of penetration) = eine Meßgröße zur Erfassung des Umfangs, in dem die Aufgaben einer Organisation durch Techniksysteme unterstützt werden. IKS-Abteilung (IS department) = Abkürzung für Abteilung Informations- und Kommunikationssysteme. Synonyme: EDV-Abteilung, Abteilung Organisation/ Datenverarbeitung. Installierungszeit (installation period) = die Zeitspanne zwischen dem Abschluß der Feinprojektierung und der Verfügbarkeit des produktiv verwendbaren Informationssystems bei den Benutzem. Organisationsmittel (aid for Organization) = die Sachmittel, die, ohne selbst Aufgabenträger zu sein, als Hilfsmittel für die Erfassung, Übertragung, Speicherung usw. von Daten verwendet werden, sowie die "Mittel des Organisierens" wie Erhebungs-, Darstellungs- und Analysemethoden. Qualifikation (qualification) = das Wissen und das Können (Fähigkeiten und Fertigkeiten einer Person oder Gruppe), die erforderlich sind, um mit Information und Kommunikation als wirtschaftlichem Gut umgehen zu können. R e k o n f i g u r a t i o n (reconfiguration) = die nur graduelle, nicht grundlegende Veränderung einer Konfiguration. Schulungsprogramm (training program) = die inhaltliche, zeitliche und methodische Planung von Qualifizierungsmaßnahmen und ihre Zuordnung auf Personen. Strukturorganisation (organizational structure) = der Teil der Organisation, der die Gliederung der Gesamtaufgabe in Tätigkeiten und deren Zuordnung auf Aufgabenträger zum Gegenstand hat. Synonym: Aufbauorganisation. V e r f ü g b a r k e i t (availability) = die durchschnittliche Zeitspanne, in der ein System die geforderten Funktionen fehlerfrei ausführt.

360

Aufgaben der Installierung

Aufgaben beim Vorbereiten der Installierung Das Phasenschema der Systemplanung (vgl. Lerneinheit ZAMSP) gibt lediglich eine logische Ordnung der Aufgaben der Systemplanung an; es macht zum Beispiel keine Aussagen über deren zeitliche Ordnung (die für ein bestimmtes Projekt durch die Projektplanung festgelegt wird; vgl. Lerneinheit PROPL). Typisch für das Vorbereiten der Installierung ist es, daß einzelne Aufgaben, die logisch dieser Planungsphase zugeordnet werden, bereits während anderer Planungsphasen erfolgen. Im Interesse einer Minimierung der Installierungszeit wird versucht, den Umfang der Aufgaben der Installierungsvorbereitung, die erst nach Abschluß der Feinprojektierung durchgeführt werden können, so gering wie möglich zu halten. Der Bedarf an Installierungsvorbereitung ist umso geringer, je besser die Informationsinfrastruktur, in die das neu geschaffene Informationssystem eingefügt werden soll, entwickelt ist. Wenn beispielsweise der Durchdringungsgrad hoch ist und wenn die Systemplanung ein die Informationsinfrastruktur nur ergänzendes Informationssystem zum Gegenstand hat, entfällt der größte Teil der vorbereitenden Aufgaben bzw. haben diese Aufgaben nur ergänzenden Charakter. Umgekehrt ist bei einem geringen Durchdringungsgrad der Umfang der Installierungsvorbereitung entsprechend groß. Entscheidend für den Bedarf an Installierungsvorbereitung ist also das Verhältnis zwischen dem Informationssystem-Bestand und dem einzufügenden Informationssystem. Struktur der Vorbereitungsaufgaben Unabhängig vom Bedarf an Installierungsvorbereitung, können die Vorbereitungsaufgaben in personelle, organisatorische, räumliche, gerätetechnische, programmtechnische und datentechnische Vorbereitung gegliedert werden (vgl. Abbildung VORIN-1). Die folgende Erläuterung der Vorbereitungsaufgaben beschränkt sich auf einige grundsätzliche Aussagen, da deren Gestaltung im einzelnen vom konkreten Installierungsprozeß (also vom jeweiligen IuK-Projekt) abhängig ist. Auf die zu ihrer Unterstützung verfügbaren Methoden und Techniken wird hingewiesen.

Abb. VORIN-1: Aufgaben beim Vorbereiten der Installierung

VORIN - Vorbereiten der Installierung

Personelle

361

Vorbereitung

Informationssysteme sind Mensch/Aufgabe/Technik-Systeme. Auf die sich daraus ergebende Notwendigkeit des Einbeziehens der Benutzer in die Systemplanung wurde bereits mehrfach eingegangen (vgl. insbes. Lerneinheit AUTER sowie Lerneinheit BEBET im Band "Informationsmanagement"). Benutzerbeteiligung ist aber nur dann möglich, wenn die Benutzer über die für eine sachgerechte Mitwirkung erforderliche Qualifikation verfügen. Diese ist häufig nicht vorhanden, sodaß Qualifizierungsmaßnahmen erforderlich sind. Darüber hinaus sind Qualifizierungsmaßnahmen erforderlich, die den Benutzern einen sachgerechten Umgang mit dem zu installierenden Informationssystem ermöglichen. Es sind also personelle Vorbereitungsmaßnahmen ("Personalschulung") notwendig, die sowohl eine sachgerechte Mitwirkung bei der Systemplanung als auch eine sachgerechte Nutzung der Planungsergebnisse sicherstellen. In Abhängigkeit vom Ausmaß der vorhandenen Qualifikation einerseits und dem geforderten Qualifizierungsniveau andererseits, wird der Bedarf an Personalschulung ermittelt. Dem Bedarf werden Qualifizierungsmaßnahmen inhaltlich, methodisch und terminlich so zugeordnet, daß das geforderte Qualifizierungsniveau spätestens zu dem Zeitpunkt erreicht wird, an dem die dieses Niveau erfordernden Aufgaben auf Grund der Projektplanung in Angriff genommen werden sollen. Das sich aus diesen Planungen ergebende Schulungsprogramm kann in Grundschulung und Aufgabenschulung, die sich durch ihre Schulungsziele wesentlich unterscheiden, gegliedert werden. • Das Lehrziel der Grundschulung kann wie folgt beschrieben werden: Die Mitarbeiter kennen die Grundzüge der Systemplanung und die Funktionsweise der wichtigsten Organisationsmittel (z.B. die Funktionsweise eines Computers). • Das Lehrziel der Aufgabenschulung kann wie folgt beschrieben werden: Die Mitarbeiter können die ihnen im Systemplanungsprozeß und im Umgang mit den Ergebnissen der Systemplanung übertragenen Aufgaben sachgerecht wahrnehmen. Letzteres heißt insbesondere, daß sie das installierte Informationssystem in ihrer persönlichen Arbeitssituation wie geplant zur Unterstützung der ihnen zugeordneten Aufgaben "produktiv" verwenden können. Die Aufgabenschulung soll durch direktes Training an typischen Beispielen erfolgen, um nicht nur Wissen, sondern insbesondere Fähigkeiten und Fertigkeiten zu vermitteln. Die Aufgabenschulung kann weitgehend in frühere Phasen des Planungsprozesses verlagert werden, wenn Prototyping als Entwurfs- und Entwicklungsmethodik verwendet wird (vgl. Lerneinheit PROTY). Durch die Systemplanung entstehen häufig Aufgaben, die eine Qualifikation erfordern, die durch Schulung eigener Mitarbeiter nicht erreicht werden kann. In diesem Fall müssen Maßnahmen zur Personalbeschaffung vorgesehen werden. Typische Beispiele sind Arbeitsplätze für Systemplaner und Anwendungsprogrammierer. Personalbeschaffungsmaßnahmen zur Besetzung derartiger Arbeitsplätze werden reduziert oder vermieden, wenn Aufgaben mit besonderen Qualifikationsanforderungen ausgelagert werden (z.B. an Software-Häuser).

362

Aufgaben der Installierung

Organisatorische Vorbereitung Informationssysteme sind integrale Bestandteile der Struktur- und Ablauforganisation. Sie werden nicht "neben" diesen entwickelt und nach Abschluß der Entwicklung an diese angepaßt, sondern sie entstehen - bei einer richtig angelegten Systemplanung - aus dem organisatorischen Gefüge heraus und sind diesem prinzipiell von vornherein angepaßt, also kein Fremdkörper. Das heißt jedoch nicht, daß die bestehenden Strukturen und Abläufe unverändert bleiben. Die Veränderungen erfordern Vorbereitungsmaßnahmen bei der Strukturorganisation und bei der Ablauforganisation sowie bei den Organisationsmitteln. • Strukturorganisation: Bestehende Aufgaben werden inhaltlich verändert, einzelne Aufgaben entfallen, andererseits entstehen neue Aufgaben. Dies führt zu der Frage, ob die bestehende Strukturorganisation noch zweckmäßig ist. In der Regel ist eine Änderung der Zuordnung von Aufgaben auf Aufgabenträger (Menschen und Sachmittel) erforderlich, die auch zu einer Veränderung bestehender Abgrenzungen zwischen einzelnen Struktureinheiten führen kann. • Ablauforganisation: Deutlicher als die Veränderungen der Strukturorganisation sind die Veränderungen der Ablauforganisation. Da diese Veränderungen aber selbst Gegenstand der Installierung sind (vgl. Lerneinheit DURIN), bedürfen sie keiner besonderen vorbereitenden Maßnahmen. • Organisationsmittel: Soweit es sich bei den Organisationsmitteln um Techniksysteme als Sachmittel und Aufgabenträger handelt, sind sie Gegenstand der gerätetechnischen Vorbereitung. Daneben müssen eine Reihe weiterer Sachmittel (z.B. Datenträger in Form von Formularen) sowie die "Mittel des Organisierens", wie Erhebungs-, Darstellungs- und Analysemethoden sowie die sie unterstützenden Werkzeuge rechtzeitig verfügbar gemacht werden. Räumliche Vorbereitung Informationssysteme sind auch dadurch gekennzeichnet, daß Techniksysteme eingesetzt werden, für die - einschließlich der erforderlichen Transporttechnik (z.B. Verkabelung) - räumliche Vorbereitungsmaßnahmen erforderlich sind. Im Verlauf der Entwicklung der Techniksysteme sind die Anforderungen an die räumliche Vorbereitung sowohl in quantitativer Hinsicht (flächenmäßiger Raumbedarf) als auch in qualitativer Hinsicht (z.B. Deckenbelastung, Doppelböden, Klimatisierung) erheblich zurückgegangen. Nach wie vor sind aber planmäßige Vorbereitungsmaßnahmen zur Deckung des zentralen und des dezentralen Raumbedarfs erforderlich. • Zentraler Raumbedarf: Dabei handelt es sich um den Raumbedarf der IKS-Abteilung für Personal, Geräte und sonstige Sachmittel. Entsprechende Vorbereitungsmaßnahmen können nicht Gegenstand der Systemplanung, sondern müssen Aufgabe des Informationsmanagements sein, da sie in der Regel nicht projektbezogen sind, sondern die Informationsinfrastruktur als Ganzes betreffen. • Dezentraler Raumbedarf: Dabei handelt es sich um den Raumbedarf am Benutzerarbeitsplatz in den Fachabteilungen. Da es sich hierbei um die zweckmäßige Situierung von Endgeräten und PCs handelt, stehen primär qualitative

VORJN - Vorbereiten der Installierung

363

Gesichtspunkte im Vordergrand, also solche der Arbeitsplatzergonomie (vgl. Lerneinheit PAPER). Trotz der zunehmenden Dezentralisierung der Informationsinfrastruktur spielen räumliche Schutzmaßnahmen (insbes. im Zusammenhang mit dem zentralen Raumbedarf) eine große Rolle. Mit Maßnahmen zum Objektschutz muß eine ausreichend hohe Schwelle gegen das unbefugte Eindringen (Einbrechen, Einschleichen, Einschließen, Überfallen und Sabotieren) geschaffen werden. Dies schließt das Überwachen des Freigeländes ein, auf dem sich das zu schützende Gebäude befindet. Mit Maßnahmen zum Hardware-Schutz sollen die Ursachen beseitigt oder zumindest reduziert werden, die den Betrieb von Hardware unterbrechen, zu Schäden an der Hardware führen oder Hardware zerstören können. Wegen des erheblichen Umfangs der hier zu prüfenden Möglichkeiten und der durchzuführenden Maßnahmen muß auf die Spezialliteratur verwiesen werden (vgl. Kapitel Schutztechnik im Band "Informations- und Kommunikationstechnik"). In diesem Zusammenhang muß auch auf die projektspezifischen Sicherungsmaßnahmen (vgl. Lerneinheit ESICH) verwiesen werden, soweit sie räumliche Vorbereitungsmaßnahmen erfordern (z.B. die Sicherung von Datenbeständen durch Auslagerung). Gerätetechnische Vorbereitung Zweck der gerätetechnischen Vorbereitung ist es, die Verfügbarkeit der Techniksysteme herzustellen. Dazu gehört das Aufstellen und Testen der Funktionsweise der zentralen Komponenten (z.B. Zentraleinheit, Massenspeicher, Systemdrucker), der dezentralen Komponenten (z.B. Bildschirmgeräte, PCs, Arbeitsplatzdrucker) und der diese verbindenden physischen Komponenten des Transportsystems (z.B. Verkabelung zentraler Komponenten mit lokalen Endgeräten). • Aufstellen der Geräte: Dies erfolgt normalerweise durch das Personal des Lieferanten. Das Personal der IKS-Abteilung soll dabei mitwirken, um sicherzustellen, daß die Aufstellung korrekt erfolgt. Die Zusammenarbeit zwischen dem Personal des Lieferanten und dem der IKS-Abteilung sichert auch ein schnelles Vertrautwerden mit den installierten Geräten. • Testen der Geräte: Bezüglich der personellen Aspekte gilt das zum Aufstellen der Geräte Gesagte analog. Zweck des Gerätetests ist es festzustellen, ob die Geräte komplett installiert sind und einwandfrei arbeiten. Gewöhnlich umfaßt der Test die Abarbeitung bestimmter Testroutinen, die vom Lieferanten beigestellt werden. Die Testergebnisse sollen vom Personal der IKSAbteilung sofort überprüft werden, um sicherzustellen, daß die Tests umfassend genug angesetzt wurden und korrekt abgelaufen sind. Schließlich sollen in die Gerätetests auch solche Testobjekte einbezogen werden, die Ergebnisse der Systemplanung sind, also selbst entwickelte oder fremd erstellte Individualsoftware und Standardsoftware. Programmtechnische

Vorbereitung

Ist nicht nur selbst entwickelte oder fremd erstellte Individualsoftware Ergebnis der Systemplanung, sondern wird auch Standardsoftware eingesetzt, ist normalerweise eine Reihe von Anpassungsmaßnahmen erforderlich, um den

364

Aufgaben der Installierung

"Abstand" zwischen den struktur- und ablauforganisatorischen Anforderungen einerseits und den Eigenschaften der Standardsoftware andererseits zu beseitigen (z.B. durch Parametrisierung der Anwendungsprogramme). Hersteller und Lieferanten von Standardsoftware haben zu diesem Zweck spezifische Vorgehensmodelle entwickelt. Anpassungsmaßnahmen können auch bei Rekonfigurationen erforderlich sein, insbesondere dann, wenn ohne sie eine volle Ausschöpfung der Leistungsfähigkeit des rekonfigurierten Systems nicht möglich ist. Dabei stellt sich die Frage, ob die vorhandenen Anwendungsprogramme - unter der Voraussetzung, daß diese auf dem rekonfigurierten System ablauffähig sind - angepaßt werden sollen oder ob eine Neuprogrammierung zweckmäßiger ist. Programmanpassung hat im allgemeinen die Konsequenz, daß die Programmlaufzeiten verlängert werden. Dem steht als Vorteil die schnelle Installierung bei geringem Ressourceneinsatz gegenüber. Angepaßte Programme werden daher in der Regel nur während einer geplanten Übergangsphase verwendet und dann durch eine Neuprogrammierung abgelöst. Um die in die Altsoftware getätigten Investitionen wenigstens teilweise zu retten, kann die Migration von Programmen ("Programmigration") zweckmäßig sein. Zur Lösung dieser Wahlprobleme dient eine dynamisierte, über den gesamten Nutzungszeitraum greifende Kostenvergleichsrechnung (vgl. Lerneinheit WIRTA). Weitere Informationen zur programmtechnischen Vorbereitung finden sich in Lerneinheit PRADA. Datentechnische Vorbereitung Die Zweckmäßigkeit der Datenorientierung der Systemplanung wurde bereits im Zusammenhang mit der Erläuterung ihrer Methodik verdeutlicht (vgl. Lerneinheit ZAMSP) und an verschiedenen Stellen weiter begründet (vgl. z.B. Lerneinheit VGROB). Die Datenorientierung hat auch für die Installierung Gültigkeit und erklärt die grundlegende Bedeutung der datentechnischen Vorbereitung. Die datentechnische Vorbereitung hat das Ziel, das entwickelte Datensystem (vgl. Lerneinheit EDASY) auf den dafür vorgesehenen Speichermedien für alle berechtigten Anwendungsprogramme und Benutzer verfügbar zu machen. Dies ist weniger eine Aufgabe der physischen Datenspeicherung (die vom Datenverwaltungssystem übernommen wird), als vielmehr eine Aufgabe des Sammeins und Erfassens der Daten sowie des Überprüfens der Richtigkeit und Vollständigkeit der erfaßten Daten. Problematisch und zeitaufwendig ist die datentechnische Vorbereitung dann, wenn das bestehende Datensystem gegenüber dem geplanten Datensystem erhebliche inhaltliche Lücken aufweist und wenn es in einer physischen Realisierungsform vorliegt, auf die ein maschineller Zugriff nicht möglich ist (z.B. in Form von Karteien oder unsystematischen, persönlichen Aufzeichnungen der Aufgabenträger). Weitere Informationen zur datentechnischen Vorbereitung finden sich in Lerneinheit DAKON. Methodenverweise Vorgehensweise bei der Installierung (Lerneinheit VINST); Methoden der Datenkonvertierung (Lerneinheit DAKON); Methoden der Programmadaption (Lerneinheit PRADA).

VORIN - Vorbereiten der Installierung

365

Kontrollfragen 1. Welcher Zusammenhang besteht zwischen Installierungsvorbereitung und Durchdringungsgrad? 2. In welche Aufgaben kann die Installierungsvorbereitung gegliedert werden? 3. Wie wird der Bedarf an Schulungsmaßnahmen durch Benutzerbeteiligung beeinflußt? 4. In welchem Zusammenhang stehen Schutzmaßnahmen und räumliche Vorbereitung? 5. Warum wird der datentechnischen Vorbereitung eine grundlegende Bedeutung beigemessen? Quellenliteratur Heinrich, L. J. et al.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 4. A., Oldenbourg Verlag, München/Wien 1994 Vertiefungsliteratur Boll, M.: Prozeßorientierte Implementation des SAP-Softwarepaketes. In: WIRTSCHAFTSINFORMAUK 5/1993, 418 - 423 Pietsch, M.: PAREUS-RM - ein Tool zur Unterstützung der Konfiguration von PPS-Parametern im SAP-System R/2. In: WIRISCHAFTSINFORMAnK 5/1993, 434 - 445

DURIN - Durchführen der Installierung Lernziele Sie kennen die Aufgaben beim Durchführen der Installierung. Sie können diese Aufgaben erläutern. Sie kennen den Zusammenhang, der zwischen dem zu installierenden Informationssystem und der Informationsinfrastruktur besteht und seinen Einfluß auf die Durchführung der Installierung. Definitionen und Abkürzungen Abnahmetest (acceptance test) = ein Test, den Auftraggeber und Auftragnehmer vereinbaren, um zu überprüfen, ob das übergebene Produkt die geforderten Eigenschaften erfüllt. Abweichung (deviation) = die Differenz zwischen dem geplanten Grad der Zielerreichung ("Soll") und dem tatsächlichen Grad der Zielerreichung ("Ist"). Synonym: Soll/Ist-Abweichung (target/actual deviation). Bewertung (evaluation) = Die zielbezogene Beurteilung von Alternativen auf der Grundlage eines Systems von Beurteilungskriterien. Bewertungsverfahren (evaluation procedure) = eine systematische Vorgehensweise zur Bewertung, mit der das "Was?" und das "Wie?" der Bewertung festgelegt sind. Diagnose (diagnosis) = das Erkennen, Feststellen oder Bezeichnen von Abweichungen der tatsächlichen Funktionsweise und/oder Leistung eines Systems von einer geplanten Funktionsweise und/oder Leistung. Ereignis (event) = ein Vorgang, der einen Arbeitsablauf aktiviert und der zu einer Veränderung des Zustands des Systems führt, der dem Arbeitsablauf zugrunde liegt. Fehler (error) = die negative Abweichung einer Größe von einem geplanten (z.B. dem theoretisch exakten) Wert. Installierungsmethode (installation technique) = eine planmäßige und einheitliche Vorgehensweise bei der Installierung, die sich an sachlichen, zeitlichen und qualitativen Merkmalen orientiert. Installierungsplanung (installation scheduling) = die Festlegung der Aufgaben der Installierung sowie der Aufgabenträger, der Termine, der Zeitpunkte usw. der Aufgabendurchführung. Integrationstest (integration test) = ein Test, mit dem die Schnittstellen zwischen dem zu installierenden System und seinem Umsystem überprüft werden. Interdependenz (interdependence) = eine Beziehungsform zwischen Elementen, Funktionen, Komponenten, Personen usw., die dadurch gekennzeichnet ist, daß A von B in der Weise abhängig ist, in der B von A abhängig ist. Ursache (cause) = die Voraussetzung, die Bedingung oder das Motiv für die Entstehung einer Ordnung oder die Veränderung einer Ordnung (z.B. für das Entstehen einer Abweichung). Ursachenanalyse (cause analysis) = die systematische Vorgehensweise beim Feststellen der Ursachen, die für diagnostizierte Abweichungen verantwortlich sind.

DURIN - Durchführen der Installierung

367

Aufgaben beim Durchführen der Installierung Nach dem Abschluß aller Vorbereitungsmaßnahmen zur Installierung wird die durch Abbildung ZAMIN-1 schematisch dargestellte Einfügung der Ergebnisse der Systemplanung in die Informationsinfrastruktur so vervollständigt, daß das neu geschaffene Informationssystem im Echtbetrieb verwendet werden kann ("produktives Informationssystem"). Dieses Vervollständigen umfaßt zumindest die folgenden Aufgaben und die angegebene logische Abfolge dieser Aufgaben (vgl. Abbildung DURIN-1): • Durchführen von Integrations- und Abnahmetest; • Start der Verarbeitung nach der neuen Arbeitsorganisation, einschließlich des Abschließens der Verarbeitung nach der bestehenden Arbeitsorganisation; • Bewerten der tatsächlichen Funktionen und Leistungen des installierten Informationssystems im Vergleich zu den geplanten Funktionen und Leistungen (entsprechend den Planungszielen), einschließlich der notwendigen Anpassungen; • Übergeben des Informationssystems vom Projektmanagement an das Informationsmanagement und das Durchführen verschiedener Abschlußarbeiten. Die folgende Erläuterung dieser Installierungsaufgaben beschränkt sich auf grundsätzliche Aussagen, da ihre Gestaltung im einzelnen vom konkreten Projekt der Systemplanung abhängt. Physisches Modell Informationssystem

Durchführen vc)n Integrationsund Abn ahmetest

Start der Verarbeitung

Bewerten und Anpassen

Übergebtin und Abschluß;irbeiten

Produktives Informationssystem

Abb. DURIN-1: Aufgaben beim Durchführen der Installierung

368

Aufgaben der Installierung

Durchführen von Integrations- und Abnahmetest Mit dem projektbegleitenden Testen (vgl. Lerneinheit TESTM) kann das Überprüfen von Schnittstellen nur insoweit erfaßt werden, als es sich um Schnittstellen zwischen den Systemkomponenten handelt (sog. Systemtest). Dieser Integrationstest im engeren Sinn erfaßt nicht die zwischen dem Informationssystem und seiner Anwendungsumgebung bestehenden Schnittstellen, zumindest nicht vollständig. Der Integrationstest im Sinn der Installierung erfordert das "sukzessive Hochfahren" des Informationssystems in seiner konkreten Anwendungsumgebung. Die Anwendungsumgebung besteht nicht nur aus Daten und Programmen, sondern auch aus Arbeitsabläufen, Verhaltensweisen und persönlichen Arbeitssituationen. Erst mit dem Durchführen der Installierung ist der Zeitpunkt erreicht, zu dem die Schnittstellen zur Anwendungsumgebung umfassend in den Integrationstest einbezogen werden können. Während beim Komponententest das Überprüfen der Funktionen im Mittelpunkt steht (deshalb auch "Funktionstest" genannt), konzentriert sich das Interesse beim Integrationstest auf die Produktqualität (z.B. auf die Untersuchung von Zuverlässigkeit und Leistung durch Belastungstests und Leistungstests). Da Testziele dieser Art auch beim Abnahmetest im Vordergrund des Interesses stehen, gibt es einen engen Zusammenhang zwischen Integrationstest und Abnahmetest. Mitunter wird der Integrationstest als Teil des Abnahmetests angesehen. Mit dem Abnahmetest soll vor dem Start der Verarbeitung überprüft werden, ob das Informationssystem die geforderten Eigenschaften bezüglich der geplanten Funktionen und Leistungen erbringt, soweit eine derartige Überprüfung durch einen Test überhaupt möglich ist. Der Abnahmetest sollte von der Projektgruppe ("Auftragnehmer") und dem Informationsmanagement mit den Benutzern ("Auftraggeber") gemeinsam durchgeführt werden. In Abhängigkeit von den Ergebnissen des Abnahmetests wird über die weitere Vorgehensweise bei der Durchführung der Installierung entschieden. Größere Abweichungen zwischen den geplanten Funktionen und Leistungen und den tatsächlich verfügbaren Funktionen und Leistungen, die durch den Abnahmetest festgestellt werden, führen zu einer Änderung der Installierungsplanung, meist auch zu einer Verschiebung des geplanten Starts der Verarbeitung. Wegen der damit verbundenen negativen Konsequenzen, soll eine Änderung der Installierungsplanung nur nach einer gründlichen Analyse aller durch den Abnahmetest aufgedeckten Abweichungen erfolgen, insbesondere nach Aufdeckung ihrer Ursachen ("Ursachenanalyse"). Die Abweichungen müssen vom Informationsmanagement auch daraufhin überprüft werden, ob eine Nachbesserung des Informationssystems möglich oder ob eine Anpassung der Planungsziele (zumeist im Sinn einer Reduzierung von Anforderungen) notwendig ist. Start der Verarbeitung Der Start der Verarbeitung nach der neuen Arbeitsorganisation und das Beenden der Verarbeitung nach der bestehenden Arbeitsorganisation erfolgen unter der Verantwortung der Projektgruppe und mit deren aktiver Unterstützung bei Einbeziehung der Benutzer, nicht also unter der Verantwortung der Benutzer und allein durch sie.

DURIN - Durchfuhren der Installierung

369

Für die Installierung des Informationssystems und einzelner Teilsysteme wurden bei der Installierungsplanung Termine festgelegt. Installierungstermine (z.B. bestimmte Tage) reichen für die eindeutige Festlegung des Starts der Verarbeitung nicht aus. Erforderlich ist die Festlegung eines bestimmten Ereignisses innerhalb des Installierungstermins (z.B. eines bestimmten Kundenauftrags in einem Informationssystem der Produktionsplanung und -Steuerung); dieses Ereignis bestimmt in allen logisch verbundenen Teilsystemen die "Startereignisse" der Installierung (z.B. in der Lagerwirtschaft den ersten Lagerabgang, der durch den definierten Kundenauftrag ausgelöst wird). Wenn die geplante Installierungsmethode eine Stichtagsumstellung vorsieht (vgl. Lerneinheit VINST), ergibt sich durch das Festlegen der Startereignisse für jeden Arbeitsvorgang im Arbeitsablauf der genaue Zeitpunkt des Starts der Verarbeitung nach der neuen Arbeitsorganisation und damit der Zeitpunkt des Beendens der Verarbeitung nach der bestehenden Arbeitsorganisation. Sieht die Installierungsmethode eine Parallelumstellung vor (vgl. Lerneinheit VINST), dann ist der Zeitpunkt des Beendens der Verarbeitung nach der bestehenden Arbeitsorganisation unabhängig vom Zeitpunkt des Starts der Verarbeitung nach der neuen Arbeitsorganisation nach anderen Kriterien festzulegen (z.B. nach dem Zeitraum, der bis zur Unterschreitung einer geplanten Fehleranzahl erforderlich ist). Unabhängig von der Installierungsmethode, erfolgt die Installierung nicht gleichzeitig für alle am Arbeitsablauf beteiligten Aufgabenträger, sondern jeweils zu dem Zeitpunkt, zu dem das Startereignis bei den am Arbeitsablauf beteiligten Aufgabenträgern ein logisch verbundenes Ereignis auslöst. Die mit der Orientierung an Startereignissen verbundene Dehnung des Installierungstermins zu einem Installierungszeitraum ermöglicht es der Projektgruppe, die ersten, nach der neuen Arbeitsorganisation bearbeiteten Ereignisse im Arbeitsablauf konsequent zu verfolgen und den Benutzern gezielt Unterstützung zu geben. Folgende Unterstützungsaufgaben sind von Bedeutung: • das Überwachen der korrekten Bearbeitung durch die Aufgabenträger und das Aushelfen bei Bearbeitungsschwierigkeiten; • die Diagnose von Bearbeitungsfehlern, die sich aus der Umstellung der Arbeitsorganisation ergeben, und ihr Beseitigen; • die Diagnose und das Beseitigen von Fehlern im Informationssystem, insbesondere von Fehlern in der Anwendungssoftware; • das Sammeln von Informationen für eine realistische Bewertung des installierten Informationssystems. Bewerten und Anpassen Bewerten meint auf der untersten Ebene "Bewerten des Installierungsprozesses", das heißt Überprüfen des Erreichens der Installierungsziele. Bewerten auf der zweiten Ebene meint "Bewerten des installierten Informationssystems", das heißt Beschreiben seiner Funktionen und Leistungen auf Grund der produktiven Nutzung, Vergleichen mit den geplanten Funktionen und Leistungen entsprechend den Planungszielen und Ermitteln der Ursachen von Abweichungen. Dabei geht es um die Überprüfung der Sachziele (vgl. Lerneinheit SACHZ). Die geplante Nutzung kann unterschritten werden ("Nutzungslücke") oder über-

370

Aufgaben der Installierung

schritten werden ("Zusatznutzung"). Die Abweichungsursachen können von unterschiedlicher Art sein, beispielsweise: • Im Zeitraum zwischen dem Abnahmetest und dem Start der Verarbeitung haben sich Anforderungen verändert; diese waren der Planungsgruppe nicht bekannt, wurden von ihr nicht berücksichtigt oder wurden falsch eingeschätzt. • Der Abnahmetest war nicht gründlich oder nicht umfassend genug; beispielsweise wurden bestimmte Teile des Informationssystems nicht oder nicht ausreichend getestet. • Die Vorbereitung der Installierung (vgl. Lerneinheit VORIN) war nicht gründlich und umfassend genug (z.B. standen notwendige Organisationsmittel nicht rechtzeitig oder nicht ausreichend zur Verfügung). Abweichungen sollen unverzüglich dokumentiert und analysiert werden. Wegen der möglicherweise bestehenden Interdependenzen mit anderen Systemteilen sollen Anpassungen erst nach gründlicher Analyse und Abstimmung durchgeführt werden. Insbesondere muß vermieden werden, daß ein einzelner, für die Installierung bestimmter Systemteile verantwortlicher Systemplaner Anpassungen vornimmt, bevor eindeutig geklärt ist, welche Auswirkungen diese Anpassung auf andere Systemteile haben könnte. Nach der Durchführung von Anpassungen müssen die betreffenden Arbeitsvorgänge wiederholt werden, um festzustellen, ob die geplanten Funktionen und Leistungen nun einwandfrei gegeben sind. Bewerten meint auf einer dritten Ebene, die Erreichung der Formalziele (vgl. Lerneinheit FORMZ) zu überprüfen. Während das Bewerten der Funktionen und Leistungen bereits durch einen gründlichen Abnahmetest während der Installierung erfolgen kann, ist ein realistisches Bewerten der Formalziele (wie Produktivität, Qualität und Wirtschaftlichkeit) erst nach einem Erfahrungszeitraum von mehreren Monaten möglich. Schließlich soll auf eine vierte Ebene des Bewertens hingewiesen werden, die Ebene des strategischen Informationsmanagements. Hier geht es darum festzustellen, ob die in der Informatik-Planung gesetzten strategischen Ziele erreicht worden sind (vgl. dazu den Band "Informationsmanagement", insbes. Lerneinheiten SZIEL und STRAT). Systemübergabe und Abschlußarbeiten Nach dem Installieren aller Systemteile, nach dem Bewerten der Funktionen und Leistungen und nach dem Anpassen mit dem Ziel der Fehlerbeseitigung wird das Informationssystem als produktiver Teil der Informationsinfrastruktur vom Projektmanagement an das Informationsmanagement übergeben ("Systemübergabe"). Damit ist der Systemplanungsprozeß beendet. Nach der Systemübergabe sind einige Abschlußarbeiten durchzuführen; dazu gehören: • das Erstellen des Abschlußberichts zur Installierung, mit der Bewertung der Ergebnisse der Systemplanung vor dem Hintergrund der Sachziele und der Formalziele; • das Vervollständigen der Dokumentation (vgl. Lerneinheit DOKUM); • das Übergeben sämtlicher Unterlagen an die für das Produktionsmanagement und das Anwendungssystem-Management zuständigen Stellen (vgl. Lerneinheiten ANWEN und PRODM im Band "Informationsmanagement").

DURIN - Durchfiihren der Installierung

371

Forschungsbefunde Willcocks/Lester haben mit empirischen Untersuchungen (mündliche explorative Befragung in 50 Unternehmen, schriftliche Befragung weiterer 50 Unternehmen sowie Follow-up-Befragungen, Untersuchungszeitraum zwischen Dezember 1990 und November 1991) zur Bewertung in der Installierungsphase ("post implementation phase") unter anderem folgendes festgestellt: Die Zufriedenheit mit den verwendeten Bewertungsverfahren und ihren Ergebnissen ist beim Management der Fachabteilungen und bei den Benutzern deutlich geringer als bei den Systemplanern ("IS Professionals"). Die Anzahl der Unternehmen, die Bewertungen durchführen, nimmt mit dem Projektfortschritt ab; insbesondere wird von wesentlich mehr Unternehmen in der Vorstudie im Vergleich zur Installierungsphase bewertet. Ein Zusammenhang zwischen der Art und der Branche der Unternehmen und der Auffassung über die Wirksamkeit der Bewertung konnte nicht festgestellt werden. 20% der Unternehmen bewerten nicht in der Installierungsphase. Gründe, die dafür angegeben wurden, sind: nicht erforderlich; zu hohe Kosten; hält von anderer Arbeit ab; Ergebnisse werden in negativer Weise verwendet; zu bürokratisch. Diese und ähnliche Befunde geben zu der These Anlaß, daß die Unternehmen dazu tendieren, die Kosten für IuK-Projekte als verlorene Kosten ("sunk costs") zu betrachten, sodaß Bewertungen nutzlos sind. Folgende Bewertungsverfahren wurden verwendet (in Klammern die Häufigkeit der Nennungen): Kostenvergleich mit der Vorstudie (83%); Kostenwirtschaftlichkeit (63%); Produktqualität (53%); Verfügbarkeit (49%); Produktivität (44%); Arbeitszufriedenheit (22%) sowie weitere, deutlich seltener verwendete. Häufig verwendet wurde eine Kombination der sechs genannten Bewertungsverfahren (15%), der ersten fünf (15%) und der ersten vier (10%). Methodenverweise Vorgehensweise bei der Installierung (Lerneinheit VINST); Dokumentationsmethoden (Lerneinheit DOKUM); Testmethoden (Lerneinheit TESTM); Wirtschaftlichkeitsanalyse (Lerneinheit WIRTA); Nutzwertanalyse (Lerneinheit NUTZW). Kontrollfragen 1. 2. 3. 4. 5.

Welche Aufgaben sind Gegenstand des Durchführens der Installierung? Was wird beim Durchfuhren der Installierung unter "Installierungstermin" verstanden? Welche Ursachen sind typisch für Abweichungen zwischen den tatsächlichen und den geplanten Funktionen und Leistungen des installierten Informationssystems? Warum ist ein realistisches Bewerten des installierten Informationssystems nicht unmittelbar im Zusammenhang mit dem Durchführen der Installierung möglich? Welche Abschlußarbeiten hat die Planungsgruppe nach der Übergabe des Informationssystems durchzufuhren?

Quellellliteratur Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. A., Oldenbourg Verlag, München/Wien 1992 Krüger, W.: Organisatorische Einführung von Anwendungssystemen. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990, 275 - 288 Willcocks, L. and Lester, St.: How do Organization Evalúate and Control Information Systems Investments? Recent Survey Evidence. In: Avison, D. et al. (Ed.): Human, Organizational, and Social Dimensions of Information Systems Development. Elsevier Science Publishers, NorthHolland et al. 1993,15 - 39

VINST - Vorgehensweise bei der Installierung Lernziele Sie kennen die Vorgehensweise bei der Installierung sowohl im Sinn von Installierungsstrategien als auch von Installierungsmethoden. Sie können - auf der Grundlage systematisch bestimmter Installierungsarten - die Installierungsmethoden ableiten. Sie können mit eigenen Worten die Installierungsarten erläutern und auf Grund ihrer Merkmale alternative Installierungsmethoden beurteilen. Sie wissen, in welchen Situationen und unter welchen Voraussetzungen welche Installierungsstrategie und welche Installierungsmethode zweckmäßig sind. Definitionen und Abkürzungen Bedingung (condition) = eine notwendige Voraussetzung für das Zustandekommen oder für die Entwicklung einer Sache. Bottom-up-Strategie (bottom-up strategy) = eine Strategie, bei der mit der Bearbeitung der Systemteile begonnen wird, die sich auf der untersten Ebene des hierarchisch gegliederten Systems befinden. Easiest-First-Strategie (easiest-first strategy) = eine Strategie, bei der zunächst jene Aufgaben bearbeitet werden, welche ohne große Probleme lösbar sind; sie soll gewährleisten, daß möglichst viele Teile eines Systems in einer begrenzten Zeit realisiert werden. Installierungsstrategie (installation strategy) = die grundsätzliche Art und Weise des Vorgehens bei der Einfügung eines neu geschaffenen Informationssystems in die bestehende Informationsinfrastruktur. Istzustand (current system) = die Gesamtheit aller organisatorischen Regelungen eines bestehenden Informations- und Kommunikationssystems. Konfiguration (configuration) = eine Menge von Komponenten (z.B. Hardware und Software), die in ihrer Wirkungsweise und in ihren Schnittstellen aufeinander abgestimmt sind und gemeinsam eine vorgegebene Aufgabe erfüllen. Leerkosten (dead costs) = der Teil der fixen Kosten, der nicht durch die Nutzung der sie verursachenden Betriebsmittel abgedeckt ist. Merkmal (characteristic) = die Eigenschaft eines Objekts, die es kennzeichnet und von anderen Objekten unterscheidet. OE (OD) = Abkürzung für Organisationsentwicklung. Rekonfiguration (re-configuration) = die nur graduelle, nicht grundlegende Veränderung einer Konfiguration. Risiko (risk) = die Wahrscheinlichkeit des Eintretens eines unerwünschten Ereignisses (einer "Bedrohung") in einem bestimmten Zeitraum und der mit dem Ereignis verbundene Schaden, also Wahrscheinlichkeit mal Schadenshöhe. SAP = Firmenname eines Software-Hauses in D-69185 Walldorf. Sollzustand (target system) = die Gesamtheit aller organisatorischen Regelungen eines geplanten Informationssystems. Strategie (strategy) = die Planung und Durchführung einer Vorgehensweise im großen Rahmen. Top-down-Strategie (top-down strategy) = die Umkehrung der Bottom-upStrategie.

VINST - Vorgehensweise bei der Installierung

373

Strategien und Methoden der Installierung Die Vorgehensweise bei der Installierung beschreibt zunächst nur "die Art und Weise des Vorgehens" bei der Durchführung der Aufgaben der Installierung (vgl. Lerneinheit ZAMIN). Spricht man von Installierungsstrategie, dann meint man die Planung und Durchführung der Installierung "im großen Rahmen"; spricht man von Installierungsmethode, dann meint man die Planung und Durchführung im Detail. "Strategie" und insbesondere "Methode" implizieren die Forderung nach Einheitlichkeit der Vorgehensweise, also nach Wiederholbarkeit der gleichen Vorgehensweise bei verschiedenen IuK-Projekten, die unterschiedliche Informationssysteme zum Gegenstand haben, in unterschiedlichen Organisationen und/oder zu unterschiedlichen Zeitpunkten stattfinden. Wiederholbarkeit setzt voraus, daß ein bestimmtes Maß an Strukturierung und Formalisierung gegeben ist. Bezüglich der Installierungsmethode erfolgt dies durch drei Maßnahmen: • durch Gliederung der Installierung nach sachlichen, zeitlichen und qualitativen Merkmalen in Installierungsarten; • durch Definition der Installierungsarten; • durch zweckmäßige Kombination von Installierungsarten zu Installierungsmethoden. Installierungsstrategien In der Organisationsforschung wird über drei Strategien berichtet, die für die Installierung zur Verfügung stehen: "Strategie des Bombenwurfs", "Lernstrategie" und "Strategie der evolutorischen Systemgestaltung". • Bombenwurfstrategie: Sie basiert auf der Top-down-Strategie. Ohne Partizipation wird unter Geheimhaltung ein Konzept entwickelt, das dann unter Anwendung von Machtmitteln schlagartig und unwiderruflich eingeführt wird. Erst im Anschluß daran wird das Konzept mit Partizipation weiter entwickelt. Alle wesentlichen Entwurfsentscheidungen sind jedoch bereits gefallt und prinzpiell nicht widerrufbar. • Lernstrategie: Sie basiert auf der Bottom-up-Strategie und dem OE-Ansatz und zielt auf einen Prozeß des Lernens durch die Betroffenen ab. Der sehr hohe Partizipationsgrad soll eine umfassende Problemanalyse und Lösungssuche bei hoher Akzeptanz ermöglichen. Entscheidender Nachteil dieser Strategie ist, daß sie die Fähigkeit der Betroffenen zur Bewältigung komplexer Probleme in kollektiven Entscheidungsprozessen voraussetzt. • Strategie der evolutorischen Systemgestaltung: Sie verbindet die Vorteile der Lernstrategie mit einer Vorgehensweise, die mit der spezifischen Situation der Installierung abgestimmt ist. Bezüglich des Partizipationsgrads wird von "geführter Partizipation" gesprochen, wobei auch das Eingriffsniveau des Managements der Situation angepaßt wird. Welche Strategie gewählt wird, hängt von den technischen, organisatorischen und personellen Rahmenbedingungen ab, die für ein IuK-Projekt bestimmend sind. Unabhängig davon kann generell gesagt werden, daß die Strategie des Bombenwurfs im allgemeinen nicht zweckmäßig ist. Begründung dafür ist, daß System-

374

Methoden und Techniken der Installierung

planung ein kooperativer und kreativer Arbeitsprozeß ist (vgl. Lerneinheit PROSP), der durch partizipationsfördernde Methoden und Werkzeuge unterstützt wird (vgl. Lerneinheit PROTY); damit ist die Strategie des Bombenwurfs nicht vereinbar. Installierungsarten Während sich die Installierungsstrategien an personellen Gesichtspunkten orientieren, berücksichtigen die Installierungsarten (und die daraus gebildeten Installierungsmethoden) sachliche, zeitliche und qualitative Merkmale. Beide sind daher keine Alternativen, sondern Ergänzungen einer zweckmäßigen Vorgehensweise. • Sachliche Merkmale charakterisieren das Verhältnis des in die Installierung einbezogenen Systemteils zum Gesamtsystem. • Zeitliche Merkmale charakterisieren das Verhältnis zwischen dem Zeitpunkt des Beendens des Istzustands und dem Zeitpunkt des Einfuhrens des Sollzustands. • Qualitative Merkmale charakterisieren die Art des Übergangs vom Istzustand zum Sollzustand. Abbildung VINST-1 gibt einen Überblick über die nach sachlichen, zeitlichen und qualitativen Merkmalen gegliederten Installierungsarten. Eine Installierungsmethode wird durch ein sachliches, ein zeitliches und ein qualitatives Merkmal gebildet. Bei den angegebenen 2x2x2 Installierungsarten ergeben sich acht verschiedene Installierungsmethoden; nicht alle sind sinnvoll. Wegen der Redundanz, welche die Darstellung aller Installierungsmethoden bedingen würde, werden nachfolgend nur die Installierungsarten der Abbildung VINST-1 erläutert und mit ihren Vorteilen und Nachteilen beschrieben. Gliederungsmerkmal Sachlich Zeitlich Qualitativ

Installierungsart Gesamtumstellung (Totalumstellung) Schrittweise Umstellung (Teilumstellung) Stichtagsumstellung (Direktumstellung) Parallelumstellung Sofortige Umstellung auf den Sollzustand Stufenweise Umstellung auf den Sollzustand

Abb. VINST-1: Gliederungsmerkmale und Installierungsarten

Gesamtumstellung Gesamtumstellung (auch: Totalumstellung) heißt, daß alle Teilprojekte mit allen in diesen enthaltenen Anwendungsaufgaben in vollem Umfang "gleichzeitig" installiert werden. Dabei bezieht sich "gleichzeitig" sinnvollerweise nicht auf einen Zeitpunkt, sondern - auf Grund des Arbeitsumfangs - immer auf einen Zeitraum, der allerdings so kurz wie möglich gehalten wird und in dem die Installierungsaufgaben ohne planmäßige Unterbrechung abgewickelt werden. Der Ge-

VINST - Vorgehensweise bei der Installierung

375

samtumfang der Teilprojekte und der in diesen enthaltenen Anwendungsaufgaben bezieht sich auf den gesamten Umfang des gegenständlichen IuK-Projekts. Vorteile der Gesamtumstellung sind: Die vorhandenen Basissysteme werden "sofort" im geplanten Umfang produktiv genutzt, Leerkosten werden minimiert; da das Gesamtsystem "sofort" installiert wird, sind keine besonderen Vorkehrungen für die Schnittstellen zwischen den einzelnen Teilprojekten und Anwendungsaufgaben erforderlich. Schnittstellen verbrauchen nicht nur Zeit und verursachen Kosten, sondern sind auch Risikoquellen der Umstellung. Nachteile der Gesamtumstellung sind: Punktuell hohe Anforderungen an die Ressourcen, insbesondere an das Unterstützungspersonal der IKS-Abteilung; Belastung der Benutzer durch massiv auftretende Installierungsaufgaben, die neben den laufenden Arbeitsaufgaben bewältigt werden müssen; die sukzessive Einarbeitung von Benutzern durch andere Benutzer kann kaum zur Anwendung kommen; es liegen keine systematisch aufbereiteten Erfahrungen mit der Installierung umfangreicher Gesamtsysteme vor, die zur Vermeidung von Installierungsschwierigkeiten planmäßig genutzt werden könnten. Eine Gesamtumstellung ist daher nur empfehlenswert, wenn folgende Bedingungen (gemeinsam) vorliegen: • Das Gesamtsystem ist nicht zu groß. • Der Istzustand befindet sich bereits auf einer organisatorisch hohen Stufe (z.B. bei Rekonfiguration), sodaß der Arbeitsaufwand für die Installierung und der daraus folgende Unterstützungsaufwand gering sind. • Die Feinprojektierung ist für alle Teilprojekte und Anwendungsaufgaben abgeschlossen. Für die beiden zuerst genannten Bedingungen gibt es keine präzisen, quantifizierbaren Angaben (z.B. wie die Systemgröße gemessen werden kann). Schrittweise Umstellung Schrittweise Umstellung (auch: Teilumstellung) heißt, daß alle Teilprojekte mit mehreren, einzelnen oder gar nur mit Teilen von Anwendungsaufgaben "gleichzeitig" installiert werden. Die Installierung des Gesamtsystems erfolgt also durch sukzessive, planmäßige Installierung von Systemteilen. Bei der Bildung zweckmäßiger Systemteile geht man in der Regel vom Teilprojekt Datensystem aus. Darin kommt die Bedeutung des datenorientierten Ansatzes der Systemplanung (vgl. Lerneinheit VGROB) auch für die Installierung zum Ausdruck. Bezüglich der Vorteile der schrittweisen Umstellung kann auf die Nachteile der Gesamtumstellung, bezüglich der Nachteile der schrittweisen Umstellung auf die Vorteile der Gesamtumstellung verwiesen werden. Daraus folgt, daß sich eine schrittweise Umstellung empfiehlt, wenn die Systemgliederung so erfolgen kann, daß die schrittweise zu installierenden Systemteile in sich relativ abgeschlossen sind und - zumindest zeitweise, also über den Installierungszeitraum hinweg selbständig "lebensfähig" sind, ohne daß aufwendige Installierungsvorkehrungen für die Beherrschung der Schnittstellen getroffen werden müssen.

376

Methoden und Techniken der Installierung

Eine schrittweise Umstellung wirft das Problem der Festlegung der Installierungsreihenfolge für die Systemteile auf, das mit der Integration der Informationssysteme zunimmt. Dazu sind folgende Hinweise von Bedeutung: • Systemteile, deren Funktionsfähigkeit vom Vorhandensein anderer Systemteile abhängt, können erst nach diesen installiert werden. • Die Installierung soll zeitlich so gewählt werden, daß zwischen der Installierung einzelner Systemteile eine Konsolidierungsphase liegt, in der Fehler erkannt und beseitigt werden können. • Wo möglich, sollte die Easiest-First-Strategie angewendet werden, um schnell Installierungserfahrungen zu sammeln. Stichtagsumstellung Stichtagsumstellung (auch: Direktumstellung) heißt, daß zu einem festgelegten Zeitpunkt bzw. zum Zeitpunkt des Eintretens eines bestimmten Ereignisses (vgl. Lerneinheit DURIN) der Istzustand beendet und der Sollzustand eingeführt wird; es gibt also den einen oder den anderen Systemzustand. Vorteile der Stichtagsumstellung sind: Es entstehen keine Parallelarbeiten; das Überprüfen des Sollzustands, das Abstimmen zwischen Istzustand und Sollzustand sowie das Berichtigen des Sollzustands mit den damit verbundenen terminlichen, räumlichen und personellen Schwierigkeiten ist nicht erforderlich; die von der Umstellung betroffenen Mitarbeiter können sich auf den Sollzustand konzentrieren. Nachteile der Stichtagsumstellung sind: Fehler im Informationssystem werden möglicherweise nicht erkannt und wirken sich auf die realen betrieblichen Prozesse und je nach Anwendungsaufgabe auch auf nur mittelbar Beteiligte aus (z.B. Kunden und Lieferanten); durch Fehler bedingte Arbeitswiederholungen stören den normalen Arbeitsablauf. Ein allmähliches Hineinwachsen der Benutzer in das und Vertrautwerden mit dem neuen System ist nicht möglich. Ein konsequentes Projektmanagement ist erforderlich, um mit den Nachteilen fertig zu werden. Gute Integrationstests sind unabdingbar. Bei einer hohen Qualität der zu installierenden Informationssysteme oder der zu installierenden Systemteile, wie sie durch eine gute Systemplanung oder durch Verwendung ausgereifter Standardlösungen erzielt werden kann, kommen im Regelfall die Nachteile der Stichtagsumstellung nicht zum Tragen. Parallelumstellung Parallelumstellung heißt, daß das neue Informationssystem oder Teile davon installiert werden, ohne daß das bestehende Informationssystem gleichzeitig beendet wird. Dies erfolgt erst dann, wenn das neue Informationssystem einwandfrei funktioniert. Bezüglich der Vorteile der Parallelumstellung kann auf die Nachteile der Stichtagsumstellung, bezüglich der Nachteile der Parallelumstellung auf die Vorteile der Stichtagsumstellung verwiesen werden. Daraus folgt, daß die Parallelumstel-

VINST - Vorgehensweise bei der Installierung

377

lung für Informationssysteme bzw. Teile von Informationssystemen mit solchen Anwendungsaufgaben vorzusehen ist, die wegen ihrer Neuartigkeit keine ausreichende Entwicklungsqualität aufweisen, obwohl eine hohe Sicherheit der Ergebnisse gefordert wird. Sofortige Umstellung Sofortige Umstellung auf den Sollzustand heißt, daß alle mit der Installierung des neuen Informationssystems verbundenen Veränderungen vom Istzustand zum Sollzustand "in einem Zug" bewältigt werden. Sie ist dann vorteilhaft, wenn der mit dem Übergang vom Istzustand zum Sollzustand verbundene Unterschied im Qualitätsniveau nicht zu groß ist oder wenn er durch entsprechende Vorbereitungsmaßnahmen (insbes. auf der Benutzerseite) aufgefangen werden kann. Stufenweise Umstellung Stufenweise Umstellung auf den Sollzustand heißt, daß die mit der Installierung des neuen Informationssystems verbundenen Veränderungen vom Istzustand zum Sollzustand über mehrere Zwischenstufen bewältigt werden. Die Zwischenstufen müssen genau festgelegt und so gestaltet sein, daß eine Kontrolle der Zwischenergebnisse möglich ist. Die stufenweise Umstellung ist dann zweckmäßig, wenn qualitativ völlig neue Methoden eingeführt werden, welche umfassende organisatorische Veränderungen erfordern, die durch entsprechende Vorbereitungsmaßnahmen nicht vollständig aufgefangen werden können. Demonstrationsbeispiel Beim Einsatz von integrierter Standardsoftware bietet sich eine Vorgehensweise an, die durch Gesamtumstellung, Stichtagsumstellung und sofortige Umstellung auf den Sollzustand gekennzeichnet ist (sog. "Big-bang"). Erfahrungen der SAP zeigen, daß sich "immer mehr Unternehmen" zum Big-bang, das heißt zum "flächendeckenden Einsatz" der SAP-Software, entscheiden. Abweichungen von dieser Vorgehensweise ergeben sich im Einzelfall auf Grund spezifischer Projektbedingungen (z.B. nicht ausreichende Verfügbarkeit von Projektpersonal). Das von SAP verwendete Vorgehensmodell zur Einfügung von Standardsoftware gliedert sich in die folgenden Phasen: • Durchführung von Vorarbeiten (z.B. Projektplanung), Festlegen von Projektstandards, Grobdesign, Installation, Schulung der Projektmitarbeiter; • Ausprägung der Anwendungsmodule ("Parametrisierung"); • Produktionsvorbereitung, Integrationstest, Benutzerschulung, Datenübernahme, Produktionsstart. Der Schwerpunkt der fachlichen Projektarbeit liegt in der zweiten Phase; sie ist in Abschnitte gegliedert. Nach jedem Abschnitt werden die Arbeitsergebnisse dem Lenkungsausschuß vorgelegt, der über das weitere Vorgehen entscheidet. Aufgabenverweise Vorbereiten der Installierung (Lerneinheit VORIN); Durchführen der Installierung (Lerneinheit DURIN).

378

Methoden und Techniken der Installierung

Kontrollfragen 1. 2. 3. 4. 5.

Nach welchen Strategien kann bei der Installierung vorgegangen werden? Welcher Zusammenhang besteht zwischen Installierungsmethoden und Installierungsarten? Worin unterscheidet sich Gesamtumstellung von schrittweiser Umstellung? Worin unterscheidet sich Stichtagsumstellung von Parallelumstellung? Worin unterscheidet sich sofortige Umstellung von stufenweiser Umstellung?

Quellenliteratur Boll, M.: Prozeßorientierte Implementation des SAP-Softwarepaketes. In: WIRTSŒAFISINFCRMA3IK 5/1993, 418 -423 Krüger, W.: Organisatorische Einführung von Anwendungssystemen. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990, 275 - 288 Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989

DAKON - Methoden der Datenkonvertierung Lernziele Sie kennen die Aufgaben der Datenkonvertierung und können diese zu einem Prozeß der Datenkonvertierung ordnen. Sie kennen die Methoden der Datenkonvertierung und können beurteilen, welche Methoden unter welchen Bedingungen angewendet werden sollen. Sie wissen, welche Bedeutung die Datenmigration im Zusammenhang mit der Installierung hat und kennen die für die Datenmigration verwendbaren Migrationsstrategien. Definitionen und Abkürzungen Aktualisierung (updating) = das Ändern eines Informationssystems (z.B. das Ändern und/oder Erweitern der Datenstruktur). Bestandsdaten (inventory data) = die Ausgabedaten eines Verarbeitungsprozesses, die im Verarbeitungsprozeß verändert wurden und in einem zeitlich nachfolgenden Ablauf des gleichen Verarbeitungsprozesses als Eingabedaten verwendet werden können. Datenintegrität (data integrity) = die zusammenfassende Bezeichnung für Datenkonsistenz, Datensicherheit und Datenschutz. Datenkomprimierung (data compression) = die Reduzierung des Datenbestands einer Datenbasis durch das Beseitigen von Redundanz. Datenkonvertierung (data Converting) = das Umsetzen oder Umwandeln von Daten (z.B. von einem Datenträger A auf einen Datenträger B). Datenmigration (data migration) = die im Zusammenhang mit einer Migration erforderliche Umsetzung von Datenbeständen (z.B. von einem hierarchischen auf ein relationales Datenbanksystem). Datenspiegelung (data shadowing) = die Parallelaufzeichnung von Daten auf mehreren (i.a. zwei), physikalisch voneinander unabhängigen Speichern. Migration (migration) = der koordinierte Übergang von einer bestehenden Plattform auf eine Zielplattform (z.B. von einem proprietären System auf ein offenes System). Primärdaten (source data) = die Eingabedaten eines Verarbeitungsprozesses, die über einen Datenerfassungsprozeß aus den realen betrieblichen Prozessen nach den Anforderungen dieses Verarbeitungsprozesses entnommen werden. Prüfliste (check list) = eine Methode zur Überprüfung von Systemeigenschaften mit dem Zweck, Systemmängel ("Schwachstellen") aufzudecken. Releasewechsel (release change) = das planmäßige Ersetzen eines Systemzustands A durch einen verbesserten (z.B. in der Funktionalität erweiterten) Systemzustand B. Reorganisation (reorganization) = das Bereinigen von Datenbeständen (z.B. das physische Löschen von zur Löschung vorgemerkten Datensätzen). Szenario (scenario) = die Darstellung eines möglichen Ablaufs, der durch mehrere, miteinander in Beziehung stehende Ereignisse gesteuert wird, oder die Darstellung des zukünftigen Zustands eines Systems. Synonym: Zukunftsbild. Stammdaten (master data) = die Eingabedaten einer Folge von Datenverarbeitungsprozessen, die durch diese nicht verändert werden.

380

Methoden und Techniken der Installierung

Aufgaben der Datenkonvertierung Die Datenkonvertierung ist eine Tätigkeit der datentechnischen Vorbereitung, die sich unmittelbar an die Feinprojektierung der Teilprojekte anschließt (vgl. Lerneinheit VORIN). Sie ist dann erforderlich, wenn die Daten in einem Datenformat vorliegen, das mit dem Datenformat des zu installierenden Datensystems nicht übereinstimmt. Dies ist beispielsweise der Fall, wenn • die Daten maschinell nicht verarbeitbar sind (weil sie z.B. bisher auf Karteien geführt werden); • die Daten zwar auf einem maschinell verarbeitbaren Datenträger gespeichert sind, das Datensystem jedoch die Verwendung eines anderen Datenträgers erfordert (z.B. Direktzugriffsspeicher statt sequentieller Speicher); • Änderungen und/oder Erweiterungen in den Datensätzen eine Umordnung der Datenfelder mit oder ohne Wechsel des Datenträgers notwendig machen; • die Zusammenlegung oder Aufteilung von Dateien erforderlich ist; • die Datenstruktur grundlegend verändert wird (z.B. beim Übergang von einem konventionellen Dateisystem auf ein relationales Datenbanksystem). Wichtige Tätigkeiten der Datenkonvertierung sind: • das Feststellen der zu konvertierenden Daten; • das Zusammenstellen aller vorhandenen Daten und ihrer Charakteristiken (physischer Aufbau, logischer Zusammenhang der Daten, Schnittstellen, Zugriffsmethoden, Zugriffsberechtigungen); • das Festlegen der Konvertierungsmethoden; • das Festlegen von Dokumentationsrichtlinien für die alten und für die neuen Daten sowie für jede durchgeführte Konvertierung ("Konvertierungslauf'); • das Feststellen der Verträglichkeit des derzeit verwendeten Datenträgers mit dem zu verwendenden Datenträger; • das Festlegen der Anforderungen an die Konvertierungsprogramme; • das Festlegen der Reihenfolge der Konvertierung; • das Festlegen der Verfahren zur Aufrechterhaltung der Aktualität der zu konvertierenden Daten; • das Entwickeln oder Einführen von Konvertierungsverfahren. Prozeß der Datenkonvertierung Der Prozeß der Datenkonvertierung kann durch folgende Arbeitsschritte beschrieben werden: • Erster Arbeitsschritt: Sammeln der zu konvertierenden Daten. Bei vielen Installationen müssen die zu konvertierenden Daten von nicht maschinell verarbeitbaren Datenträgern (z.B. Karteien, Belege) zusammengetragen werden. In anderen Fällen ist nur die Ergänzung der bereits auf maschinell verarbeitbaren Datenträgern geführten Daten erforderlich. Für das Zusammenfassen und Aufbereiten dieser Daten werden Konvertierungsprogramme benötigt. • Zweiter Arbeitsschritt: Durchführen der Datenkonvertierung. Daten, die auf nicht maschinell verarbeitbaren Datenträgern vorliegen, werden erfaßt. Diese oder bereits in maschinell verarbeitbarer Form vorliegende Daten

DAKON - Methoden der Datenkonvertierung

381

werden mit einem Standard-Dienstprogramm oder mit einem individuellen Konvertierungsprogramm ("Umsetzprogramm") auf die vorgesehenen Speichermedien konvertiert. • Dritter Arbeitsschritt: Überprüfen der konvertierten Daten. Dadurch soll erreicht werden, daß die konvertierten Daten vollständig und richtig erfaßt wurden. Dazu werden sie ausgedruckt oder am Bildschirm angezeigt und von der Fachabteilung überprüft, die für diese Daten verantwortlich ist. Methodisch erfolgt dies durch Abstimmkreise und Stichproben; bei letzteren wird der Inhalt der Datensätze im Detail mit den Erfassungsunterlagen verglichen. Die in Fehlerprotokollen festgehaltenen Fehler werden in einem zweiten Konvertierungslauf oder am Bildschirm korrigiert. Es ist darauf zu achten, daß alle Fehlerprotokolle vollständig bearbeitet werden. • Vierter Arbeitsschritt: Pflege der konvertierten Daten. Die Datenkonvertierung erfolgt meist in einem Zeitraum von mehreren Wochen vor dem Start der Verarbeitung nach der neuen Arbeitsorganisation. Daher müssen konvertierte Datenbestände bis zum Start der Verarbeitung und parallel zur bestehenden Arbeitsorganisation gepflegt werden. Dafür ist ein Änderungsdienst in der für die Daten verantwortlichen Fachabteilung einzurichten. Methoden der Datenkonvertierung Beim Konvertieren der Dateien für Stamm- und Bestandsdaten bestehen meist folgende Probleme, deren Lösung durch Anwendung geeigneter Methoden unterstützt werden soll: • Die konvertierten Daten müssen zu einem bestimmten Zeitpunkt in einem verarbeitungsfähigen Zustand (z.B. für das Testen der Anwendungsprogramme) zur Verfügung stehen. • Die konvertierten Daten müssen zum Zeitpunkt des Starts der Verarbeitung nach der neuen Arbeitsorganisation den aktuellen Zustand der Stamm- und Bestandsdaten abbilden. Folgende Methoden zur Datenkonvertierung können unterschieden werden: permanente Datenkonvertierung, schrittweise Datenkonvertierung und Datenkonvertierung an einem Stichtag. Permanente Datenkonvertierung: Stamm- und Bestandsdaten werden laufend (z.B. bei Entstehen der Datensätze) konvertiert. Diese Methode wird vor allem dann angewendet, wenn sich Daten über die Zeit stark verändern (z.B. die Auftragsdatei bei kurzen Durchlaufzeiten der Aufträge). Kurz vor dem Zeitpunkt der Aufnahme des Produktionsbetriebs mit dem neuen Informationssystem werden die noch nicht erfaßten Datensätze "nachgezogen". Schrittweise Datenkonvertierung: Die Daten werden in vorher festgelegten Zeitabständen nacheinander konvertiert. Der Zusammenhang mit anderen, eventuell noch nicht konvertierten Daten muß berücksichtigt werden (Datenintegrität, Schnittstellen zu anderen Informationssystemen). Eine Minimierung des Pflegeaufwands ist bei Beachtung folgender Grundsätze möglich:

382

Methoden und Techniken der Installierung

• Daten, die wenig Änderungen bis zur Aufnahme des Produktionsbetriebs mit dem neuen Informationssystem erwarten lassen, werden zuerst konvertiert. • Daten, die bis zur Aufnahme des Produktionsbetriebs mit dem neuen Informationssystem Änderungen in einem erheblichen Umfang erwarten lassen, werden zuletzt konvertiert. Datenkonvertierung an einem Stichtag: Alle Daten werden an einem Stichtag konvertiert. Diese Methode muß dann angewendet werden, wenn die vorhandenen Daten durch den Einsatz eines neuen Basissystems (das meist nur zu einem Stichtag in Produktion genommen werden kann) konvertiert werden müssen. Auch bei der Umstellung eines Nummernsystems (vgl. Lerneinheit NUMSY) und/oder bei der Änderung von Schlüsselbegriffen wird die Datenkonvertierung an einem Stichtag empfohlen. Bei allen Methoden der Datenkonvertierung ist es sinnvoll, mit Prüflisten die Vollständigkeit und die Richtigkeit der Datenkonvertierung zu verfolgen. Besondere Aufmerksamkeit erfordert dabei die Aufrechterhaltung vorhandener Schnittstellen zu anderen Informationssystemen. Sinnvoll kann es auch sein, die bestehenden Datenbestände vor der Konvertierung zu "bereinigen" und zu reorganisieren. Alle zur Datensicherung notwendigen Programme sind an die konvertierten Datenformate anzupassen. Häufig wird bei Datenkonvertierungen die Konvertierung von Stamm- und Bewegungsdaten, die bereits auf Archivdatenbeständen ausgelagert worden sind, vergessen. Unter Umständen sind auch Datenbestände auf PCs durch die Datenkonvertierung betroffen. Datenmigration Ist die teilweise oder sogar vollständige Änderung der logischen und/oder physischen Repräsentation von Daten erforderlich, wird dies als Datenmigration bezeichnet. Folgende Szenarien der Datenmigration sind erkennbar: • Zusammenführen von (isolierten) Anwendungssystemen zu integrierten Informationssystemen. Zur Vermeidung von Inkonsistenzen und Redundanzen im Datensystem müssen die getrennt entwickelten und implementierten Datenbasen zusammengeführt und mit dem unternehmensweiten Datenmodell abgestimmt werden. • Ablösung proprietärer Systeme durch offene Systeme. Dies erfordert die Überführung nicht-relationaler (zumeist hierarchischer) in relationale Datenstrukturen. • Downsizing von monolithischen Architekturen. Es handelt sich um einen Spezialfall der Ablösung proprietärer Systeme durch offene Systeme, wobei von Host-Systemen auf verteilte Systeme übergegangen wird. Dies erfordert die Migration der Daten in relationale Strukturen und deren Verteilung. • Einführung von Standardsoftware. Moderne Standardsoftware basiert auf offenen Systemen. Ihre Eingliederung in bestehende, meist proprietäre Systeme ist ohne Abgleich der verwendeten Datenstrukturen nicht möglich. Unabhängig davon, welches dieser Szenarien im Zusammenhang mit der Installierung eines neuen Informationssystems vorliegt, haben sich in der Praxis drei Migrationsstrategien herausgebildet:

DAKON - Methoden der Datenkonvertierung

383

• die vollständige Datenmigration; • die schrittweise Datenmigration mit temporärer Datenkoexistenz; • die systemkonforme Spiegelung von Datenbeständen. Vollständige Datenmigration: Die Datenbestände und Datendefinitionen der Quellumgebung werden nach logischen Abbildungsregeln ("Konvertierungsregeln") und mit Hilfe von Extrakt- und Ladeprogrammen ("Migratoren") in die Datenstruktur der Zielumgebung überführt. Auch die prozeduralen Datenbankaufrufe der Anwendungsprogramme müssen in die Zielumgebung konvertiert werden. Da es nicht immer zweckmäßig ist (z.B. wegen der Sicherheit des Produktionsbetriebs) bzw. möglich ist (z.B. wegen knapper Personalkapazität), alle Anwendungsprogramme sofort umzustellen, wird über eine Software-Schnittstelle der Zugriff der alten Anwendungsprogramme auf den migrierten Datenbestand ermöglicht. Die Migration der Anwendungsprogramme erfolgt dann schrittweise (vgl. Lerneinheit PRADA). Schrittweise Datenmigration mit temporärer Datenkoexistenz: Es werden schrittweise ausgewählte Anwendungsprogramme und ihre Datenbestände in die neue Architektur migriert, sodaß über den gesamten Migrationszeitraum hinweg zwei Systemkonzepte gültig sind. Da in einer heterogenen Architektur die Datenintegrität nur schwer zu gewährleisten ist, werden die migrierten Daten temporär in der alten Architektur redundant vorgehalten. Über eine SoftwareSchnittstelle können bei Bedarf auch die migrierten Anwendungsprogramme auf die alten Datenbestände zugreifen. Systemkonforme Spiegelung von Datenbeständen: Im Unterschied zu den bisher genannten Migrationsstrategien wird eine andauernde Koexistenz der alten und der migrierten Datenbestände verlangt. Auf die alten Datenbestände greifen die alten, auf die migrierten Datenbestände die neuen Anwendungsprogramme zu. Dazu ist erstens die physische Migration der Daten und zweitens die ständige Abbildung von Wertänderungen durch eine synchrone oder asynchrone Datenspiegelung erforderlich. Bei synchroner Datenspiegelung wird sowohl der alte als auch der migrierte Datenbestand durch das Anwendungsprogramm direkt angesprochen; eine wertändernde Transaktion ist erst dann abgeschlossen, wenn die Wertänderung in beiden Datenbeständen erfolgt ist. Bei der asynchronen Datenspiegelung werden Wertänderungen, die sich durch einen Zugriff auf einen der Datenbestände ergeben, zunächst nur in diesem durchgeführt. Gleichzeitig werden sie in einer Logdatei aufgezeichnet und periodisch an den komplementären Datenbestand übergeben. Aus Gründen der Leistung und Konsistenz soll die Datenspiegelung nur in einer Richtung (vom alten zum migrierten Datenbestand) erfolgen. Jede MigrationsStrategie hat vorübergehend Datenredundanz zur Folge, wobei die redundanten Datenobjekte in zwei oder mehr Datenbasen geführt werden. Jede Transaktion, die auf eine dieser Datenbasen zugreift, muß daher Transaktionen auslösen, mit denen die Konsistenz der Datenobjekte in den anderen Datenbasen gesichert wird. Da die erste dieser Transaktionen erst abgeschlossen werden kann, wenn alle anderen konsistenzerhaltenden Transaktionen abgeschlossen sind, verlängert sich die Antwortzeit entsprechend. Auch die Auswirkung der Migration auf die Speicherkosten darf nicht unberücksichtigt bleiben.

384

Methoden und Techniken der Installierung

Zwar ist es zutreffend, daß Speicher heute "billig" sind; wenn aber große Datenbestände mehrfach geführt werden müssen, können sich erhebliche kostenwirtschaftliche Effekte ergeben. Demonstrationsbeispiel Es wird die Vorgehensweise beim Konvertieren von Datenbeständen gezeigt, die durch den Releasewechsel auf eine neue Version einer Standardsoftware mit einem hohen Anteil an Online-Verarbeitung erforderlich ist. Folgende Arbeitsschritte sind dazu vorgesehen: • Erster Arbeitsschritt: Einrichten eines Testsystems. Das Testen von neuen Funktionen mit geänderten Daten soll (und kann) in den meisten Fällen nicht im produktiven Betrieb erfolgen. Es ist deshalb ein Testsystem einzurichten. Der Bedarf an Externspeicher kann dabei zum Problem werden, weil durch das Testsystem für die Speicherung der Testdaten "vorübergehend" zusätzlicher Speicherbedarf erforderlich ist. • Zweiter Arbeitsschritt: Abschließen des Altsystems. Die Datenbestände müssen für den Produktionsbetrieb gesperrt werden. Zuvor sollen sie - wie im "normalen" Produktionsbetrieb periodisch üblich - bereinigt und reorganisiert werden. Nicht mehr benötigte Daten werden archiviert. • Dritter Arbeitsschritt: Sichern der Datenbestände. Um bei auftretenden Schwierigkeiten (z.B. beim Entstehen fehlerhafter Datenbestände durch Programm- oder Bedienungsfehler) während des Testens und der Installierung jederzeit den "alten Stand" reproduzieren zu können, müssen die Datenbestände vor der Datenkonvertierung gesichert werden. • Vierter Arbeitsschritt: Entladen aller Datenbestände. Bei einem Releasewechsel sind, hervorgerufen durch Verbesserungen und Erweiterungen der Standardprogramme, meistens Änderungen und Erweiterungen der Datenbestände auf Grund von Änderungen der Datenstruktur erforderlich. Zur Vorbereitung der Konvertierung werden die bisher verwendeten Datenbestände auf andere Datenträger entladen. Komprimierte Datenbestände werden dabei dekomprimiert. • Fünfter Arbeitsschritt: Durchführen von Programmanpassungen. Vor dem Konvertieren der Datenbestände werden die zum Releasewechsel erforderlichen Änderungen und Erweiterungen in den Anwendungsprogrammen vorgenommen (vgl. Lerneinheit PRADA). Die meisten Standardprogramme verwenden Tabellen zur Steuerung von Abläufen und zur Verschlüsselung von Daten. Bei der Änderung und Erweiterung der Tabellen ist darauf zu achten, daß für die Konvertierung im Regelfall beide Tabellenversionen (die für die bisherige Version und die für die neue Version) zur Verfügung stehen müssen. • Sechster Arbeitsschritt: Konvertieren der Datenbestände. Die im vierten Arbeitsschritt entladenen Datenbestände werden mit Konvertierungsprogrammen in die geänderte Datenstruktur umgesetzt. Um die Datenintegrität zu erhalten, soll die Konvertierung "zusammengehörender Datenbestände" (z.B. die Stammdaten und die Bewegungsdaten eines Materialwirtschaftssystems) an einem Stichtag durchgeführt werden. • Siebenter Arbeitsschritt: Durchführen von Tests. Alle durch den Releasewechsel notwendig gewordenen Programmänderungen und -erweiterungen

DAKON - Methoden der Datenkonvertierung

385

werden mit den konvertierten Datenbeständen getestet (vgl. Lerneinheit TESTM). Aufgabenverweise Durchführen der Installierung (Lerneinheit DURIN); Entwickeln des Datensystems (Lerneinheit EDASY). Kontrollfragen 1. Welches sind die wichtigsten Tätigkeiten beim Konvertieren von Daten? 2. Welche Methoden zur Datenkonvertierung können angewendet werden? 3. Wie erfolgt die Datenkonvertierung im Zusammenhang mit einem Releasewechsel? 4. Welche "Szenarien für Datenintegration" sind typisch? 5. Welche Migrationsstrategien können verfolgt werden? Quellenliteratur Netze, J. und Seelos, H.-J.: Szenarien und Strategien der Datenmigration. In: WIRTSCHAFTS1NFORMÄIK 4/1993, 320 - 324 Schmückle, W. und Cleve, D.: Konversion - am Beispiel einer Umstellung von IBM/360 DOS auf IBM/370 OS. IBM Nachrichten 207/1971, 835 - 840 und IBM Nachrichten 208/1971, 945 948 Vertiefungsliteratur Dittrich, K. R.: Migration von konventionellen zu objektorientierten Datenbanken: soll man, muß man - oder nicht? In: WIRTSCHAFISINFORMATIK 4/1993, 346 - 352 Hannan, J. (Hrsg.): Ein praktischer Führer für das Datenbank-Management. Verlag Vieweg, Braunschweig/Wiesbaden 1988 Meier, A. et al.: Schutz der Investitionen beim Wechsel eines Datenbanksystems. In: WIRTSCHAFISlNFCRMAnK 4/1993, 331 - 338 Neumann, K. et al.: Eine Portierungsstrategie für ADABAS-Datenbestände und -Anwendungen nach DB2. In: WIRTSCHAFISINFCRMAnK 4/1993, 339 - 345

PRADA - Methoden der Programmadaption Lernziele Sie kennen die Aufgaben der Programmadaption. Sie können Verträglichkeitseinrichtungen und Umstellungseinrichtungen als Methoden der Programmadaption erläutern. Sie können die Auswirkungen von Programmadaptionen beschreiben. Sie wissen, welche Bedeutung die Programmigration im Zusammenhang mit der Installierung hat und in welchem Verhältnis sie zur Datenmigration steht. Definitionen und Abkürzungen ADABAS = ein relationales Datenverwaltungssystem der Software AG. Emulator (emulator) = eine Funktionseinheit, die Eigenschaften eines Systems A auf einem System B so nachbildet, daß für A entwickelte Programme auf B ablaufen (emuliert werden) können, wobei die Daten für A von B akzeptiert und die gleichen Ergebnisse wie auf A erzielt werden. Synonym: Emulierer. Geräteunabhängigkeit (device independence) = die Unabhängigkeit eines Produkts von spezifischen Eigenschaften der Hardware und/oder einer bestimmten Konfiguration. G M D = Akronym für Gesellschaft für Mathematik und Datenverarbeitung, eine Forschungseinrichtung in der Bundesrepublik Deutschland. M O O R E = Akronym für Methoden für objektorientiertes Reengineering; ein Forschungsprojekt der GMD. NATURAL = eine nicht-prozedurale Programmiersprache der 4. Generation, entwickelt von der Software AG. Objektcode (object code) = das von einem Kompilierer oder Assemblierer aus einem Benutzercode erzeugte Maschinenprogramm. Parser (parser) = ein Programm zur syntaktischen Analyse eines Programms (z.B. durch Ermitteln eines Syntax-Baums). Programmigration (program migration) = die im Zusammenhang mit einer Migration erforderliche Umsetzung von Anwendungsprogrammen (z.B. von einer Implementierung in 3GL zu einer Implementierung in 4GL). Simulation (Simulation) = eine Verträglichkeitseinrichtung, bei der ein Simulationsprogramm eine Art Übersetzerfunktion übernimmt. Syntax-Baum (syntax tree) = die Abbildung der syntaktischen Konstrukte eines Programms in Form eines gerichteten Graphen, dessen Kantenmenge eine Hierarchie bildet. Übertragbarkeit (portability) = die Eigenschaft von Programmen, auf ein anderes Datenverarbeitungssystem übertragen werden zu können; eine Form der Software-Kompatibilität. Umstellungstest (changeover test) = ein Test, mit dem anhand typischer Testfalle nachgewiesen werden soll, daß ein durch Programmadaption verändertes Anwendungsprogramm die gleichen Funktionen zur Verfügung stellt wie das ursprüngliche Anwendungsprogramm. Verträglichkeit (compatibility) = die Eigenschaft eines Systems, ohne Anpassungsarbeiten oder Änderungen mit anderen Systemen zusammenarbeiten zu können. Synonym: Kompatibilität.

PRADA - Methoden der Programmadaption

387

Aufgaben der Programmadaption In der Lerneinheit BTECH wird das Entscheidungsproblem Eigenerstellung oder Fremdbezug von Anwendungssoftware behandelt. Bei einer Rekonfiguration besteht häufig ein ähnliches Entscheidungsproblem: Sollen vorhandene Anwendungsprogramme adaptiert oder durch Neuprogrammierung abgelöst werden? Adaptieren von Anwendungsprogrammen heißt: Vorhandene Anwendungsprogramme, die für eine andere Hardware und Systemsoftware geschrieben worden sind, sollen so verändert werden, daß sie auch auf der Hardware und Systemsoftware ablauffähig sind, die neu installiert wird. Im allgemeinen hat Programmadaption zur Folge, daß die Programmlaufzeit drastisch verlängert wird. Dem steht als Vorteil die schnelle Installierung bei geringem Ressourceneinsatz gegenüber. Adaptierte Anwendungsprogramme werden daher meist nur in einer Übergangsphase verwendet und so schnell wie möglich durch neue Anwendungsprogramme ersetzt. Der zeitliche Umstellungsaufwand, der für die Programmadaption erforderlich ist (insbes. Zeitaufwand für Programmierleistungen), kann häufig nur schwer abgeschätzt werden. Methoden der Aufwandsschätzung (vgl. Lerneinheit MEAUF im Band "Informationsmanagement") sind auf Neuprogrammierung ausgerichtet und können bei Programmadaption kaum verwendet werden. Neben der Abschätzung der Programmlaufzeit und des Zeitaufwands für die Umstellung gehört die Beantwortung der folgenden Fragen zu den Aufgaben der Programmadaption: • Welche Umstellungshilfen sind für die betreffende(n) Programmiersprache(n) vorhanden, und welcher Zeitgewinn kann damit erzielt werden? • Sollen eigene Umstellungshilfen entwickelt werden? • Welche Programmteile sind soweit standardisiert, daß sie gemeinsam umgestellt werden können? • Welche Anwendungsprogramme werden durch Anwendungsprogramme des neu geschaffenen Informationssystems überflüssig? • Welche Anwendungsprogramme können durch Standardprogramme ersetzt werden? Methoden der Programmadaption Zum Adaptieren von Anwendungsprogrammen gibt es verschiedene Hilfsmittel ("Methoden"), deren Funktion so beschrieben werden kann: Sie erleichtern den Übergang von einem Datenverarbeitungssystem (Hardware und Systemsoftware) auf ein anderes Datenverarbeitungssystem (des gleichen oder eines anderen Herstellers). Die Methoden der Programmadaption werden in Verträglichkeitseinrichtungen und in Umstellungseinrichtungen gruppiert. Verträglichkeitseinrichtungen ermöglichen es, Anwendungsprogramme unverändert von einem Datenverarbeitungssystem auf ein anderes, unverträgliches Datenverarbeitungssystem zu übernehmen. Folgende methodische Hilfsmittel werden unterschieden: Simulation, Hardware-Verträglichkeit und Emulation.

388

Methoden und Techniken der Installierung

• Simulation: Ein Software-Produkt interpretiert jede einzelne Instruktion des Anwendungsprogramms so, daß sie vom unverträglichen Datenverarbeitungssystem ausgeführt werden kann. Die Ausführung der interpretierten Instruktion erfolgt unmittelbar; das Anwendungsprogramm wird also nicht in ein Objektprogramm des unverträglichen Datenverarbeitungssystems übertragen. Da jede Instruktion bei jedem Programmlauf erneut interpretiert wird, ergeben sich längere Programmlaufzeiten. • Hardware-Verträglichkeit: Darunter werden Hardware-Einrichtungen am unverträglichen Datenverarbeitungssystem verstanden, durch die das Verhalten des Datenverarbeitungssystems, für welches das Anwendungsprogramm geschrieben wurde, simuliert wird. • Emulation: Dabei handelt es sich um eine Kombination der beiden bisher genannten Hilfsmittel. Die zeitraubende Interpretation der Instruktionen wird von hardwarenahen Einrichtungen (Mikroprogramm) erledigt, und die übrige Simulation (z.B. Ein-/Ausgabesteuerung) wird durch ein Emulationsprogramm übernommen. Es wird zwischen Einzelemulation und integrierter Emulation unterschieden. Einzelemulation kann normalerweise nur einen Teil der in einem Datenverarbeitungssystem verfügbaren Hardware nutzen; integrierte Emulation ermöglicht (im Grenzfall) die Ausnutzung aller vorhandenen Systemkomponenten. Im Unterschied zu den Verträglichkeitseinrichtungen verändern Umstellungseinrichtungen das Anwendungsprogramm. Umstellungseinrichtungen sind Umstellungsprogramme, Umstellungshilfsprogramme, Umstellungsroutinen und Umstellungsmakros. • Umstellungsprogramme (auch: Konversionsprogramme) konvertieren aus dem Anwendungsprogramm ein modifiziertes Objektprogramm, das mit dem neuen Datenverarbeitungssystem verträglich ist. • Umstellungshilfsprogramme (auch: Diagnoseprogramme) durchsuchen ein Anwendungsprogramm auf Unverträglichkeiten; diese werden (z.B. auf einer Liste) ausgegeben. Die Beseitigung der Unverträglichkeiten erfolgt durch den Programmierer. • Umstellungsroutinen sind verträgliche Programmteile (Unterprogramme) für häufig auftretende, unverträgliche Programmteile im Anwendungsprogramm. Das Austauschen unverträglicher Programmteile durch Umstellungsroutinen erfolgt durch den Programmierer. • Umstellungsmakros werden unter ihrem im Anwendungsprogramm verwendeten Namen aufgerufen und bewirken die Generierung des Maschinencodes des unverträglichen Datenverarbeitungssystems. Außer den Umstellungsprogrammen sind die genannten Umstellungseinrichtungen im allgemeinen standardmäßig nicht verfügbar; sie müssen von Fall zu Fall entwickelt werden. Konvertierte Anwendungsprogramme müssen wie neu entwickelte Anwendungsprogramme getestet werden, möglichst mit den konvertierten Daten des bisherigen Datensystems oder mit Testdaten, die dem konvertierten Anwendungsprogramm angepaßt sind. Bei mehreren ähnlich aufgebauten Anwendungsprogrammen kann ein Umstellungstest nützlich sein.

PRADA - Methoden der Programmadaption

389

Auswirkungen der Programmadaption Für alle Verträglichkeits- und Umstellungseinrichtungen gilt, wenn auch in unterschiedlichem Umfang, daß der Hauptspeicherbedarf vergrößert und die Programmlaufzeit verlängert wird. Nach Beendigung einer Umstellung sollte daher auf den Einsatz von Verträglichkeits- und Umstellungseinrichtungen verzichtet werden. Eine Umstellung ist erst abgeschlossen, wenn alle Anwendungsprogramme adaptiert worden sind und fehlerfrei laufen und wenn eine sorgfältige Überprüfung der Umstellungsergebnisse stattgefunden hat. In diesem Zusammenhang ist besonders die Systemauslastung zu überprüfen. Ungünstige Programmierung (insbes. der Dateneingabe und -ausgabe) beeinflußt die Laufzeit von datenintensiven Anwendungsprogrammen wesentlich. Ein Wechsel des Betriebssystems kann eine Anpassung der Programmiertechnik erforderlich machen, weil im neuen Betriebssystem andere Werkzeuge zur Verfügung stehen, als sie bisher im Einsatz waren. Programmigration Im allgemeinen ist die Datenmigration der Treiber für die Migration von Programmen (vgl. Lerneinheit DAKON). Das ist wie folgt zu verstehen: Im Zusammenhang mit der Schaffung eines neuen Informationssystems wird für das Datensystem ein relationales Datenbanksystem implementiert. Die vorhandenen Programme können nur unter der Voraussetzung weiterverwendet werden, daß vor-relationale Datenbanksysteme (oder sogar konventionelle Dateisysteme) parallel weitergeführt werden oder daß über eine Software-Schnittstelle der Zugriff der "Altsoftware" auf die relationale Datenbasis ermöglicht wird. Dieser Zustand sollte wegen der Beeinträchtigung der Leistung (z.B. des Antwortzeitverhaltens), der Gefahr der Dateninkonsistenz (verursacht durch Datenredundanz) und/oder des Wartungsaufwands für die Altsoftware so schnell wie möglich beendet werden. Die Altsoftware sollte zügig migriert werden, was im Normalfall heißt, von der Implementierung in einer prozeduralen Programmiersprache (z.B. COBOL) in die einer nicht-prozeduralen Programmiersprache (z.B. NATURAL) überführt werden. Dabei soll nicht nur die Transformation von Programmcode erfolgen, sondern auch die Überarbeitung der Programmstruktur. Dies ist ohne geeignete Verfahren und Werkzeuge nicht möglich. Demonstrationsbeispiel Im Projekt M O O R E der GMD ist folgendes Verfahren für die Migration von COBOL-Programmen in Programme in Object-Oriented Extensions to COBOL vorgesehen (vgl. Abbildung PRADA-1): In der ersten Migrationsphase wird der vorliegende C O B O L - Q u e ü c o d e mit Hilfe eines Scanners und eines Parsers analysiert und in Form eines attributierten Syntax-Baums aufgearbeitet. Der Syntax-Baum enthält alle Informationen über die Struktur des Programms, die verwendeten Dateien und Datennamen bis zu den Kommentaren. Er dient als interne Darstellung des Programms, auf der alle Transformationsarbeiten durchgeführt werden. Die Analyse entspricht den ersten

390

Methoden und Techniken der Installierung

Phasen eines Compilers (syntaktische und semantische Analyse). Für die Realisierung von Scanner und Parser kommen daher Compilergeneratoren-Werkzeuge zum Einsatz. Diese erzeugen, ausgehend von der Grammatik der Zielsprache, Scanner und Parser sowie Funktionen zum Aufbau und zur Bearbeitung des Syntax-Baums. Im Anschluß an die Analyse wird der attributierte Syntax-Baum ausgewertet. Die dabei gewonnenen Ergebnisse (z.B. die in einem Programmsegment benutzten Datenfelder, die aufgerufenen Unterprogramme, die Verweise auf Programmteile, welche die deklarierten Dateien und Datensätze verwenden) werden für die nachfolgende Transformation in den Baum aufgenommen.

c

DesignDokumente

'Attn butierter iln.\-Ba rser) . Scanner/Parser COBOLCode

Modifizierter Syntax-Baum^ CodeV^Generator^x

I

J

( Object- "N yCOBOL-Code)

Abb. PRADA-1: In MOORE vorgesehenes Migrationsverfahren (Quelle: Pflüger et al.)

Grundlage für die zweite Migrationsphase sind der attributierte Syntax-Baum, Entwurfsdokumente sowie weitere Informationen (z.B. der Sachbearbeiter und der Programmierer), die nicht dokumentiert sind. Anhand der im Syntax-Baum abgelegten Informationen über das alte Programm prüft das Transformationswerkzeug, welche Datenfelder zu Attributen einer Klasse zusammengefaßt und welche bereits im Repository abgelegten Klassen dazu verwendet werden können. Mögliche Transformationen werden dem Benutzer vorgeschlagen; er entscheidet, ob die Umsetzung durchgeführt oder ob sie auf Grund des Benutzerwissens oder von Informationen aus den Entwurfsdokumenten modifiziert werden soll. Nachdem die Attribute einer Klasse festgelegt worden sind, wird der Code des alten Programms nach Methoden für diese Klasse durchsucht. Die Auswahl der gefundenen Codesequenzen wird dem Benutzer zur Bestätigung oder Änderung angeboten. Sind die Methoden einer Klasse gefunden, wird die Umsetzung für diese Klasse durchgeführt, indem die entsprechenden Komponenten des SyntaxBaums in objektorientierte Komponenten eines modifizierten Syntax-Baums transformiert werden. Dabei werden die Datendefinitionen zu Attributedefinitionen einer Klasse und die Codesequenzen zu Methodendefinitionen. Die Stellen, an denen die Daten benutzt oder die Codesequenzen aufgerufen wurden, werden durch Methodenaufrufe ersetzt. Alle dazu erforderlichen Anpassungen in den verbleibenden Programmteilen werden automatisch durchgeführt. Die Klassenbildung wird solange fortgesetzt, bis (fast) alle Datenfelder in Klassen als Attri-

PRADA - Methoden ¿1er Programmadaption

391

bute untergebracht und die dazu gehörenden Methoden festgelegt sind. Auf diese Weise wird der Syntax-Baum des alten Programms sukzessiv in einen SyntaxBaum mit objektorientierter Struktur umgesetzt. Da nicht alle Programme in einem Transformationsprozeß umgesetzt werden können, werden Klassen bei ihrer ersten Definition in einem Repository abgelegt. Bei der Umsetzung eines weiteren Programms wird der Benutzer auf vorhandene ähnliche Klassen hingewiesen. Er kann diese Klassen entweder unverändert übernehmen oder sie um zusätzliche Attribute und Methoden ergänzen und dann geändert in das Repository zurückschreiben. Dabei finden Konsistenzprüfungen statt, damit bereits umgesetzte Programme auch nach Änderungen an Klassen, die von ihnen benutzt werden, lauffahig bleiben. Der Benutzer kann zu einer vorhandenen Klasse eine Unterklasse definieren, ohne die Klasse zu ändern. Das Bilden einer Oberklasse aus vorhandenen Klassen ist möglich. Abbildung PRADA-2 veranschaulicht den Transformationsprozeß.

f L

alter ASB

]

J

andere Ln) Information

[ Repository ) Auswahl ähnlicher Klassen

f Klassen, Attribute ) \Methoden und Objekte/

Einfügen oder , Ändern von Klassen ,

Benutzung-Schnittstelle

Bestätigung .der Tansaküon

Dialog mir dem Benutzer Änderungen und ErgänzungenJ

Transformation des Codes Neuer ASB

T

J

Abb. PRADA-2: Tranformationsprozeß in MOORE (Quelle: Pflüger et al.)

Neuartig an diesem Verfahren ist nicht nur die Integration von Reverse Engineering und Objektorientierung, sondern auch die interaktive, inkrementelle Transformation des strukturierten Codes in eine objektorientierte Form. Dies ermöglicht es dem Benutzer, den Transformationsprozeß zu verfolgen und ihn zu

392

Methoden und Techniken der Installierung

beeinflussen. Dies gibt ihm Gelegenheit, die für die Transformation erforderlichen Änderungen nachzuvollziehen und die Programmstrukturen der objektorientierten Programme kennen zu lernen. Forschungsbefunde Filbig/Kernler berichten über Erfahrungen aus einer Fallstudie über die Programmigration von COBOL (mit VSAM) auf NATURAL (mit ADABAS) unter anderem folgendes: Die Anzahl der Programme hat sich drastisch erhöht (von etwa 700 auf 1200), was auf die konsequente Modularisierung zurückzuführen ist. Die Anzahl der Zeilen Code je Programm hat sich drastisch verringert (von zwischen 80 und 6000 auf durchschnittlich 150), was auf die Mächtigkeit der Befehle von NATURAL zurückzuführen ist. Die Systemzuverlässigkeit konnte deutlich gesteigert werden (von einem Absturz pro Woche auf null). Überstunden bei den Software-Entwicklern wurden abgebaut. Die Programme sind nach der Umstellung auf NATURAL vom Entwickler unabhängig; sie sind von jedem Software-Entwickler wartbar. Die Arbeitsorganisation der SoftwareEntwickler konnte verbessert werden, insbesondere wurde die Arbeitsteiligkeit reduziert. Das Qualitätsbewußtsein wurde gestärkt. Aufgabenverweise Durchführen der Installierung (Lerneinheit DURIN); Entwickeln des Methodensystems (Lerneinheit EMESY). Kontrollfragen 1. 2. 3. 4. 5.

Welche Methoden der Programmadaption werden unterschieden? Welcher Unterschied besteht zwischen Simulation und Emulation? Welche Umstellungseinrichtungen gibt es? Welche Kriterien können zur Lösung des Entscheidungsproblems "Neuprogrammierung oder Programmadaption" verwendet werden? Wodurch ist Programmigration gekennzeichnet; in welchem Verhältnis steht sie zur Datenmigration?

Quellenliteratur Filbig, G. und Kernler, H.: Eine Migration von COBOL/VSAM zu NATURAL/ADABAS. In: WIRISCHAFTSINFCRMAnK 4/1993, 325 - 330 Pflüger, C. et al.: Umstellung alter COBOL-Programme in objektorientierte Systeme. In: WIRTSCHAFTSINFCRMAUK 4/1993, 353 - 359 Vertiefungsliteratur Pietsch, M.: PAREUS-RM - ein Tool zur Unterstützung der Konfiguration von PPS-Parametem im SAP-System R/2. In: WIRTSCHAFTE INFORMATIK 5/1993,434 - 445

Literaturverzeichnis Abel, H. und Schmölz, W.: Datensicherung für Betriebe und Verwaltungen. Sicherungsmaßnahmen in der modernen Informationstechnik - Erfahrungen aus der Praxis. Verlag Beck, München 1987 Ackermann, A.: Empirie des Softwareentwurfs: Richtlinien und Methoden. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988, 253 - 276 Ackermann, D.: Handlungsspielraum, mentale Repräsentation und Handlungsregulation am Beispiel der Mensch-Computer-Interaktion. Dissertation Universität Bern, Bern 1987 Ackermann, D. und Ulich, E. (Hrsg.): Software-Ergonomie '91. Benutzerorientierte SoftwareEntwicklung. Verlag Teubner, Stuttgart 1991 Al-Zobaidie, A. and Grimson, J. B.: Expert Systems and Database Systems - how can they serve each other? In: Expert Systems 2/1987,30 - 37 Alioth, A.: Entwicklung und Einfuhrung alternativer Arbeitsformen. Schriften zur Arbeitspsychologie Bd. 27, Verlag Huber, Bern 1980 Ambichl, E. und Gappmaier, M.: Nicht vernetzte PCs versus Lokale Netzwerke - eine Vergleichsstudie. In: Information Management, 1/1989, 38 - 43 Ambichl, E. und Heinrich, L. J.: Leistungsbewertung dialogorientierter Datenbanksysteme in Client/Server-Architekturen. In: Information Management 3/1992, 2 4 - 3 1 Apple Computer (Ed.): Human Interface Guidelines - The Apple Desktop Interface. AddisonWesley Pubi. Company, Reading/MA. et al. 1988 Arbeitskreis Software-Ergonomie Bremen: Eigenprogrammierung als Unterstützung individueller Arbeitsgestaltung. In: Ackermann, D. und Ulich, E. (Hrsg.): Software-Ergonomie '91. Benutzerorientierte Software-Entwicklung. Verlag Teubner, Stuttgart 1991, 262 - 271 Balzert, H.: Die Entwicklung von Software-Systemen. Prinzipien, Methoden, Sprachen, Werkzeuge. B. I. Wissenschaftsverlag, Mannheim et al. 1982 Balzert, H. et al.: Fenstersysteme im Vergleich - Architektur, Leistungsfähigkeit und Eignung für die Anwendungsentwicklung. In: Bullinger, H.-J. (Hrsg.): Software-Ergonomie '85. MenschComputer-Interaktion. Stuttgart 1985, Verlag Teubner, 42 - 52 Barth, H.: Grundlegende Konzepte von Methoden- und Modellbanksystemen. In: Angewandte Informatik 8/1980, 301 - 309 Bartölke, K.: Teilautonome Arbeitsgruppen. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Poeschel Verlag, Stuttgart 1992, 2384 - 2399 Bauer, F. L.: Kryptologie. Methoden unmd Maximen. Springer Verlag, Berlin et al. 1993 Bauer, I. and Schwab, Th.: Propositions on Help-Systems. In: Angewandte Informatik 1/1987, 23-29 Bechtel, M. et al.: Datenmodellierung bei der Bühler AG, Uzwil (Schweiz) Pensionskasse. Institutsbericht 3/92, Universität Konstanz - Informationswissenschaft, Konstanz 1993 Bechtolsheim, M. von: Die informationstechnische Integration von Expertensystemen: Stand der Technik, Probleme und Lösungsansätze. In: Gesellschaft für Mathematik und Datenverarbeitung (Hrsg.): lahresbericht 1988. St. Augustin 1989,71 - 83 Bechtolsheim, M. von: Der gordische KI-Knoten: Die technische Integration von Expertensystemen. In: Information Management 1/1991, 24 - 31 Becker, J.: CIM-Integrationsmodell. Die EDV-gestützte Verbindung betrieblicher Bereiche. Springer Verlag, Berlin et al. 1991 Benyon, D.: Information and Data Modelling. Blackwell Scientific Publications, Oxford et al., 1990 Benz, J.: PC-Standard-Statistik-Programmpakete als Methodenbankbasis in Systemen für Management und Marketing. In: Information Management 3/1991,28 - 34 Berns, T. (Hrsg.): Die ergonomischen Prinzipien der Büroautomation. Der neueste Erkenntnisstand sowie Richtlinien für die Humanfaktoren im Bürobereich. Verlag Ericsson Information Systems AB, Bromma 1984 Beth, T. et al.: Kryptographie - Eine Einführung in die Methoden und Verfahren der geheimen Nachrichtenübermittlung. Verlag Teubner, Stuttgart 1983 Beth, T. et al.: Kryptographie - Eine Einführung in die Methoden und Verfahren der geheimen Nachrichtenübermitüung. Verlag Teubner, Stuttgart 1983 Biethahn, J. und Hoppe, U.: Entwicklung von Expertensystemen - Eine Einführung. Gabler Verlag, Wiesbaden 1991 Blaschek, G. et al.: Einführung in die Programmierung mit Modula-2. 2. A., Springer Verlag, Berlin et al. 1987

394

Literaturverzeichnis

Blohm, H.: Die Gestaltung des betrieblichen Berichtswesens als Problem der Leitungsorganisation. Verlag Neue Wirtschafts-Briefe, Herne/Berlin 1970 Bodendorf, F.: Benutzermodell - ein konzeptioneller Überblick. In: WRTSCTAFISINFCRMATIK 2/1992, 233 - 245 Bolkart, W.: Programmiersprachen der vierten und fünften Generation. McGraw-Hill, Hamburg/ New York 1987 Boll, M.: Prozeßorientierte Implementation des SAP-Softwarepaketes. In: WIRTSCHAFTSINFCRMA3K 5 / 1 9 9 3 , 4 1 8 - 4 2 3 Bössmann, E.: Die ökonomische Analyse von Kommunikationsbeziehungen in Organisationen. Springer Verlag, Berlin et al. 1967 Bräunling, P. und Bodenschatz, K.: Fertigungs- und Montagedisposition in der Wälzlagerproduktion mit Hilfe der Linearen Programmierung. In: WIRTSCHAFTSINFORMATK 1/1992, 38 - 51 Brenner, W.: Entwurf betrieblicher Datenelemente. Ein Weg zur Integration von Informationssystemen. Springer Verlag, Berlin et al. 1988 Buhl, U. und Wirth, A.: Outsourcing von Informationsverarbeitungsleistungen unter Risikoaspekten. In: Frisch, W. und Taudes, A. (Hrsg.): Informationswirtschaft. Aktuelle Entwicklungen und Perspektiven. Physica-Verlag, Heidelberg 1993,207 - 230 Bühler, K.: Sprachtheorie. Die Darstellungsfunktion der Sprache. Fischer Verlag, Stuttgart 1978 Bullinger, H.-J. (Hrsg.): Berichte des German Chapters of the ACM 24. Verlag Teubner, Stuttgart 1985 Bullinger, H.-J. (Hrsg.): Software-Ergonomie '85 - Mensch-Computer-Interaktion. Berichte des German Chapter of the ACM Bd. 24, Verlag Teubner, Stuttgart 1985 Bundesminister des Inneren (Hrsg.): Unterlagen für Ausschreibung und Bewertung von DV-Leistungen (UFAB). Bonn 1985 Cakir, A.: Bürobeleuchtung - ein neues Konzept nimmt Formen an. In: Office Management 2/1986, 166 - 173 Cakir, A. et al.: Bildschirmarbeitsplätze. Springer Verlag, Berlin et a. 1980 Celler, W.: Mehr Datensicherheit durch Kryptographie. IBM-Nachrichten 34/1981,31 - 35 Chen, P. P.-S.: The Entity-Relationship Model: Towards a Unified View of Data. In: ACM Transactions on Database-Systems, 1/1976, 9 - 36 Chen, P. P.-S. (Ed.): Entity-Relationship Approach to Information Modeling and Analysis. Proc. of the 2nd International Conference on Entity-Relationship Approach (1981). Amsterdam et al. 1983 Claussen, U.: Objektorientiertes Programmieren. Mit Beispielen und Übungen in C++. Springer Verlag, Berlin et al. 1993 Clocksin, W. F. and Mellish, C. S.: Programming in Prolog. 2. A., Springer Verlag, Berlin et al 1984 Codd, E. F.: A Relational Model for Large Shared Data Banks. In: Communications of the ACM 6/1970, 377 - 387 Codd, E. F.: Further normalization of the relational model. In: Rustin, R. (Ed.): Data Base Systems, Courant Computer Science Symposium. Prentice Hall, Englewood Cliffs, N. J. 1972 Couger, J. D. und Zawacki, R. A.: Motivating and Managing Computer Personnel. J. Wiley & Sons, New York et al. 1980 Cummings and Blumberg: Advanced Manufacturing Technology and Work Design. In: Clegg, T. W. and Kemps, M.: Human Fight of Advanced Manufacturing Technology, 37 - 60; zitiert nach Ulich, E.: Arbeitspsychologie. 2. A., Verlag der Fachvereine und Poeschel Verlag, Zürich bzw. Stuttgart 1992, 205 (bibliographische Angaben unvollständig) Date, C. J.: An Introduction to Database Systems. Vol. I. 5. Ed., Addison-Wesley, Reading/ Mass. 1990 Diffie, W. and Hellman, M. E.: New Directions in Cryptography. In: IEEE Transactions on Information Theory 22/1976, 644 - 654 DIN (Hrsg.): EDIFACT - Elektronischer Datenaustausch für Verwaltung, Wirtschaft und Transport. Referate zur 4. DIN-Tagung. DIN Normenausschuß für Bürowesen, Berlin 1989 Disterer, G.: Nichtprozedurale Programmierung. In: Angewandte Informatik 7/87, 281 - 287 Dittrich, K. R.: Migration von konventionellen zu objektorientierten Datenbanken: soll man, muß man - oder nicht? In: WIRTSCHAFISINFORMATK 4/1993, 346 - 352 Dittrich, K. R. et al.: Das KARAMBA-Methodenbanksystem. In: Böhling, K. H. und Spies, P. P. (Hrsg.): 9. Jahrestagung der Gl. Springer Verlag, Berlin et al. 1979, 322 - 336 Drews, H.-L. et al.: Lexikon Datenschutz und Datensicherung. 3. A., Siemens AG, Berlin/München 1986

Literaturverzeichnis

395

EAN AUSTRIA, Gesellschaft für kooperative Logistik GesmbH., Wien (Hrsg.): INFO EAN, Fachzeitschrift für Artikelnumerierung, Warenwirtschaft und elektronischen Datenaustausch, 2/1991,4-6 Eberleh, E.: Klassifikation von Dialogformen. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988, 102 - 120 Eberleh, E.: Menüauswahl. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988, 121 - 137 Embley, D. W. et al.: Object-Oriented Systems Analysis. A Model-Driven Approach. Yourdon Press, Englewood Cliffs/N.J. 1992 Esprester, A. C.: Die Entwicklung einer Methodenbank und einer Methodenbanksprache. In: Angewandte Informatik 7/1978, 203 - 206 Feldman, M.: Constraints on Communication and Electronic Messaging. In: CSCW '86. Proceedings ACM-Conference on Computer Supported Cooperative Work, Austin/Texas, 73 - 90 Ferstl, K. und Sinz, E. J.: Geschäftsprozeßmodellierung. In: WIRTSCHAFISINFCRMA'nK 6/1993, 589 - 592 Filbig, G. und Kernler, H.: Eine Migration von COBOL/VSAM zu NATURAL/ADABAS. In: WRISCHAFTSINFCRMATtK 4/1993, 325 - 330 Fischer, G.: Kognitionswissenschaft - Ein Bindeglied zwischen Informatik und Psychologie. In: Schauer, H.: und Tauber, M. J. (Hrsg.): Informatik und Psychologie. Oldenbourg Verlag, München/Wien 1982,169 - 193 Fischer, J.: Datenmanagement - Datenbanken und betriebliche Datenmodellierung. Oldenbourg Verlag, München/Wien 1992 Fitzgerald, G.: Approaches to the Development of Executive Information Systems and the Contrast with Traditional Systems Development. In: Avison, D. et al. (Ed.): Human, Organizational, and Social Dimensions of Information Systems Development. Elsevier Science Publishers, North-Holland et al. 1993, 339 - 351 Ford, F. N.: Decision Support Systems ans Expert Systems: A Comparison. In: Information & Management 8/1985, 21 - 26 Frank, J.: Standard-Software - Kriterien und Methoden zur Beurteilung und Auswahl von Software-Produkten. 2. A., Verlagsgesellschaft Müller, Köln 1980 Frank, U.: Anwendungsnahe Standards der Datenverarbeitung: Anforderungen und Potentiale. In: WIRISCHAFTSINFCRMATIK 2/1991, 100- 111 Frese, E.: Aufgabenanalyse und -synthese. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980,207 - 217 Frese, M. und Zapf, D.: Die Einführung von neuen Techniken verändert Qualifikationsanforderungen, Handlungsspielraum und Stressoren kaum. In: Zeitschrift für Arbeitswissenschaft 1/1987,7- 14 Gabriel, R. und Röhrs, H.-P.: Datenbanksysteme. Konzeptionelle Datenmodellierung und Datenbankarchitekturen. Springer Verlag, Berlin et al. 1994 Geis, W. et al.: Vergleich von regelbasierten Expertensystemen mit Entscheidungstabellen anhand ausgewählter Beispiele. Arbeitsbericht des Instituts für Informatik der Universität Erlangen/ Nürnberg Bd. 21, Erlangen 1988 Geis, W. and Schumann, M.: Comparison of Rule Based Expert Systems with Traditional Technology - Selected Examples. In: Pau, L. F. et al. (Hrsg.): Expert Systems in Economics, Banking and Management. Elsevier Science Publishers, North-Holland et al. 1989,437 - 446 Gierlach, D. und Jankowski, R.: Operationalisierung der Grundsätze ergonomischer Dialoggestaltung nach DIN 66234 Teil 8 - Beispiel Textverarbeitung. In: Angewandte Informatik 5/1989, 189-196 Goldberg, A.: Smalltalk-80 - The Interactive Programming Environment. Addison-Wesley Publ. Company, Reading/MA. et al. 1984 Grass, A. und Roth, M.: Erfahrungen mit Dataflex, einem 4. Generationsansatz für die PC-Welt. In: Information Management 2/1987,44 - 48 Grupp, B.: EDV-Pflichtenheft zur Hardware- und Softwareauswahl. Verlag TÜV Rheinland, Köln 1987 Grupp, B.: Optimale Verschlüsselung bei Online-Datenverarbeitung - Aufbau moderner Nummernsysteme für Sachnummern jeder Art, Personennummern und Auftragsnummern. Verlag TÜV Rheinland, Köln 1987 Gunnarsson, E. and Östberg, O.: Physical and mental working environment in a terminal-based computer system. In: Arbearskyddsstyrelsen, August 1977, 35 (in Schwedisch)

396

Literaturverzeichnis

Haaks, D.: Anpaßbare Informationssysteme. Auf dem Weg zu aufgaben- und benutzerorientierter Systemgestaltung und Funktionalität. Verlag für Angewandte Psychologie, Göttingen/Stuttgart 1992 Hage, M. und Löhr, G.: Praktische Erfahrungen mit der Relationalen Datenanalyse bei der Hüls AG. In: Information Management 3/1986,30 - 39 Hannan, J. (Hrsg.): Ein praktischer Führer für das Datenbank-Management. Verlag Vieweg, Braunschweig/Wiesbaden 1988 Hasse, M.: Über die Behandlung graphentheoretischer Probleme unter Verwendung der Matrizenrechnung. In: Wissenschaftliche Zeitschrift der Technischen Universität Dresden, 10/1961, 1313-1316 Heilmann, H.: Integration - Ein zentraler Begriff der Wirtschaftsinformatik im Wandel der Zeit. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 150/1989,46 - 58 Heilmann, H. und Pleye, D.: Änderungshäufigkeiten von Daten und Funktionen. In: HMD Theorie und Praxis der Wirtschaftsinformatik 174/1993,115 - 123 Heilmann, W. und Reusch, G. (Hrsg.): Datensicherheit und Datenschutz. Hilfen zur Bestimmung eines eigenen Standpunktes. Forkel Verlag, Stuttgart/Wiesbaden 1984 Heinrich, L. J.: Zur rechnerischen Lösung von Organisationsproblemen mit Hilfe der Graphentheorie. In: Layer, M. (Hrsg.): Rechnungswesen und Betriebswirtschaftspolitik. Schmidt Verlag, Bielefeld 1969, 169 - 179 Heinrich, L. J.: Zur Methodik der Systemplanung in der Wirtschaftsinformatik. In: Schult, E. und Siegel, Th. (Hrsg.): Betriebswirtschaftslehre und Unternehmenspraxis. Schmidt Verlag, Berlin 1986, 83 - 99 Heinrich, L. J.: Benutzer-Service, Organisation des. In: Freese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A„ Poeschel Verlag, Stuttgart 1992, 308 - 318 Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. A., Oldenbourg Verlag, München/Wien 1992 Heinrich, L. J. und Hartwig, Th.: Abschlußbericht zum Forschungsprojekt CUSIS: Computerunterstütztes Studenten-Informationssystem - Ersetzbarkeit von Mensch-Mensch-Kommunikation durch Mensch-Maschine-Mensch-Kommunikation. Linz 1989 Heinrich, L. J. und Hoffellner, N.: Methoden und Techniken der Anwendungssystem-Planung eine empirische Studie. In: Information Management 4/1989,42 - 46 Heinrich, L. J. et al.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 4. A., Oldenbourg Verlag, München/Wien 1994 Herold, H. und Unger, W.: Das C-Buch. te-wi Verlag, München 1986 Hillier, F. S. und Lieberman, G. J.: Operations Research - Einführung. 4. A., Oldenbourg Verlag, München/Wien 1988 Hu, D.: C/C++ for Expert Systems. Management Information Source, Inc., Portland/OR. 1989 Humeltenberg, W.: Planungssprachen zur Entwicklung von Management-Support-Systemen. In: Krallmann, H. et al. (Hrsg.): Rechnergestützte Werkzeuge für das Management. Grundlagen, Methoden, Anwendungen. Schmidt Verlag, Berlin 1992, 73 - 107 IBM (Ed.): Introduction to Cryptography - Student Text. Poughkeepsie/N.Y. 1981 IBM (Ed.): Data Security through Cryptography. IBM Form GC22- 9062 IBM Österreich (Hrsg.): ECODEX Informationsbroschüre. Wien 1991 Jacobson, I. et al.: Object-Oriented Software Engineering. Addison-Wesley Publ. Company, Reading/MA. et al. 1992 Jarke, M.: Wissensbasierte Systeme - Architektur und Einbettung in betriebliche DV-Landschaften. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990,459 - 479 Jarke, M. and Vassiliou, Y.: Coupling Expert Systems with Database Systems. In: Reitman, W. (Ed.): Artificial Intelligence Applications for Business. Norwood/N.J. 1984, 65 - 85 Karras, D. et al.: Entwicklungsumgebungen für Expertensysteme. Vergleichende Darstellung ausgewählter Systeme. Verlag de Gruyter, Berlin/New York 1987 Keene, S. E.: Object-Oriented Programming in COMMON LISP. A Programmer's Guide to CLOS. Addison-Wesley Publ. Company, Reading/MA. et al. 1989 Kemper, H.-G.: Dezentrale Anwendungsentwicklung. Entwicklung von betrieblichen Anwendungssystemen durch Fachabteilungen und Endbenutzer in deutschen Großunternehmen. Verlag Eul, Bergisch Gladbach/Köln 1991 Kernighan, et al.: Programmieren in C. Oldenbourg Verlag, München /Wien 1983 Kersten, H.: Einführung in die Computersicherheit. Oldenbourg Verlag, München/Wien 1991 Khoshafian, S. and Abnous, R.: Object Orientation. Concepts, Databases, User Interfaces. John Wiley & Sons, Inc. New York et al. 1990

Literaturverzeichnis

397

Kieser, A. und Kubicek, H.: Organisation. 2. A., Verlag de Gruyter, Berlin/New York 1983 Kim, W. and Lochovsky, F. H. (Ed.): Object-Oriented Concepts, Databases, and Applications. Addison-Wesley Publ. Company, Reading/MA. et al. 1989 Kirsch, W. et al.: Das Management des geplanten Wandels von Organisationen. Poeschel Verlag, Stuttgart 1979 Klein, H.: Partnerschaft zwischen Fachabteilung und EDV. In: Heilmann, H. (Hrsg.): Zusammenarbeit zwischen Fachabteilung und EDV. Forkel Verlag, Stuttgart/Wiesbaden 1980,15-63 Klösgen, W. und Schwarz, W.: Die Realisierung von Architekturprinzipien für Methodenbanksysteme im Modellbanksystem MBS. In: Böhling, K. H. und Spies, P. P. (Hrsg.): 9. Jahrestagung der Gl, Informatik-Fachberichte Bd. 19, Springer Verlag, Berlin et al. 1979, 274 - 284 Knolmayer, G.: Die Auslagerung von Servicefunktionen als Strategie des IS-Managements. In: Heinrich, L. J. et al. (Hrsg.): Die Informationswirtschaft im Unternehmen. Universitätsverlag Trauner, Linz 1991, 323 - 341 Koch, M.et al.: Software-Ergonomie. Gestaltung von EDV-Systemen - Kriterien, Methoden und Werkzeuge. Verlag Springer, Wien/New York 1991 Kohl, A. et al.: Elektronische Produktkataloge - Entwicklungsstand und Einsatzmöglichkeiten. In: WIRTSCHAFISINFCRMAUK 5/1992, 509 - 516 Koller, F. und Ziegler, J.: Benutzerpräferenzen bei alternativen Eingabetechniken. In: Maaß, S. und Oberquelle, H. (Hrsg.): Software-Ergonomie '89. Aufgabenorientierte Systemgestaltung und Funktionalität. Verlag Teubner, Stuttgart 1989 Kosiol, E.: Grundprobleme der Ablauforganisation. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A„ Poeschel Verlag, Stuttgart 1980, 2 - 7 Krallmann, H.: EDV-Sicherheitsmanagement. Integrierte Sicherheitskonzepte für betriebliche Informations- und Kommunikationssysteme. Schmidt Verlag, Berlin 1989 Krüger, W.: Organisatorische Einführung von Anwendungssystemen. In: Kurbel, K. und Strunz, H. (Hrsg.): Handbuch Wirtschaftsinformatik. Verlag Poeschel, Stuttgart 1990, 275 - 288 Kubicek, H.: Informationsverbund, überbetrieblicher. In: Frese, E. et al. (Hrsg.): Handwörterbuch der Organisation. 3. A„ Poeschel Verlag, Stuttgart 1992, 994 - 1009 Kunerth, W.: EDV-gerechte Verschlüsselung: Grundlagen und Anwendung moderner Nummernsysteme. 2. A., Forkel Verlag, Stuttgart/Wiesbaden 1981 Kurbel, K.: Programmentwicklung. 2. A., Verlag Gabler, Wiesbaden 1985 Kurbel, K.: Programmierstil in Pascal, Cobol, Fortran, Basic und PL/I. Springer Verlag, Berlin et al. 1985 Kurbel, K.: Entwicklung und Einsatz von Expertensystemen - Eine anwendungsorientierte Einführung in wissensbasierte Systeme. 2. A., Springer Verlag, Berlin et al. 1992 Kurbel, K. und Pietsch, W.: Expertensystem-Projekte. Entwicklungsmethodik, Organisation und Management. In: Informatik Spektrum 12/1989,133 - 146 Laske, St.: Arbeitsorganisation und Arbeitsqualität. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A„ Poeschel Verlag, Stuttgart 1980, 118 - 126 Lassmann, W. und Schilar, H.: Ökonomie und Optimierung. Akademie-Verlag, Berlin 1985 Lehmann, H.: Integration. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980, 976 - 984 Lehner, F.: Aufwandsvergleich: Anwendungssystementwicklung mit Sprachen der 3. Generation und modernen Softwarewerkzeugen. In: Information Management 4/1988, 34 - 41 Liebelt, W. und Sulzberger, M.: Grundlagen der Ablauforganisation. Verlag Schmidt, Gießen 1988 Lindheim, W. und Egle, W.: Schlüsselfaktoren für eine erfolgreiche Kommunikation zwischen Management, EDV, Fachbereich. In: EERWIRTSCHAFTSINGENIEUR 3/1987, 34 - 38 Lorenzen, P.: Konstruktivismus und Hermeneutik. In: Lorenzen, P. (Hrsg.): Konstruktive Wissenschaftstheorie. Suhrkamp Verlag, Frankfurt 1974, 113 - 118 Lusti, M.: Daten und Datenbanken - Eine anwendungsorientierte Einführung. Springer Verlag, Berlin et al. 1989 Maaß, S.: Software-Ergonomie - Benutzer- und aufgabenorientierte Systemgestaltung. In: Informatik Spektrum 4/1993,191 - 205 Maguire, M.: An evaluation of published recommendations on the design of man-computer dialogues. In: International Journal of Man-Machine Studies 16/1982, 237 - 261 Marr, R. und Kötting, M.: Implementierung, organisatorische. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Poeschel Verlag, Stuttgart 1992, 827 - 841 Martin, J.: Application Development Without Programmers. Prentice-Hall, Inc., Englewood Cliffs/N. J. 1982

398

Literaturverzeichnis

Martland, D., et al.: Fourth Generation Languages and Application Generators. The Technical Press - UNICOM , Brookfield/Vermont, 1986 Mathy, G.: Informatik-Strategie und Relationale Datenbanken. In: Information Management 2/1987, 6 - 17 Mathy, G.: Wettbewerbsinstrument Relationale Datenbanken. Die Anforderungen des Tools an die organisatorische Infrastruktur. AIT Verlagsgesellschaft, Halbergmoos 1987 Meier, A. et al.: Schutz der Investitionen beim Wechsel eines Datenbanksystems. In: WIRTSCHAFISINFCRMAnK 4/1993, 331 - 338 Meinhard, A. und Lorenz, V.: Unterstützung des Benutzers durch Hilfesysteme. In: Angewandte Informatik 11/1986, 475 - 479 Merritt, D.: Building Expert Systems in Prolog. Springer Verlag, New York et al. 1989 Mertens, P.: Zwischenbetriebliche Integration der EDV. In: Informatik Spektrum 8/1985, 81 - 9 0 Mertens, P.: Enriching Conventional PPS Systems by Knowledge-Based Elements. In: Proceedings of the International Conference on Artificial Intelligence in Industry & Government. Hyderabad/India 1989,271 - 290 Mertens, P.: Integrierte Informationsverarbeitung 1 - Administrations- und Dispositionssysteme in der Industrie. 8. A., Gabler Verlag, Wiesbaden 1991 Mertens, P. und Bodendorf, F.: Interaktiv nutzbare Methodenbanken - Entwurfskriterien und Stand der Verwirklichung. In: Angewandte Informatik 12/1979, 533 - 541 Mertens, P. und Griese, J.: Integrierte Informationsverarbeitung 2 - Planungs- und Kontrollsysteme. 7. A., Gabler Verlag, Wiesbaden 1993 Mertens, P. et al.: Betriebliche Expertensystem-Anwendungen. 3. A., Springer Verlag, Berlin et al. 1993 Mertin, C.-O.: Aktuelle EDV-Musterpflichtenhefte zur präzisen Definition der kompletten Anforderungen an EDV-Lösungen in allen kaufmännischen Bereichen. WEKA Fachverlage, Kissing et al. 1988 Metzger, W.: Gesetze des Sehens. Verlag Kramer, Frankfurt/M. 1975 Meyer, B.: Objektorientierte Softwareentwicklung. Hanser Verlag, München/Wien und PrenticeHall International Inc., London 1990 Meyer, C. H. und Matyas, S. M.: Cryptography - A New Dimension in Computer Data Security. New York 1982 Meyer, M. und Hanken, K.: Planungsverfahren des Operations Research. 3. A., Verlag Vahlen, München 1985 Miebach, J. T.: Funktionalität von EDI-Konvertern. In: WIRTSCHAFISINFCRMA'nK 5/1992, 517 -526 Mikuteit, H.-L.: "Computer machen krank". In: MACup 1/1991,12-16 Minnemann, J.: MAMBO - Erfahrungen bei der Entwicklung eines Methodenbanksystems. In: HMD - Handbuch der Modernen Datenverarbeitung 126/1985. Forkel Verlag, Stuttgart/Wiesbaden 1985, 95 - 105 Mörk, R.: Ein praxisorientiertes Vorgehensmodell zur Einführung von zwischenbetrieblicher Integration. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 165/1992,47 - 67 Müller-Merbach, H.: Die ungenutzte Synergie zwischen Operations Research und Wirtschaftsinformatik. In: WIRTSCHAFTSINFORMAnK 3/1992, 334 - 339 Müller-Pleuß, J.: Vordruckgestaltung. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Poeschel Verlag, Stuttgart 1992, 2582 - 2595 Nagl, M.: Ada. Eine Einführung in die Programmiersprache der Softwaretechnik. 4. A., Vieweg Verlag, Braunschweig/Wiesbaden 1992 Naylor, Th. N. and Mann, M. H. (Ed.): Computer Based Planning Systems. Planning Executives Institute, Oxford/Ohio 1982 Netze, J. und Seelos, H.-J.: Szenarien und Strategien der Datenmigration. In: WIRTSCHAFTSINFCRMAUK 4/1993, 320 - 324 Neumann, K. et al.: Eine Portierungsstrategie für ADABAS-Datenbestände und -Anwendungen nach DB2. In: WIKISCHAFTSINFCRMAnK 4/1993, 339 - 345 Niedereichholz, J. und Kaucky, G.: Datenbanksysteme. Konzepte und Management. 4. A., Physica Verlag, Heidelberg 1992 Oppelt, U.: EDI-Implementierung in der Praxis - Voraussetzungen, Vorgehensweise, Wirtschaftlichkeit. In: Reichwald, R. (Hrsg.): Marktnahe Produktion. Gabler Verlag, Wiesbaden 1992, 68-81 Oppermann, R. und Reiterer, H.: Evaluation von Benutzerschnittstellen. In: WIRXSCHAFISINFCRMA31K 3/1992, 283 - 293

Literaturverzeichnis

399

Ortner, E.: Aspekte einer Konstruktionssprache für den Datenbankentwurf. Toeche-Mittler Verlag, Darmstadt 1983 Ortner, E.: Semantische Modellierung - Datenbankentwurf auf der Ebene der Benutzer. In: Informatik Spektrum 8/1985, 20 - 28 Ortner, E.: Unternehmensweite Datenmodellierung als Basis für integrierte Informationsverarbeitung in Wirtschaft und Verwaltung. In: WDüSCHAFTSINFCRMAnK4/1991, 269 - 280 Ortner, E.: Informationsverarbeitung und Sprachkritik - Ein komplementärer Integrationsbereich für Benutzer, Management und Systeme. Institutsbericht 17/93, Universität Konstanz - Informationswissenschaft, Konstanz 1993 Ortner, E. und Söllner, B.: Semantische Datenmodellierung nach der Objekttypenmethode. In: Informatik Spektrum 1/1989,31 - 42 Österle, H. (Hrsg.): Anleitung zu einer praxisorientierten Software-Entwicklungsumgebung. Bd.2.: Software-Entwicklungssysteme und 4.Generation-Sprachen. AIT Verlag, Halbergmoos 1988 o.V.: Reizklima Büro. Ozonausstoß von Laserdruckern. In: Konsument. Das österreichische Testmagazin 1/1994, 17 - 19 Paaß, G. und Wauschkuhn, U.: Datenzugang, Datenschutz und Anonymisierung. Oldenbourg Verlag, München/Wien 1985 Panny, W. und Taudes, A.: Client-Server Computing mit SQL2. In: Frisch, W. und Taudes, A. (Hrsg.): Informationswirtschaft. Aktuelle Entwicklungen und Perspektiven. Physica Verlag, Heidelberg 1993, 273 - 287 Parnas, D. L.: On the Criteria to be Used in Decomposition Systems into Modules. In: Comm. of the ACM 12/1972,1053 - 1058 Peters, G.: Ablauforganisation und Informationstechnologie im Büro. Konzeptionelle Überlegungen und empirisch-explorative Studie. Müller Botermann Verlag, Köln 1988 Peters, T.: Arbeitswissenschaft für die Büropraxis. Ein Handbuch für Büro-Medizin und -Ergonomie. Schilling Verlag für Informationstechnik, Herne 1973 Pfeiffer, H. K.: The Diffusion of Electronic Data Interchange. Selected Results of an International Empirical Investigation. Working Report 23, Institut fur Wirtschaftsinformatik der Universität Bem, Bern 1990 Pflüger, C. et at.: Umstellung alter COBOL-Programme in objektorientierte Systeme. In: W1RTSCHAFISINFCRMAnK 4/1993, 353 - 359 Picot, A. und Franck, E.: Informationsmanagement. In: Frese, E. (Hrsg.): Handwörterbuch der Organisation. 3. A., Poeschel Verlag, Stuttgart 1992, 886 - 900 Picot, A. und Maier, M.: Analyse- und Gestaltungskonzepte für das Outsorcing. In: Information Management 4/1992, 14 - 27 Picot, A. und Reichwald, R. (Hrsg.): Kommunikationstechnik für Anwender. Forschungsprojekt Bürokommunikation Bd. 1. CW-Publikationen Verlagsgesellschaft, München 1983 Picot, A. et al.: Ökonomische Perspektiven eines "Electronic Data Interchange". In: Information Management 2/1992,22 - 29 Pietsch, M.: PAREUS-RM - ein Tool zur Unterstützung der Konfiguration von PPS-Parametern im SAP-System R/2. In: WIKISOIAFISINFORMAIIK 5/1993, 434 - 445 Piller, E. und Weissenbrunner, A.: Software-Schutz. Springer Verlag, Wien/New York 1986 Pomberger, G.: Softwaretechnik und Modula-2. Hanser-Verlag, München/Wien 1984 Pomberger, G. und Blaschek, G.: Software Engineering. Prototyping und objektorientierte Software-Entwicklung. Hanser Verlag, München/Wien 1993 Pommerening, K.: Datenschutz und Datensicherheit. B.I. Wissenschaftsverlag, Mannheim et al. 1991 Puchan, J. et al: Programmieren mit Modula-2. Verlag Teubner, Stuttgart 1991 Rauh, O.: Überlegungen zur Behandlung ableitbarer Daten im Entity-Relationship-Modell (ERM). In: WIRTSCHAFTSINFORMATIK 3/1992, 294 - 306 Reblin, E.: Stapel- oder Dialogverarbeitung im Rechnungswesen. In: Stahlknecht, P. (Hrsg.): Online-Systeme im Finanz- und Rechnungswesen. Springer Verlag, Berlin et al. 1980 Reichwald, R. und Stauffert, T.: Bürokommunikationstechnik und Führung. In: Kieser, A. et al. (Hrsg.): Handwörterbuch der Führung. Poeschel Verlag, Stuttgart 1987,115 - 127 Reuter, A.: Kopplung von Datenbank- und Expertensystemen. In: Informationstechnik 3/1987, 164-175 Rick F. van der Lans: Das SQL-Lehrbuch. Addison-Wesley Publ. Company, Bonn 1988 Rickert, R.: Konzeption von Methodenbanken zur Entscheidungsunterstützung. In: Krallmann, H. (Hrsg.): Unternehmensplanung und -Steuerung in den 80er Jahren. Springer Verlag, Berlin et al. 1982, 164 - 179

400

Literaturverzeichnis

Ritterbach, B.: Ein Schlüsselkonzept für das ER-Modell - Praktische Konsequenzen für die Modellierung und Toolunterstützung. Unveröffentlichtes Manuskript, Hamburg 1993 Rivest, R. et al.: A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. In: Communications of the ACM 2/1978,120- 126 Rock, I.: Wahrnehmung. Vom visuellen Reiz zum Sehen und Erkennen. Verlag Spektrum der Wissenschaft, Heidelberg o.J. Rumbaugh, J. et al.: Object-Oriented Modeling and Design. Prentice Hall International, Inc., Englewood Cliffs/N.J. 1991 Ryska, N. und Herda, S.: Kryptographische Verfahren in der Datenverarbeitung. Springer Verlag, Berlin et al. 1980 Schauer, H. und Barta, G.: Konzepte der Programmiersprachen. Springer Verlag, Wien/New York 1986 Schaumüller-Bichl, I.: Sicherheitsmanagement. Risikobewältigung in informationstechnologischen Systemen. B. I. Wissenschaftsverlag, Mannheim et al. 1992 Scheer, A.-W.: EDV-orientierte Betriebswirtschaftslehre. 4. A., Springer Verlag, Berlin et al. 1990 Scheer, A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. 4. A., Springer Verlag, Berlin et al. 1994 Scheer, A.-W. et al.: Analyse der Umsetzung einer EDI-Konzeption am Beispiel der Beschaffungslogistik in der Automobilzuliefererindustrie. In: Information Management 2/1991, 30 - 37 Schips, B.: Ein Beitrag zum Thema "Methodenbanken". In: Angewandte Informatik 11/1977,465 -470 Schlaffer, P.: Systemfreie Benummerung. DIN-Mitteilungen 12/1983, 601 - 609 Schlageten G. und Stucky, W.: Datenbanksysteme. Konzepte und Modelle. 2. A., Verlag Teubner, Stuttgart 1983 Schmidt, G.: Methode und Techniken der Organisation. 8. A., Verlag Schmidt, Gießen 1989 Schmidtke, H.: Ergonomische Bewertung von Arbeitssystemen - Entwurf eines Verfahrens. Hanser Verlag, München/Wien 1976 Schmückte, W. und Cleve, D.: Konversion - am Beispiel einer Umstellung von IBM/360 DOS auf IBM/370 OS. IBM Nachrichten 207/1971, 835 - 840 und IBM Nachrichten 208/1971, 945 948 Schnauber, H.: Arbeitswissenschaft. Verlag Vieweg, Braunschweig 1979 Schneider, St. et al.: Wesen, Vergleich und Stand von Software zur Produktion von Systemen der computerunterstützten Unternehmensplanung. Arbeitsberichte des Instituts für Informatik der Universität Erlangen-Nürnberg, Bd. 16, Nürnberg 1983 Schoffa, G.: Die Programmiersprache LISP - Eine Einführung in die Sprache der künstlichen Intelligenz. München 1987 Schrefl, M.: Grundlagen von Datenbanksystemen. Vorlesungsunterlagen WS 1993/94, Institut für Wirtschaftsinformatik/Data & Knowledge Engineering, Linz 1993 Schuppenhauer, R.: Grundsätze für eine ordnungsgemäße Datenverarbeitung. IdW-Verlag, Düsseldorf 1982 Schweitzer, M.: Arbeitsteilung. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980, 139 - 144 Schweitzer, M.: Arbeitsteilung. In: Grochla, E. (Hrsg.): Handwörterbuch der Organisation. 2. A., Poeschel Verlag, Stuttgart 1980,139 - 144 Shlaer, S. and Mellor, St. J.: Object-Oriented Systems Analysis. Modeling the World in Data. Yourdon Press, Englewood Cliffs/N.J. 1988 Shneiderman, B.: Direct Manipulation. A Step Beyond Programming Languages. In: IEEE Computer, Vol. 16. August 1983, 57 - 69 Shneiderman, B.: Designing the User Interface. Strategies for Effective Human-Computer Interaction. Addison-Wesley Publ. Company, Reading/MA. et al. 1987 Siegmann, H.: Wesen, Vergleich und Stand von zeh'.i ausgewählten kleinrechnerorientierten Planungssprachen. Arbeitsberichte des Instituts für Informatik der Universität Erlangen-Nürnberg, Bd. 18, Nürnberg 1985 Siemens-Nixdorf Informationssysteme (Hrsg.): Anwenderhandbuch INFPLAN. Bestellnummer U2846-J-Z87-1, München 1986 Siemens-Nixdorf Informationssysteme (Hrsg.): Benutzerhandbuch INFPLAN. Bestellnummer U1561-J-Z87-4, München 1986 Siemens-Nixdorf Informationssysteme (Hrsg.): MEMO (BS2000) Modellsprache - Beschreibung. Ausgabe 1/1985, München 1985

Literaturverzeichnis

401

Siemens-Nixdorf Informationssysteme (Hrsg.): MEB (BS2000) Methodenbank - Anwendungsbeschreibung. Ausgabe März 1986, München 1986 Sinz, E. J.: Das Entity-Relationship-Modell (ERM) und seine Erweiterungen. In: HMD - Theorie und Praxis der Wirtschaftsinformatik 152/1990,17 - 29 Sinz, E. J. und Amberg, M.: Vergleichende Buchbesprechung Datenbanksysteme. In: WIRTSCHAFTSINFORMATIK 2/1994,193 - 197 Spillner, A.: Das aktuelle Schlagwort: Integrationstest. In: Informatik Spektrum 5/1992, 293 - 294 Sorg, S. und Zangl, H.: Vorteile integrierter Bürosysteme für Führungskräfte - Erfahrungen aus einem Pilotprojekt. In: Jahrbuch der Bürokommunikation 2/1986,117 - 119 Spinas, P. et al.: Leitfaden zur Einführung und Gestaltung von Arbeit mit Bildschirmsystemen. Verlag CW-Publikationen und Verlag Industrielle Organisation, München und Zürich 1983 Staufer, M.: Piktogramme für Computer. Verlag de Gruyter, Berlin/New York 1987 Stein, W.: Objektorientierte Analysemethoden - ein Vergleich. In: Informatik Spektrum 6/1993, 317-332 Steinmetz, G.: Was ist ein Pflichtenheft? In: Elektronische Rechenanlagen 5/1982, 225 - 229 Strauß, Ch.: Informatik-Sicherheitsmanagement. Eine Herausforderung für die Untemehmensführung. Verlag Teubner, Stuttgart 1991 Streitz, N. A.: Fragestellungen und Forschungsstrategien der Software-Ergonomie. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988, 3 - 24 Stroustrup, B.: The C++ Programming Language. 2. Ed., Addison-Wesley Publ. Company, Reading/ MA. et al. 1991 S V D (Hrsg.): EDV-Pflichtenhefte. Wegleitung für die Erstellung von EDV-Pflichtenheften. Schriftenreihe des Instituts für Informatik der Universität Zürich, Bd. 4, 2. A., Verlag Haupt, Bern/Stuttgart 1983 Tepper, A.: Paradoxien der Direkten Manipulation. In: Ackermann, D. und Ulich, E. (Hrsg.): Software-Ergonomie '91. Benutzerorientierte Software-Entwicklung. Verlag Teubner, Stuttgart 1991,236-251 Ulich, E.: Différentielle Arbeitsgestaltung. In: Zeitschrift für Arbeitswissenschaft 1/1983, 12 - 15 Ulich, E.: Arbeits- und organisationspsychologische Aspekte. In: Balzert, H. et al. (Hrsg.): Einführung in die Software-Ergonomie. Verlag de Gruyter, Berlin/New York 1988,49 - 66 Ulich, E.: Arbeitspsychologie. 2. A., Verlag der Fachvereine und Poeschel Verlag, Zürich bzw. Stuttgart 1992 VDI-Richtlinie 3320: Werkzeugnummerung - Werkzeugordnung. VDI Verlag, Düsseldorf 1973 Vessey, I. and Sravanapudi, A. P.: Evaluation of Vendor Products: CASE-Tools as Collaborative Support Technologies. Unpublished Paper, Penn. State University 1992 Vetter, M.: Aufbau betrieblicher Informationssysteme mittels konzeptioneller Datenmodellierung. 6. A., Verlag Teubner, Stuttgart 1990 Vossen, G. und Witt, K.-U. (Hrsg.): Entwicklungstendenzen bei Datenbank-Systemen. Oldenbourg Verlag, München/Wien 1991 Walk, Ch.: Aufgaben und Methoden eines Migrationszentrums. In: WIRTSCHAFISINFORMAnK 4/1993, 311 - 3 1 9 Waither, H.-W.: The on-line user-computer interfaces: The effects of interface flexibility, experience, and terminal type on user satisfaction and performance. Dissertation. The University of Texas at Austin, August 1973 Wandmacher, J.: Software-Ergonomie. Verlag de Gruyter, Berlin et al. 1993 Weber, E. et al.: Ein Verhandlungsmechanismus zwischen drei einfachen Wissensbasierten Systemen. In: WIRTSCHAFISINFCRMAnK 1/1990, 59 - 70 Weck, G.: Datensicherheit. Methoden, Maßnahmen und Auswirkungen des Schutzes von Information. Teubner Verlag, Stuttgart 1984 Wedekind, H. und Ortner, E.: Systematisches Konstruieren von Datenbankanwendungen - Zur Methodologie der Angewandten Informatik. Hanser Verlag, München 1980 Wenzel, G.: Anwendungen in TURBO PROLOG - Expertensysteme. Hüthig Buch Verlag, Heidelberg 1989 Werner, G. und Bernhardt, R.: Die Nummer als Schlüssel in der Datenverarbeitung. Grundlagen und Anwendung moderner Nummernsysteme. 3. A., Forkel Verlag, Wiesbaden 1991 Weyer, H. und Pütter, St.: Organisation und Technik der Datensicherung - Empfehlungen aus der Kontrollpraxis. Datakontext Verlag, Köln 1983 Willcocks, L. and Lester, St.: How do Organizations Evaluate and Control Information Systems Investments? Recent Survey Evidence. In: Avison, D. et al. (Ed.): Human, Organizational, and

402

Literaturverzeichnis

Social Dimensions of Information Systems Development. Elsevier Science Publishers, NorthHolland et al. 1993, 15-39 Willmer, H. und Balzert, H.: Fallstudie einer industriellen Software-Entwicklung. Definition, Entwurf, Implementierung, Abnahme, Qualitätssicherung. B. I. Wissenschaftsverlag, Mannheim et al. 1984 Winston, P. H. und Horn, B. K.: LISP. Addison-Wesley Pubi. Company, Bonn et al. 1987 Wirth, N.: Program Development by Stepwise Refinement. In: Comm. of the ACM 4/1971, 221 227 Wirth, N.: Programmieren in Modula-2. 2. A., Springer Verlag, Berlin et al. 1991 Zehnder, C. A.: Informationssysteme und Datenbanken. Verlag Teubner, 5. A., Stuttgart 1989 Zwerina, H.: Masken und Formulare. In: Balzert, H. et al. (Hrsg.): Einführung in die SoftwareErgonomie. Verlag de Gruyter, Berlin/New York 1988, 163 - 175 Zwerina, H. et al.: Kommunikations-Ergonomie. Benutzerfreundliche Anwendungsprogramme in Maskentechnik. Herausgegeben vom Bereich Datentechnik der Siemens AG, Berlin/München 1983

Schlagwortverzeichnis INF 127 2NF 127 3NF 127 3NF-Relation 179 4GL 280 Abarbeitungsstrategie 294 Abbildung 18 Abfrage 177; 180 freie 177; 180 parametrisierte 177 vorprogrammierte 177; 181 Abfragesprache 180; 209; 280 SQL 284 Abgleichcode 136 Abhängigkeit transitive 130; 134 Ablauforganisation 44; 46; 201; 359; 362 Ablaufteil 299 Abnahmetest 366; 368 Abschlußarbeiten 370 Abstimmen der Systementwürfe 106 der Systementwürfe untereinander 107 Abstraktion 150; 151; 252 funktionale 254 Abstraktionsebene 254 Abstraktionsgrad 211 Abtastzeile 319 Abwehrtiefe 237 Abweichung 366; 368; 369 ACM 330 Ada 265 ADABAS 386 Adjazenzmatrix 57; 63; 66 ADT270 Aggregation 113; 123 Aktion 272 Aktualisierung 379 Akzeptanz 75; 78 Akzeptanzziel 352 Algorithmierung 283 Algorithmus 28; 33ff.; 341; 342; 345 Allgemeinbegriff 109 Analogie 31 Analyse des Realproblems 150 Analysephase 277 Anbieter 83; 84 Änderungsanomalie 132 Anforderung 17; 29; 45; 58; 92; 95 physiologische 320 Anforderungsprofil 92 Anforderungsvielfalt 155 Angebot 89 Angebotsanalyse 92; 96; 97 Angriff kryptoanalytischer 346 Anomalie 127; 129

Anpassungsebene 302 Anpassungsfähigkeit 139 Ansatz datenorientierter 31; 105 zur Bildung von Datenobjekttypen 111 ANSI/SPARC 16 Antwortzeit 383 Anweisung 307 Anwendung 293 Anwendungsaufgabe 23 Anwendungsbarriere 238 Anwendungsentwicklung dezentrale 198 Anwendungsgebiet 310 Anwendungsgenerator 280; 282; 284 Anwendungsprogramm 188; 262; 263 Anwendungsrückstau 83; 188; 280 Anwendungssoftware 188; 190; 387 Anwendungssoftware-Bestand 85 Anwendungssoftware-Entwicklung 30 Anwendungsumgebung 178; 189; 201; 219; 351 Äquipollenz 109 Arbeitsablauf 32; 44; 50; 202; 203 Arbeitsanweisung 143 Arbeitsergebnis 154 Arbeitsgang 44 Arbeitsgliederung 51 Arbeitshaltung 321 Arbeitsinformation 212 Arbeitsinhalt 47 Arbeitsmatrix 307 Arbeitsorganisation 44ff.; 100; 153ff., 175; 200ff.; 331 objektive 153 organisationsweite 46 subjektive 153 vorgegebene 153 wahrgenommene 153 Arbeitsplatz 319f. mehrfunktionaler 163 Arbeitsplatzergonomie 319ff. Arbeitsplatzumgebung 325 Arbeitsraum 47 Arbeitsstuhl 322 Arbeitsteilung 44f.; 50f.; 54; 75; 77 Arbeitstisch 322 Arbeitszeit 47 Arbeitszufriedenheit 44; 46; 162; 167 Arbeitszuordnung 47 Architektur 227; 331 wissensverarbeitender Systeme 291 Argumentebilanz 83 AS 307 Assoziationstyp 119 Attribut 16; 24; 120; 276 Attribute-Weitebereich 177 Attributewert 40; 129

404

Schlagwortverzeichnis

Aufbauorganisation 44; 165; 201; 359 Aufgabe(n) 95; 164 beim Durchführen der Installierung 367 beim Entwerfen der Arbeitsorganisation 46 beim Entwerfen des Datensystems 23 beim Entwerfen des Methodensystems 32 beim Entwerfen des Sicherungssystems 70 beim Entwerfen des Transportsystems 59 beim Entwickeln der Arbeitsorganisation 202 beim Entwickeln des Datensystems 179 beim Entwickeln des Methodensystems 190 beim Entwickeln des Sicherungssystems 234 beim Entwickeln des Transportsystems 220 beim Vorbereiten der Installierung 360 der Datenkonvertierung 380 der Feinprojektierung 174 der Grobprojektierung 13 der Installierung 354 der Programmadaption 387 der Systemintegration 76; 244 Aufgabenanalyse 49; 150 Aufgabenbereicherung 157 Aufgabenerweiterung 156; 159 Aufgabenfimktion 83; 86; 89 Aufgabenorientierung 153; 155 Aufgabenschulung 361 Aufgabenstrukturierbarkeit 28 Aufgabenstrukturierung 28; 32 Aufgabensynthese 50 Aufgabenträger 84; 191 Aufgabentyp 90 Aufgabenwechsel 157 Aufgabenzuordnung 51 Aufgabenzusammenhang 154 Auflösungsvermögen 319; 323 Aufstellen der Geräte 363 Auftragsumfang 97 Aufwand 128; 342 Aufwandsvergleich 285 Ausgangsgrad 63 Ausgangsplattform 351; 354 Aussage 109 Aussagefunktion 110 Aussagensystem 109 Ausschreibung 92 Außenposition, relative 64 Ausstattung des Arbeitsplatzes 322 Auswahlhilfe 301 Auswahlverbot 301 Authentifikation 232 Autonomie 156 Axiom 271 Basis der Hierarchie 258 Basis-Komponente 314 Basisbibliothek 270 Basissystem 173 Baum 16; 200; 208

BDSG 68 Bearbeitungsfolge 104 Bearbeitungskosten 48 Bedarf 84 Bedeutung, semantische 124 Bedeutungsanalyse 113 Bedingung 150; 372 Bedrohung 68 Befehl 262 Begriff 109; 112 Begriffsdefekt 115 Begriffsleiter 140 Begriffssystem 139 mit bereichsweiser Gliederung 141 mit hierarchischer Gliederung 139 mit kombinierter Gliederung 141 mit nebengeordneter Gliederung 140 ohne Systematik 139 Beleg 218; 220; 226; 228 Belegfarbe 222 Belegform 222 Belegformat 222 Beleggestaltung 221 Beleggliederung 222 Belegmaterial 222 Belegnumerierung 222 Beleuchtungsstärke 319 Benummern 136 Benutzbarkeit 310f.; 330; 332; 338 Benutzer 211; 213; 332; 361; 368 Benutzerakzeptanz 55 Benutzerberechtigung 232 Benutzerbeteiligung 359 Benutzerebene 302 Benutzerführung und Datenschutz 181 Benutzermitwirkung 359 Benutzeroberfläche 215; 248f.; 330f. Benutzerschnittstelle 53; 330 Benutzerservice 194 Benutzerservice-Zentrum 188 Benutzersicht 128; 179ff. Benutzertyp 181; 200; 215; 301 Berechtigungsmatrix 182 Bereitstellungsweg 31; 46 Berichtsgenerator 280; 282 Beschreibungsmittel 119f. für Datenstrukturen 20 für Transportsysteme 63 Beschwerden, subjektive 327 Beständigkeit 138 Bestandsdaten 379 Betriebsmittelverbrauch 129 Bewerten 237; 250; 369 Bewertung 366; 371 Bewertungskriterien 96 für Methodenbanksysteme 300 für Planungssprachen 310 Bewertungskriterium 83 Bewertungsverfahren 366; 371 Bezeichner 109

Schlagwortverzeichnis Beziehung 24; 121; 210; 276 rekursive 119; 122 soziale 159 Beziehungskomplex 113 Beziehungstyp 24; 25; 119; 121 Big-bang 377 Bildschirm 322; 328 Bildschirmfilter 323 Bildschirmtisch 322 Bildwiederholfrequenz 319 Blockkonzept 264 Bombenwurfstrategie 373 Bottom-up-Strategie 372 Bruttobedarf 85 C 265 C++ 276f. cd 319 Chiffrierschlüssel 341 Client/Server-Architektur 351 COBOL-Quellcode 389 Common Lisp 289 Computer-Arbeitsplatz 327 Data Encryption Standard 345 Dataflex 284 Datei, invertierte 177 Daten 274 biometrische 68 personenbezogene 68; 72 Daten- und Funktionsanforderung 61 Datenabstraktion 254 Datenadäquanz 31 Datenanschluß-Komponente 314 Datenausgabe 180 Datenaustausch, elektronischer 221; 226f. Datenaustauschformat 218; 224 Datenauswahl 180 Datenbanksystem 35 relationales 389 Datenbeschreibungssprache 16 Datendefinitionssprache 16; 179f.; 185 Datenintegration 100 Datenintegrität 379 Datenkapsel 262 Datenkatalog 280 Datenkatalog-System 18; 30; 46; 59 Datenkomponente 29 lf. Datenkomprimierung 379 Datenkonsistenz 16 Datenkonvertierung 379ff. an einem Stichtag 382 permanente 381 schrittweise 381 Datenmanipulationssprache 177 Datenmigration 354; 379; 382f. Datenmodell 16 hierarchisches 21 logisches 17; 20; 178 physisches 178 relationales 22

405

semantisches 19; 109; 111 Datenobjekt 16 Datenobjekttyp 16; 109f. Datenorientierung 106; 359; 364 Datenredundanz 16; 24; 127f.; 383 Datenschutz 301 Datensicherheit 70; 342 Datensicht 18 Datenspiegelung 379; 383 Datenstruktur 100; 105; 119; 197ff. logische 120 physische 182 Datenstrukturkopplung 246 Datensystem 16ff.; 100; 174; 177ff.; 244; 375 Datentyp 262 abstrakter 255; 270; 271 Datentypkonzept 264 Datenunabhängigkeit 19 DatenVerarbeitungssystem 35; 42 Datenverwaltungssystem 177 DATEV 114 dB 319 dB(A) 319 DBMS 280 DEA 341 Deduktion 109 DES 341 DES-Chips 345 Desintegration 162 Detail-Pflichtenheft 93 Detaillierungsgrad 106 deterministisch 146 Dezentralisierung 105; 243; 245 Diagnose 366 Dialog 44; 330 benutzergefuhrter 53 gemischter 53 mit alternativen Eingabemöglichkeiten 212 systemgefuhrter 53 über Funktionstasten 212 Dialogflexibilität 44; 55 Dialogform 52ff.; 207 Dialoggestaltung 200; 333 Dialogkomponente 291; 295 Dialogmethode 148 Dialogsprache 209 Dialogsystem 330 Dialogtechnik 53; 200; 207 für den benutzergeführten Dialog 209 für den gemischten Dialog 210 für den systemgeführten Dialog 208 Dianieter 64 Dienstweg 61 Digraph 57 Direktweg 61 Dispersion 64 Dokumentation 264 des Nummernsystems 143 grafische 116 Dokumentieren 14; 175; 237

406

Schlagwortverzeichnis

Domäne 119 Download-Kopplung 248 Downsizing 280 dpi 319 Drei-Schema-Konzept 18; 30 Druckertisch 322 DSG 68 DSS 307 Durchdringungsgrad 359f. Durchlaufzeit 48; 67; 162; 169 DV-Abteilung 359 DV-Komponente 314 Easiest-Fiist-Strategie 372 Ebenen-Konzept 243 ECODEX 218 EDI 218; 230 EDIFACT 218; 224 Editor 280 Effektivtemperatur 326 Eiffel 275 Eigenentwicklung 88 Eigenerstellung 87 Eigenprogrammierung 188; 191f.; 198 Eindeutigkeit 138 Einfügeanomalie 132 Einfügung 352; 367 Eingangsgrad 63 Einsichtigkeit 238 Einzelarbeit 153; 159 Einzelzuordnung 44 EIS 36; 43 elektronische Kommunikation 228 elektronische Medien 220 elektronische Unterschrift 346 elektronischer Datenaustausch 221; 226f. elektronischer Markt 61 elektronischer Produktkatalog 229 elektronisches Postsystem 223f.; 230 Elementaroperation 207 Elternklasse 270 Empfangsschlüssel 346 Emulation 388 Emulator 386 Emulierer 386 Endbenutzersystem 188; 280 Ende-zu-Ende-Verschlüsselung 345 Engpaßfaktor 105 Entdeckungsphase 277 Entfaltung, persönliche 159 Entfernung 63f. Entfernungsmatrix 57; 63; 66 Entität 16; 24; 120 Entitätsklasse 16; 109 Entitätsmenge 16; 109 Entitätstyp 16; 24; 109; 119f. Entity-Relationship-Diagramm 21 Entity-Relationship-Modell 119ff. Entladen 384 Entscheidungskompetenz 153 Entscheidungsprozeß 42

Entscheidungsspielraum 153; 157 Entscheidungsunterstützungssystem 36; 307f.; 313 Entscheidungs Vorschlag 147 Entschlüsselung 341 Entwerfen der Arbeitsorganisation 44 der Datenstruktur 24 der Interaktionsaufgabe 52 des Datensystems 16 des Methodensystems 28 des Methodensystems und Methodenentwurf 38 des Sicherungssystems 68 des Transportsystems 57 von Methoden 41 von Nummernsystemen 139 von sachlogischen Datenstrukturen 20 Entwickeln der Arbeitsorganisation 200 der Benutzersichten 179 der funktionellen Lösung 196 der programmtechnischen Lösung 196 des Datensystems 177 des Kriterienkatalogs 96 des Methodensystems 188 des Sicherungssystems 232 des Transportsystems 218 Entwicklungsrückstau 83; 188; 195 Entwicklungsumgebung 281 Entwurf 19 Entwurfsrichtlinien 335 Enzyklopädie 18; 30; 46; 59 ER 280 ER-Editor 280; 282 Ereignis 366; 369 Ereignisaufzeichnung 232 Ergonomie 319 kognitive 330 Erklärungskomponente 291; 295 Erlernbarkeit 335 ERM 119 ERM-Ansatz 131 Erweiterbarkeit 188; 190; 253 ESS 36 Europäische Artikelnummer 143 Evaluation, heuristische 339 Expert Database System 248 Expertensystem 28; 287; 294 Expertensystem-Entwicklungsumgebung 290 Expertensystem-Shells 290 Expertenwissen 292 Extension 109 extensional 112 Fachbegriff 23; 109f. Fachwissen 111 Fakten 293; 296 Farbe 207 Fehler 68; 70; 366 Fehlerbehandlung 305

Schlagwortverzeichnis Fehlermeldung 214 Fehlerquote 144 Feinprojektierung 171ff.; 252ff. Feld, elektromagnetisches 328 Fenster 200f. Fenstertechnik 208 Fertigungs- und Montagedisposition 152 FIF0 28 Figur 336 Figurenelement 336 Flexibilität 238 Formalisierbarkeit 28; 54 Formalproblem 33f.; 146 Formalziel 1 lf.; 48; 55; 95; 173f.; 370 Formularanalyse 111 Forschungsbefunde 15; 42; 54; 67; 79; 89; 144; 160; 169; 215; 228; 240; 250; 284; 305; 317; 327; 338; 357; 371; 392 Frame 243; 287 Freiheitsspielraum 153; 158 Fremdbezug 87 Fremdbild 80 Fremdentwickler 89 Fremdentwicklung 87f. Fremdschlüssel 127; 130 FTAM 218 Führungsaufgabe 229 Führungsinformationssystem 307; 313 Funktion 83; 93; 105; 199; 271; 298; 307; 368;387 Funktionalität 332 Funktionsintegration 165 Funktionsmerkmal 83 Funktionstrennung 232 Funktionsumfang 281 Funktionsvorrat, eingebauter 309 Ganzheitlichkeit 155 GDSS 36 Gefahr 68; 70 Geheimbotschaft 341 Geheimnisprinzip 256 Geheimtext 341 Generizität 270 Geräteunabhängigkeit 386 Gesamtumstellung 374 Geschäftsprozeß 100; 104 Geschäftsvorgang 100 Gestalt 330 Gestalten der Interaktionsaufgabe 207 der Kommunikationsmittel 221 der Schnittstellen zwischen den Transportwegen 221 differentiell-dynamisches 332 der Topologie 65 Gestaltgesetz 330; 336 Gestaltpsychologie 330 Gestaltungsspielraum 47; 54 Gesundheit 327 Gesundheitsstörung 328

407

GMD 351; 386 Graph 20; 57; 63 Graphentheorie 63 Grenzregulation 155 Grob-Pflichtenheft 93 Grobprojektierung 9ff.; lOOff. Groupware 330; 332 Grundebene 302 Grundkonzeption 29; 45; 58; 84; 95 angepaßte 17; 101 Grundmodell der kryptographischen Verschlüsselung 342 des ERM 120 Grundsatz der Äquivalenz 52 der Aufgabenangemessenheit 333 der DIN 66234 Teil 8 333 der Erwartungskonformität 334 der Fehlerrobustheit 334 der Selbstbeschreibungsfähigkeit 333 der Steuerbarkeit 334 Grundschulung 361 Gruppe 138; 160f. Gruppenarbeit 81; 153 Gruppenzuordnung 44 Gruppieren von Objekten und Verrichtungen 204 Gültigkeit 146; 332 Handlung, deliktische 68; 70 Handlungsanweisung 154 Handlungsspielraum 153; 160; 194 Hardware-Bestand 85 Hardware-Schutz 363 Hardware- und Software-Technik 310 Hardware-Verträglichkeit 388 Hash-Verfahren 177 Häufigkeit 341 Häufigkeitsanalyse 343 Hauptspeicherbedarf 389 Hautausschlag 328 Heraufladen 243 Herunterladen 243 Heuristik 28; 33ff.; 163 heuristisch 110 Hierarchie 252 Hilfe 337 Hilfe-Information 214 Hilfe-System 330 Hilfsorganisation 185 Homonym 109 Horn-Klausel 289 Hybridsprache 290 Identifikation 232 Identifikationsnummer 136 Identifikationsrisiko 241 Identifikationsschlüssel 16; 127 Identifizieren 136f.; 307 Identifizierungsnummer 136f.

408

Schlagwortverzeichnis

Identitätskontrolle 181 Identnummer 136 IFPS/Plus 307 IKS-Abteilung 359 Implementierung 11; 262 Implementierungsvererbung 273 Indextabelle 177 Individualbegriff 109 Individualisierbarkeit 335 Individualsoftware 83; 87ff.; 364 Induktion 109 Inferenzfreiheit 255 Inferenzkomponente 291 Inferenzmaschine 287 Inferenzmechanismus 287; 294 Informationsangebot 57; 59 Informationsgehalt 128; 131 Informationsnachfrage 17; 57; 59; 111 Informationssystem-Bestand 106 Informationsteil 299 Informationsweit 83 Informationszentrum 188 INFPLAN 307; 313; 314; 315 Inklusion 113; 123 Installierung 173; 349ff.; 372ff. Installierungsart 374 Installierungsmethode 366; 373 Installierungsplanung 366; 369 Installierungsreihenfolge 376 Installierungsstrategie 372f. Installierungszeit 351; 355; 359f. Installierungsziel 351 f. Instanz 270 Instrumentalcharakter 236 Instrumente zur Begriffskonstruktion 112 Integration 75ff.; 162f.; 243ff. Anwendungsprogramme/Datenbanksysteme 245 Anwendungsprogramme/wissensbasierte Systeme 246 Ârbeitsorganisation/Methodensystem 248 der Systementwicklung 243 der Systementwürfe 75 diagonale 165 horizontale 165 Individualprogramme/Methodenbanksysteme 248 informations wirtschaftliche 165 innerbetriebliche 162; 166 organisatorische 162; 164; 166 technische 162; 163; 166; 169 vertikale 165 wissensbasierte Systeme/Datenbanksysteme 247 zwischen den Teilsystemen 76 zwischenbetriebliche 57; 61; 162; 166; 230 Integrationsanforderung 78; 96 Integrationsbedarf 76; 243 Integrationsdefizit 75; 78 Integrationsfeld 76; 244 Integrationsform 162

Integrationsmaßnahme 245 Integrationspotential 106 Integrationsprinzipien 162ff. Integrationsstrategie 243 Integrationstest 75; 356; 366; 368 Integrations Wirkung 162; 167; 169 Integrität, semantische 25 Intension 109 intensional 112 Interaktion 107 soziale 155 Interaktionsaufgabe 51; 158; 190; 202; 249; 330f. Interdependenz 75; 366; 370 Interpretationshilfe 301 Is.a-Beziehung 270 Istzustand 372 K.o.-Kriterium 92 Kapazitätsauslastung 48 Kardinalität 119 Kellerspeicher 262; 267 Kette 205 KI 188; 287 Kl-Sprachen 287ff. Kindklasse 270 Klartext 341 Klärung und Rekonstruktion der Fachbegriffe 115 Klasse 255; 270ff. Klassenbibliothek 270f. Klassifizieren 136; 138 Klassifizierung der Aussagen 116 Klassifizierungsmerkmal 139 Klassifizierungsnummer 136; 138 Klausel, logische 291 Knowledge Engineering 37 kognitiv 153 Kommando 298; 303 Kommandoprozedur 312 Kommandosprache 209; 298 Kommunikation 81 elektronische 228 Kommunikationsarchitektur 223 Kommunikationsergonomie 320; 330ff. Kommunikationsmittel 218; 228 Kommunikationssystem 100 Kommunikationstechnik 79 Kompatibilität 83; 386 Kompetenz 75 Kompilierer 262 Komplexität 100f.; 162; 167; 252ff. Komplexitätsgrad 119; 124 Komplexmethode 149 Kompliziertheit 162; 167 Konfiguration 83; 372 Konflikt 75; 78; 92f.; 294; 335; 351 Konfliktmanagement 351 Konnexion 113 Konsequenzanalyse 169 Konsistenz 238

Schlagwortverzeichnis Konsistenzprüfung 391 Konstruieren in Begriffen 110 Konstruktion 147 Konstruktionsansatz 20 Konstruktoperator 119 Kontaktfreudigkeit 80 Kontrast 319 Konvention 299 Konvertieren der Datenbestände 384 Konzepte höherer prozeduraler Programmiersprachen 264 objektorientierter Programmierung 272 Kooperation 75; 77 Koordination 75; 77 Koordinator 75; 79 Kopplung 243; 246 Kopplungsstrategie 247 Korrektheit 253 Kosten 311 Kosten/Nutzen-Analyse 151 Kostenziel 352 Kriterien 137; 311 Kriterienkatalog 92; 98 Kryptoanalyse 341 Kryptographie 341 Kryptologie 341 Kryptosystem 341 Laser-Drucker 326 Lauschangriff 73 Lautstärke 327 Leerkosten 372 Leistung 93 Leistungsmerkmal 83 Leistungsumfang 311; 317 Leistungsziel 352 Leitungsverschlüsselung 345 Lern- und Entwicklungsmöglichkeiten 156 Lemkomponente 291; 296 Lernstrategie 373 Lesbarkeit 252 Leuchtdichte 319 Lieferant 93 LIFO 28 Lisp 287; 289; 296 Lisp-Maschine 289 LoC 188 lokal komprimiert 258 Löschanomalie 133 Machtanwendung 357 Mainframe 280 Makro 200; 210 Makrosprache 210 Manipulation direkte 210f.; 215 symbolische 288 Markt, elektronischer 61 Maschinensprache 262 Maske 200

409

Maskenanwahl 214 Maskenkennzeichnung 213 Maskentechnik 208; 212 Maßzahl, graphentheoretische 63; 66 MAT-System 153 Materialbewertung 41 Materialbewertungsmethode 42 Matrix 307 Matrize 308 Maus 325 MCDSS 36 MEB 298; 303 Mechanismus, kognitiver 156 Medien, elektronische 220 Medienbruch 218 Medienbruch-Analyse 221 Mehrfachvererbung 270; 273 Mehrwertdienst 218 Meldung 214 MEMO 298; 305 Menge 129 Mengengerüst 92 Mensch/Aufgabe/Technik-System 352 Menü 200f. Menübefehl 200 Menükommando 200; 207 Menütechnik 208 Metapher 44; 200; 210 METHAPLAN 298 Methode(n) 11; 28; 32; 34; 41; 270; 274; 293 der Datenkonvertierung 379ff. der Feinprojektierung 252ff. der Grobprojektierung lOOff. der Installierung 372ff. der Programmadaption 386ff. zur Begriffskonstruktion 113 Methoden-Komponente 314 Methoden-Wiederverwendung 39 Methodenadministrator 30 Methodenattribut 40 Methodenbank 298 Methodenbanksysteme 193; 298ff. Methodenbasis 28; 38 Methodenbestand 30 Methodendokumentation 301 Methodenklasse 34f. Methodenkonsistenz 28 Methodenlücke 40 Methodenmodell 28 logisches 29; 189 physisches 189 Methodenredundanz 28; 40 Methodensammlung 300 Methodensicht 30 Methodensystem 28ff.; 100; 174; 188ff.; 244 organisationsweites 30 Methodenverwaltungssystem 298; 302 Migration 243; 354ff.; 364; 379 Migrationsstrategie 245; 382 Migrationsziel 354

410

Schlagwortverzeichnis

Minimalität und Sichtbarkeit der Schnittstellen 255 Mnemo 136 Modell 28; 40; 119; 146; 271; 307 abstraktes 146 der Arbeitsorganisation 201 formales 146 logisches llf.; 32; 76; 96; 101; 106; 173ff. mathematisches 146; 147 physisches 11; 173; 175; 190 Modellanalyse 31 lf. Modellansatz 20 Modellbildung 31 lf. Modellerstellung, flexible 309 Modellform 151 Modellformulierungssprache 305 Modellieren 307 Modellierung 151 Modellierungsgrundsatz 150 Modul 243; 252 Modula-2 264 Modularisierung 252 Modularität 243 Modulbildung 255; 256 Modulgeschlossenheit 255 Modulgröße 255 Modulkonzept 264 Modulkopplung 255 Möglichkeitsraum 50 MOORE 386; 389 Motivation 194 MPS36 Muß-Kriterium 92; 97 Mutation 177 Mutationsanomalie 127; 128; 177 N 319 NATURAL 386 Nachricht 270; 272 genormte 223 Nachrichtentyp 224 NBS 341 Nebenbedingung 146 Nettobedarf 85 Netz 73; 208 offenes 218 semantisches 287 Netz(werk)modell 21 Normalform 127ff. Normalformenlehre 20; 21; 127ff. Normalisierung 127ff. Normalisierungsregel 127 Nummer 136f. Nummernbereich 136 Nummernplan 136 Nummemschema 137 Nummernschlüssel 136 Nummernsystem 24; 136ff. Nummerung 136 Nummerungsobjekt 136; 139 Nutzen 342

Nutzung 106 Nutzungsphase 351 Object Pascal 275 Objective-C 275 Objekt 32; 70; 110; 200; 203; 270; 276f. Objekt/Verrichtung-Kombination 200 Objektbibliothek 270 Objektcode 386 Objektgruppierung 205 objektorientiert 270 Objektorientierung 391 Objektprinzip 49 Objektschutz 363 Objekttyp 109 abstrakter 271 Objekttypenmethode 20f.; lOOff. ODER-Rückkopplung 206 ODER-Verknüpfung nach ODERVerzweigung 206 ODER-Verzweigung 206 OE 372 Operation 22 Operations Research 147 Operatorüberladung 262 Optimalplanung 147 Optimierung, lineare 146f. Optimierungsalgorithmen 151 Optimierungsmodell 28; 35f.; 146ff.; 312 Optimierungsziel 150 OR 28 Ordnungskomponenten der Arbeitsorganisation 47 Ordnungsnummer 136 Organisationseinheit 154 Organisationsmittel 359; 362 Organisiertheit 47 Parallel-Nummernsystem 141 Parallelumstellung 369; 376 Parameter 182; 243; 298 genetischer 272 Parameterkopplung 246 Parameterversorgung 301 Parser 386 Partizipation 153 Partizipationsgrad 357 Partnerschaft 79 Paßwort 232 Paßworttechnik 238f. Paßworttest 240 Personalbeschaffung 361 Personalschulung 361 Pflichtenheft llf.; 92ff. Phase 203; 235 Piktogramm 200; 210; 215 Planung 307 Planungsaufgabe 37; 308 Planungssprachen 194; 307ff. Plattform 351 PLOT-Komponente 314

Schlagwortverzeichnis Polymorphismus 270; 274 Postsystem, elektronisches 223f.; 230 ppb 319 Prädikatenlogik 289 Primärdaten 379 Primärschlüssel 127; 129; 177 Primat 104 Prinzip 153; 252 der Ablehnung 238 der Abstraktion 254 der Arbeitsstrukturierung 156 der differentiellen Aufgabengestaltung 156 der flexiblen Aufgabengestaltung 156 der Hierarchisierung 258 der integrierten Dokumentation 259 der konstruktiven Voraussicht und methodischen Restriktion 254 der Lokalität 258 der Modularisierung 255; 259 der Parametrisierbarkeit 238 der Partizipation 155 der schrittweisen Verfeinerung 256 der Standardisierung 259 der Stetigkeit 197 der Strukturierung 257 der Unabhängigkeit 238 der Unsichtbarkeit 238 der Verantwortlichkeit 238 der Wiederverwendbarkeit 271 des Handlungsspielraums 157 Prinzipien beim Entwickeln von Sicherungsmaßnahmen 238 der Arbeitsorganisation 153 der Arbeitsplatzergonomie 319ff. der Aufgabengestaltung 155 der Gestaltpsychologie 336 der Kommunikationsergonomie 330ff. der Software-Entwicklung 252ff. soziotechnischer Systemgestaltung 154 Problemlösungsverfahren 30 Problemlösungswissen 32 Produktionsregel 287 Produktivität 197 Produktkatalog, elektronischer 229 Produktqualität 368 Programm 262 Programmablauf 298 Programmablaufsteuerung 298 Programmadaption 386ff. Programmanpassung 364 Programmbaustein 298f. Programmdokumentation 259 Programmgenerator 280 Programmiersprache 209; 262 deklarative 288 der vierten Generation 280ff. funktionsorientierte 289 höhere prozedurale 193; 195; 262ff. integrierte 282 integrierte prozedurale 283

objektorientierte 270ff. Programmiersystem 188; 193 Programmierung 262 lineare 146 objektorientierte 196f. Programmierverhalten 191 Programmiervorgabe 195; 262f. Programmigration 354; 386; 389; 392 Programmlaufzeit 387; 389 Programmstruktur 188 Projektbibliothek 79 Projektgruppe 368 Projektorganisation 75 Projektziel 92 Prolog 287; 289 Protokolldatei 239 Prototyp 282 Prototyping 37; 42; 79; 92; 97; 361 Prozedur 307 Prozeßkonzept 264 Prüfliste 327; 379; 382 Prüfprogramm 129 Prüfziffer 136 Psychosomatik 319 Public-Key-System 345 Pufferungsstrategie 248 QbE 280 Qualifikation 194; 359; 361 Qualifikationsanforderung 167 Qualität 48 Qualitätsniveau 377 Qualitätssicherung 11; 14; 173; 176 Qualitätsziel 352 Radius 64 Randposition, relative 64 Rang 203 Rangordnung 252; 258 Rationalisieningsdruck 167 Raumbedarf 204; 362 Raute 121 RDBMS 119 Realproblem 33f.; 146 Referenzmodell 31; 47 Reflexionsgrad 319 Regel 287; 291; 294 Reichweite 321 Rekonfiguration 359; 364; 372 Rekonstruieren der Fachbegriffe 23 Rekonstruktion 20 Relation 16; 22; 127ff. Relationenmodell 119; 127f. Relationenschema 119 Relationentheorie 22 relative Unabhängigkeit der Organisationseinheit 154 Releasewechsel 379; 384 Reorganisation 379 Repository 391 Restriktion 146

412

Schlagwortverzeichnis

Reverse Engineering 391 Risiko 68; 372 Robustheit 253 RSA341 Rückwärtsverkettung 289; 295 Sachaufgabe 32; 51; 53; 158; 190; 331 Sachcharakter 203 Sachnüttel 44; 51 Sachziel llf.;95; 173f.; 369 SAL 280 Sanktionierbarkeit 238 SAP 372 Satz 109 Schaden 70 Schalenmodell 234 Schema externes 18 internes 19; 30 konzeptionelles 18; 30 Schlüssel 119; 136; 177; 341f. geheimer 346 öffentlicher 346 Schlüsselattribut 16; 119; 127 Schlüsselkonzept 124 Schlüsselmerkmal, technologisches 158 Schlüsselraum 341; 346 Schlüsselsystem 344 Schlüsseltext 341 Schnittstelle 62; 78; 96; 272; 368; 382 beim Entwerfen der Arbeitsorganisation 45 beim Entwerfen des Datensystems 17 beim Entwerfen des Methodensystems 29 beim Entwerfen des Sicherungssystems 69 beim Entwerfen des Transportsystems 58 beim Entwickeln der Arbeitsorganisation 201 beim Entwickeln des Datensystems 178 beim Entwickeln des Methodensystems 189 beim Entwickeln des Sicherungssystems 233 beim Entwickeln des Transportsystems 219 Schnittstellenanforderung 59 Schnittstellentest 75 Schnittstellenvererbung 273 Schreibmarke 324 Schreibtisch-Metapher 200 Schulung 79 Schulungsprogramm 359; 361 Schutzmaßnahmen 363 screen painter 282 SEDAS 218; 226 SDS218 Segmentierungsproblem 183 Sehentfernung, optimale 322 Sekundärschlüssel 127; 177 Selbstbild 80 Selbstregulation 155 Selbstverwaltung 338 Semantik 109

Sendeschlüssel 346 Sicherheit 68; 342; 344 Sicherheitsrisiken 69; 72 Sicherheitsziel 68f.; 70 Sicherungsbedarf 68; 70 Sicherungsmaßnahme 232f.; 342 Sicherungssystem 68ff.; 100; 175; 232ff. integriertes 232f. unternehmensweites 234 Sichtdaten 180 Simula 274 Simulation 28; 386; 388 Simulationsmodell 35f. Smalltalk 275 Software Engineering 37 Software-Beschaffung 190 Software-Entwicklung 105; 190; 252ff. dezentrale 192 Software-Ergonomie 330f. Software-Qualität 253 Software-Wiederverwendung 188 soziotechnisch 153 Speicheranomalie 127 Speicherkosten 383 Speichermedien 18; 364 Speicherplatz 128 Spezifikation 277 Spezifizierung 16; 17; 29; 45; 58 SPSS 298 SQL 185; 243; 280; 284 Stammdaten 379 Standard-Konverter 225 Standardisierung 252 Standardsoftware 83; 87f.; 364; 377 Standardsoftware-Produkt 88 Standort 204 Start der Verarbeitung 368 Statistik-Paket 303 Stelle 44 Stellenanzahl 138f. Stellenbildung 50 Steuerinformation 213 Stichtagsumstellung 369; 376 stochastisch 146 Störung, psychosomatische 319 Strategie 160; 372 beim Anwenden der Prinzipien 160 der evolutorischen Systemgestaltung 373 korrigierende 160 vorbeugende 160 vorhersehende 160 Struktur 252; 257 der Hierarchie 258 der Vorbereitungsaufgaben 360 des Pflichtenhefts 93 Strukturgleichheit 146 Strukturiertheit 32f.; 54 Strukturorganisation 46; 359; 362 Substantivanalyse 111 Substitution 341; 343 Subsystem 100

Schlagwortverzeichnis Suchcode 136; 142 SVD92 Synonym 109 Syntax-Baum 386 Systemabbruch 232 Systemauslastung 389 Systemauswahl 13; 93 Systembegriff 256 Systementwicklung llf.; 173f.; 178; 189; 219; 233 Systementwurf 1 lf.; 17; 29; 58; 69; 75; 106 Systemgliederung llf.; lOOf.; 174 Systemintegration 75; 78; 173; 175; 243ff. systemkonforme Spiegelung von Datenbeständen 383 Systemkonzept 35; 95; 243; 244 Systemmeldung 214 Systemsoftware-Bestand 85 Systemtechnik 11; 13 Systemübergabe 370 Szenario 379 Tabelle 127; 307 Tabellenkalkulationssystem 312 Tastatur 322; 324 Tastatur-Layout 324 Tastaturbelegung 324 Tastaturhöhe 324 Tastaturneigungswinkel 324 Tastenform 324 Tätigkeitsspielraum 153; 157 Taxonomie 287 Technikbedarf 83ff.; 96 Technikbestand 85; 96 teilautonome Gruppe 157 Teilprojekt ll;100f.;201 Teilsystem 11; 77; lOOf.; 277 Terminziel 352 Test 75 retrospektiver 152 Testen 14; 173; 175; 264 der funktionellen Lösung 196 der Geräte 363 der Integrationsmaßnahmen 250 der programmtechnischen Lösung 196 projektbegleitendes 78 systematisches 78 Textverarbeitung 338 Theorie unscharfer Mengen 149 Ton 208 Top-down-Ansatz 123 Top-down-Strategie 372 Topologie 57; 62 Transaktion 177 Transaktionsbetrieb 245 Transaktionskopplung 247f. Transaktionsprotokoll 232; 238f. Transformation 26; 119f. Transformationsregel 19 Transformationswerkzeug 390 transitiv 16; 127

413

Transport 57 Transportdienst 218 Transportmodell 219 Transportsystem 57ff.; 100; 175;218ff. unternehmensweites 58 Transportweg 57ff.; 219 Typart 271 Übergabeparameter 248 Überprüfbarkeit 238 Übertragbarkeit 266; 386 Umgebung 325f. Umgebungseinflüsse 70; 326 Umgehbarkeit 238 Umstellung 375ff. Umstellungsaufwand 387 Umstellungseinrichtung 388 Umstellungshilfsprogramm 388 Umstellungsmakro 388 Umstellungsprogramm 388 Umstellungsroutine 388 Unistellungstest 386; 388 Umweltdynamik 158 UND-Verknüpfung nach UND-Verzweigung 205 UND-Verzweigung 205 Ungewißheit, technische 158 Unternehmensführung 165 Unterschrift, elektronische 346 Unterstützungsaufgabe 369 Unzuverlässigkeit 68 Ursache 77; 366 Ursachenanalyse 366 Validität 146 VANS 218 Variable 272 Veränderlichkeit 32f.; 211 Verbund-Nummernsystem 141 Vererbung 270; 272f. Vererbungsgraph 270 Vererbungshierarchie 277 Verfeinerung, schrittweise 197 Verfügbarkeit 68; 359; 363 Verkopplung, technische 158 Verrichtung 32; 200; 203 Verrichtungsfolge 200, 205 Verrichtungsgruppierung 205 Verrichtungsprinzip 49 Verschlüsselung 136; 341 integrierte 345 kryptographische 341 ff. monoalphabetische 343 polyalphabetische 343 private 345 Verschlüsselungsalgorithmus 341 Verschlüsselungsmethode, kryptographische 341 ff. Verschlüsselungssystem 345 Verständlichkeit 252; 266 Vertauschung 343; 346

414

Schlagwortverzeichnis

Verteilung 59; 192 Verträglichkeit 83; 85; 96; 253; 386 Verträglichkeitseinrichtung 387 Vier-Augen-Prinzip 232 Vollzugsmeldung 214 Vorbedingung 271 Vorbereiten der Installierung 359 Vorbereitung 364; 380 datentechnische gerätetechnische 363 organisatorische 362 personelle 361 programmtechnische 363 räumliche 362 Vordruck 218; 222 Vordruckgestaltung 222 Vordruckverwaltung 223 Vorgang 162 Vorgangsintegration 167 Vorgangskette 57; 61 Vorgehensmodell 333; 377 Vorgehensweise bei der Grobprojektierung 100 bei der Installierung 372 bei der objektorientierten Programmierung 276 bei der Systemintegration 249 bei kombinierten Verschlüsselungssystemen 344 beim Entwerfen der Arbeitsorganisation 49 beim Entwerfen des Methodensystems 39 beim Entwerfen des Sicherungssystems 71 beim Entwickeln der Arbeitsorganisation 203 beim Entwickeln des Methodensystems 195 beim Entwickeln des Sicherungssystems 235 beim Entwickeln des Transportsystems 220 Vorprogrammierung 191 Vorteil 375; 376 Vorwärtsverkettung 294 Wahrscheinlichkeitstheorie 146; 149 Warnmeldung 214 Wartbarkeit 252; 266 Wartung 148; 188; 281 Wechselbeziehung 330 Werkzeug 25 Wertebereich 24 Widerstand 357 Wiederanlauf 232; 239 Wiederanlauf-Verfahren 232 Wiederholbarkeit 373 Wiederverwendbarkeit 252f. Wiederverwendung 259 Wirtschaftlichkeit 85; 96; 167 Wirtschaftsinformatik-Ausbildung 15 Wissen 287 deklaratives 293 flaches 37

prozedurales 293 unscharfes 292 Wissensakquisition 287; 293 Wissensakquisitions-Komponente 291; 295 Wissensbasis 291 f. Wissensdarstellung 287; 291 Wissensdomäne 287 Wissenselement 292 Wissenserwerb 287 Wissensingenieur 287; 293 Wissenskomponente 291 Wissensmodell 28; 37 Wissensrepräsentation 287 Wissens Verarbeitungssprachen 193; 287ff. Wunsch-Kriterium 97 Zählnummer 138 Zeichengröße 323 Zeichenkontrast 323 Zeiger 177 Zeilenabstand 323 Zeitdauer 204 Zeitpunkt 204; 376 Zeitraum 204; 374 der Hierarchie 258 Zentralität, relative 64 Zentrum 64 Zerlegung 54; 252; 257 Zerlegungspunkt 64 Ziel der Feinprojektierung 174 der Grobprojektierung 12 der Installierung 352 des Projekts 95 flexibilitätsorientiertes 49 individual-soziales 48 ökonomisches 77 sozial-psychologisches 154; 155 soziales 154; 155 strategisches 106 wirtschaftliches 48 Zielbeziehung 48 Zielertrag 92 Zielfunktion 146 Zielinhalt 97 Zielkriterium 83 Zielplattform 351; 354 Zugehörigkeitsfunktion 149 Zugriff 137 Zugriffsbedingung 182 Zugriffsberechtigung 181; 232 Zugriffskontrolle 181 Zugriffspfad 182; 183 Zugriffspfadmatrix 183 Zugriffsrecht 273 Zukunftsbild 379 Zustand 200; 207; 272 Zuverlässigkeit 162; 167