Ganzheitliches Informationsmanagement. Band 2 Ganzheitliches Informationsmanagement: Band II: Entwicklungsmanagement [4. überarb. und akt. Aufl.] 9783486842883, 9783486582338

Citation preview

EIii M

ml

Ganzheitliches Informationsmanagement Band II: Entwicklungsmanagement Mit einem Fallbeispiel von Matthias Almstedt, Frank Aschenbach und Dr. Edda de Boer

von Universitätsprofessor

Dr. Jörg Biethahn Dr. Harry Mucksch und Professor

Dr. Walter Ruf

R. Oldenbourg Verlag München Wien

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

© 2007 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0 oldenbourg.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes 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. Lektorat: Wirtschafts- und Sozialwissenschaften, [email protected] Herstellung: Anna Grosser Satz: DTP-Vorlagen des Autors Coverentwurf: Kochan & Partner, München Gedruckt auf säure- und chlorfreiem Papier Gesamtherstellung: Druckhaus „Thomas Müntzer" GmbH, Bad Langensalza ISBN 978-3-486-58233-8

Vorwort zur 4. Auflage Informationsmanagement ist eine vielschichtige Aufgabe. Zum einen umfasst es verschiedene, zeitlich aufeinander folgende Aktivitäten, die aufgrund der Komplexität selbst mit Hilfsmitteln nicht vollständig beschrieben werden können. Zum anderen hängen diese Aufgaben auch von dem Ziel ab, das mit der Bewältigung vieler Einzeltätigkeiten erreicht werden soll. Diese bestimmen ganz wesentlich den Blickwinkel, aus dem das Informationssystem gesehen wird und was man von diesem erwartet. Unsere Vorstellung von einem Informationssystem sollte sich nicht an den in der Praxis üblichen Programmsammlungen orientieren, sondern das erfüllen, was man nach heutiger Kenntnis von einem Informationssystem erwarten kann. Die ständig steigenden Erwartungen bzw. erwarteten Ziele, aber auch die wissenschaftlichen und technologischen Möglichkeiten haben zu neuen und ζ. T. besseren Formen der Konzeption und Implementierung von Informationssystemen geführt. Viele dieser Vorgehensweisen oder auch Sichten wurden publiziert, sind dadurch aber nicht richtiger oder besser geworden. Häufig entstand daraus auch eine Art Glaubenskrieg darüber, welche dieser Sichten verfolgt werden sollen. Wir sehen unsere Aufgabe darin, die Sichten der Informationssystemherstellung im Hinblick auf ein ganzheitliches Informationsmanagement zu beschreiben. Durch die Überarbeitung von Band I in der 6. Auflage entstand die Notwendigkeit auch diesen vorliegenden Band entsprechend anzupassen. Dabei haben wir uns dazu entschlossen, die bewährte Grundstruktur prinzipiell beizubehalten und aktuelle Erweiterungen zusätzlich zu integrieren. Da die Existenz von Programmen, mit denen organisatorische Abläufe gestaltet werden, eine notwendige Voraussetzung für den Betrieb von Rechnern ist, wurde das Management ihrer Entwicklung - besser das Entwicklungsmanagement - auch bei dieser Auflage mehr in den Vordergrund gestellt. Dabei interessiert uns nicht die Erstellung systemnaher Software; wir konzentrieren uns auf Programme, die ihr Anwendungsgebiet im Bereich der Betriebe haben, so dass dieser 2. Band des Ganzheitlichen Informationsmanagments der Darstellung des Softwareentwicklungsprozesses und der dabei zu beachtenden Konzepte und Prinzipien dient. In der letzten Zeit wird immer wieder die Frage nach der richtigen oder besten Form der Programmierung gestellt. Es stellt sich die Frage, woran man sich orientieren soll:

VI -

-

Vorwort Sind es primär die Daten, die gestaltet werden sollten, damit darauf aufbauend jede Aufgabe bewältigt werden kann? Oder sollte man sich zunächst auf die zu bewältigenden Funktionen konzentrieren? Könnte nicht auch eine Zusammenfassung ständig im Zusammenhang auftretender Funktionen zu so genannten Prozessen von Vorteil sein? Oder steht der organisatorische Ablauf und damit die organisatorische Einbettung des zu entwickelnden Informationssystems im Vordergrund? Führt die Konzentration auf nicht hinreichend problemorientierte Einheiten durch zu frühe Trennung von Funktionen und Daten uns nicht zu künstlichen und ablauftechnisch ungünstigen Konstruktionen? Daraus ergibt sich die Frage: Können Zusammenfassungen in Form von objektorientierten Abbildungen Vereinfachungen bringen? Lassen sich eventuell auch alle Sichten vereinen?

Ein ganzheitliches Informationsmanagement muss all diese Fragen bei der Entwicklung von betrieblichen Anwendungssystemen mitberücksichtigen. Es wird deutlich werden, dass eine effiziente und wirtschaftliche Softwareentwicklung ohne ein funktionierendes Datenmanagement nicht möglich ist. Vielmehr müssen Daten- und Entwicklungsmanagement in einem wechselseitigen Prozess verankert sein. Aus diesem Grund wird in Kapitel 2 zunächst auf das Datenmanagement eingegangen. Mit den Fragen nach der Sichtweise wollen wir uns im 3. Kapitel beschäftigen, hierbei war es angebracht, ein neues Kapitel zu UML (Unified Modelling Language) zu integrieren, bevor wir im 4. Kapitel die in den Phasen des Entwicklungsprozesses einzuhaltenden Prinzipien und Vorgehensweisen behandeln, die entscheidend für die Entstehung qualitativ hochwertiger und zugleich wirtschaftlicher Software sind. Die einzuhaltenden Prinzipien und Vorgehensweisen lassen sich dabei unterteilen in entwicklungsphasenunabhängige Prinzipien und in solche, die nur in bestimmten Phasen zur Anwendung kommen. Dabei wird Bezug auf die Phasen genommen, die wir im Band I in unserer Rahmenkonzeption skizziert haben. Wegen der mit der Softwareentwicklung verbundenen hohen Kosten muss zudem auf ein effektives Qualitätsmanagement Wert gelegt werden, das in Kapitel 4.3 beschrieben wird. Erstmalig haben wir dieses Kapitel ergänzt um Ausführungen zu unternehmensübergreifenden Geschäftsprozessen im Rahmen von „Enterprise Application Integration" und den Best Practice Empfehlungen zu ITIL, die in letzter Zeit zunehmend Verbreitung in der Industrie finden.

Vorwort

VII

In Kapitel 5 wird dann die im 1. Band skizzierte Rahmenkonzeption zur Entwicklung ganzheitlicher Informationssysteme unter dem Aspekt der behandelten Methoden, Prinzipien und Konzepte verfeinert. Den Abschluss bildet das 6. Kapitel mit einer Fallstudie, die den beschriebenen ganzheitlichen Softwareentwicklungsprozess nochmals wiederholt und verdeutlicht. Wir danken den Mitarbeitern der Abteilung I des Instituts für Wirtschafitsinformatik für ihren Einsatz bei der Erstellung des vorliegenden Bandes. Besonders hervorzuheben ist hier (in alphabetischer Folge) die Arbeit von Herrn Dr. H. Fischer, Frau Dipl.-Wirt.-Inf. A. Höhn, Herrn Dr. M. Hieronimus, Herrn Dipl.-Kfm. R. Ike, Herrn Dr. A. Lackner, Herrn L. Meier, Herrn P. Opielka und Herrn Dr. M. Zilling. An der Hochschule Albstadt-Sigmaringen bedanken wir uns bei Herrn Bauer. Bedanken möchten wir uns auch bei Herrn Prof. Dr. M. Schumann für seine Verbesserungs- und Ergänzungsvorschläge. Nicht zuletzt bedanken wir uns auch wie immer beim Oldenbourg-Verlag und hier besonders bei Herrn M. Weigert und Herrn Dr. J. Schechler.

Jörg Biethahn Harry Mucksch Walter Ruf

Inhaltsverzeichnis Vorwort zur 4. Auflage

V

Abbildungsverzeichnis

XV

Abkürzungsverzeichnis

XXIII

1 Einführung in die Entwicklung ganzheitlicher Informationssysteme 1.1 Bedeutung des Entwicklungsmanagements für das ganzheitliche Informationsmanagement 1.2 Ziele und Begriffe des Entwicklungsmanagements 1.3 Aufgaben des Entwicklungsmanagements 2 Datenmanagement - Voraussetzung des Entwicklungsmanagements 2.1 Begriff und Bedeutung des Datenmanagements 2.2 Aufgaben und Funktionen des Datenmanagements 2.2.1 Datenarchitektur und Datenanalyse 2.2.2 Datenbankdesign 2.2.3 Datenbankbetrieb 2.2.4 Copy-und Extraktmanagement 2.2.5 Benutzerservice 2.3 Grundlagen der logischen Daten- und Datenbankorganisation 2.3.1 Logische Dateneinheiten 2.3.2 Strukturen in Datensätzen 2.3.3 Die logische Organisation von Dateien 2.3.4 Logische Strukturen zur Verknüpfung von Datenobjekten 2.3.5 Suchbegriffe und logische Zugriffspfade 2.4 Vorgehen bei der Konstruktion und Modellierung eines betrieblichen Datensystems 2.4.1 Grundlegende Begriffe 2.4.2 Datenbankmodelle, ihre Entwicklung und Bedeutung 2.4.2.1 Datenbankmodelle der 1. Generation 2.4.2.2 Die 2. Datenbankgeneration: Das relationale Datenbankmodell 2.4.2.3 Die Entwicklung abstrakter, semantischer Datenmodelle 2.4.2.4 Höhere Datenbankmodelle 2.4.3 Entwicklung des von Ausprägungen des Zielsystems unabhängigen konzeptionellen Datenbankschemas 2.4.4 Umsetzung in das relationale Datenbankmodell 2.4.5 Logisches Design von Anwendungen

1 2 4 9 13 14 28 29 31 32 33 33 34 35 38 40 42 47 49 50 52 54 57 59 74 92 100 115

χ

Inhaltsverzeichnis 2.5 Physische Datenorganisation - DV-technische Voraussetzung für die Funktion »Datenbankdesign« 2.5.1 Physische Speicherstrukturen 2.5.1.1 Verfahren der Adressierung 2.5.1.2 Verfahren zur Speicherung 2.5.2 Sortieren 2.5.3 Suchverfahren 2.5.3.1 Suchen mittels Algorithmen 2.5.3.2 Suchen durch Adressberechnung 2.5.3.3 Suchen mittels Adressverkettung 2.5.3.4 Suchen über Inhaltsverzeichnisse 2.5.4 Dateiorganisationsformen 2.5.4.1 Dateiorganisationsformen ohne Sekundärdaten 2.5.4.2 Dateiorganisationsformen mit Sekundärdaten 2.5.5 Komprimierungstechniken 2.6 Datenbanksysteme und Datenbankverwaltung 2.6.1 Forderungen und Ziele bei der Gestaltung eines Datenbanksystems 2.6.2 Architekturen von Datenbanksystemen 2.6.3 Datenbankverwaltung und-betrieb 2.6.3.1 Datendefinition und -manipulation in einem Datenbanksystem 2.6.3.2 Gewährleistung der Datenintegrität 2.6.3.3 Mechanismen zur Einhaltung der Datenschutzvorschriften 2.7 Weitergehende Ansätze der Datenhaltung und -Verwaltung 2.7.1 Erweiterte Datenbankmodelle 2.7.1.1 Objektorientierte Datenbanksysteme 2.7.1.2 Aktive Datenbanksysteme 2.7.2 Erweiterte Systemarchitekturen 2.7.2.1 Client/Server-Datenbanken 2.7.2.2 Mehrrechner- und verteilte Datenbanksysteme 2.7.3 Ausgewählte Anwendungsbereiche 2.7.4 Das Data Warehouse-Konzept 2.7.4.1 Charakteristika einer Data Warehouse-basierten betrieblichen Informationsversorgung 2.7.4.2 Idealtypische Architektur 2.7.4.3 Komponenten eines Data Warehouses 2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten 2.8.1 Bedeutung von Meta-Daten für die Informationsverarbeitung 2.8.2 Werkzeuge zur Beschreibung von Meta-Daten 2.8.2.1 Data Directories 2.8.2.2 Data Dictionaries 2.8.2.3 Repositories

118 118 119 120 125 126 127 131 136 143 155 155 157 168 172 173 182 187 188 190 197 198 199 199 202 205 208 210 217 218 219 224 227 234 235 239 239 240 256

Inhaltsverzeichnis 3 Sichten der Softwareentwicklung 3.1 Die historischen Sichten auf ganzheitliche Informationssysteme 3.2 Datenorientierte Softwareentwicklung 3.3 Funktionsorientierte Softwareentwicklung 3.4 Prozessorientierte Software-Entwicklung 3.5 Organisationsorientierte Software-Entwicklung 3.6 Objektorientierte Softwareentwicklung 3.6.1 Begriffliche Grundlagen 3.6.2 Unified Modelling Technique (UML) 3.6.2.1 Grundprinzipien der Unified Modelling Language 3.6.2.2 Diagrammarten in UML 2.0 3.7 Herleitung der ganzheitlichen Softwareentwicklung 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 4.1 Prinzipien der Softwareentwicklung 4.1.1 Allgemeine Prinzipien 4.1.1.1 Prinzip der Datenunabhängigkeit 4.1.1.2 Prinzip der Standardisierung 4.1.1.3 Prinzip der Abstraktion 4.1.1.4 Prinzip der Hierarchisierung 4.1.1.5 Prinzip der Modularisierung (inkl. Objekte) 4.1.1.6 Weitere Grundsätze 4.1.2 Prinzipien zur Problem- und Systemspezifikation 4.1.2.1 Prinzip der Vollständigkeit 4.1.2.2 Prinzip der Intersubjektivität 4.1.2.3 Prinzip der Integrierbarkeit 4.1.2.4 Prinzip der vollständigen Schnittstellenspezifikation 4.1.3 Prinzipien zur Systemkonstruktion und -Implementierung 4.1.3.1 Prinzip des Information Hiding (Geheimnisprinzip) und der Kapselung 4.1.3.2 Prinzip der Strukturierung 4.1.3.3 Prinzip der linearen Kontrollstrukturen 4.1.4 Prinzipien zur Systemverifikation, -einfuhrung und -Wartung 4.1.4.1 Prinzip der externen Qualitätssicherung 4.1.4.2 Prinzip der frühzeitigen Verifikation 4.1.4.3 Prinzip der sukzessiven Systemeinführung 4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung 4.2.1 Möglichkeiten und Grenzen von Methoden 4.2.2 Anforderungen an Methoden der Softwareentwicklung 4.2.2.1 Allgemeine phasenunabhängige Anforderungen 4.2.2.2 Phasenspezifische Anforderungen 4.2.3 Allgemeine Vorgehensweisen 4.2.3.1 Die Top-Down-Methode

XI 261 261 264 265 269 280 284 285 291 292 293 300

303 303 303 304 304 308 318 319 325 325 326 326 327 328 328 329 331 331 332 332 333 334 334 335 338 338 340 342 343

XII

Inhaltsverzeichnis

4.2.3.2 Die Bottom-Up-Methode 345 4.2.3.3 Die kombinierte Top-Down/Bottom-Up-Methode 347 4.2.4 Phasenspezifische Vorgehensweisen 348 4.2.4.1 Methoden für die Spezifikation: Structured Analysis (SA) 348 4.2.4.2 Methoden für die Konstruktion 352 4.2.4.3 Verfahren der Implementierung: Jackson-StructuredProgramming 367 4.2.5 Phasenübergreifende Vorgehensweisen 374 4.2.5.1 Methoden für die Spezifikation und Konstruktion: Structured Analysis and Design Technique (SADT) 374 4.2.5.2 Methoden für die Spezifikation, Konstruktion und Implementierung: Jackson-System-Development (JSD)..380 4.3 Qualitätsmanagement von Software 388 4.3.1 Begriffe zur Qualitätssicherung und Darstellung der Qualitätsmerkmale 389 4.3.2 Möglichkeiten zur qualitativen Beurteilung von Software 397 4.3.3 Softwaremetriken 400 4.3.4 Maßnahmen zur Qualitätssicherung 403 4.3.4.1 Qualitätssicherung und Entwicklungskosten 403 4.3.4.2 Einzelmaßnahmen 404 4.3.4.3 Maßnahmen bei eingesetzter Software 408 4.3.5 Normen zum Qualitätsmanagement 411 4.3.5.1 Qualitätsmanagement gemäß ISO 8402 412 4.3.5.2 Zertifizierung gemäß ISO 9000 bis 9004 413 4.4 Serviceorientierter IT-Managementprozess (ITIL) 417 4.4.1 Service Support 421 4.4.2 Service Delivery 426 4.4.3 Security Management (Sicherheitsmanagement) 432 4.4.4 Business Perspective 435 4.4.5 Application Management 43 6 4.4.6 ICT Infrastructure Management 438 4.4.7 Planning to Implement Service Management 439 4.4.8 Zusammenfassung und Bewertung 443 4.5 Enterprise Application Integration 445 5 Vorgehensweise zur Entwicklung ganzheitlicher Informationssysteme 5.1 Phase 1: Problemspezifikation (Anforderungsspezifikation) 5.1.1 Problemanstoß 5.1.2 Zielanalyse 5.1.3 Strategische Ausrichtung 5.1.4 Systemabgrenzung und Formulierung des Grobsollkonzeptes 5.1.5 Erhebimg des Istzustands 5.1.5.1 Funktionsanalyse (Aufgabenanalyse)

449 450 451 452 454 455 456 457

Inhaltsverzeichnis

5.2

5.3

5.4 5.5 5.6 5.7 5.8

5.1.5.2 Inhaltliche Datenanalyse 5.1.5.3 Qualitative Datenanalyse 5.1.5.4 Schnittstellenanalyse 5.1.5.5 Schwachstellenanalyse 5.1.6 Herleitung der strategischen Stoßrichtung 5.1.7 Wirtschaftlichkeitsbeurteilung und Bestimmung der Anforderungen Phase 2: Die Systemspezifikation 5.2.1 Datenbereitstellungsplanung 5.2.2 Informationssystemdesign 5.2.3 Kommunikationsnetzdesign 5.2.4 Durchführbarkeitsstudie 5.2.5 Probleme der Abgrenzung von Systemspezifikation und Systemkonstruktion Phase 3: Systemkonstruktion 5.3.1 Systemzerlegung 5.3.2 Modularisierung 5.3.3 Programmfestlegung 5.3.4 Programmentwurf 5.3.5 Festlegung des Hard- und Softwarebedarfs 5.3.6 Dokumentation Phase 4: Systemimplementierung und -tests Phase 5: Systemverifikation Phase 6: Systemeinführung und -Übergabe Phase 7: Systemwartung Resümee

6 Fallbeispiel zur ganzheitlichen Software-Entwicklung 6.1 Vorbemerkung 6.2 Problemspezifikation: Darstellung des Fallbeispiels 6.3 Systemspezifikation 6.3.1 Datenorientierte Modellierung 6.3.2 Funktionsorientierte Modellierung 6.3.3 Prozessorientierte Entwicklung 6.3.4 Organisationsorientierte Modellierung 6.3.5 Objektorientierte Modellierung 6.4 Systemkonstruktion 6.4.1 Datensicht 6.4.2 Funktionssicht 6.4.3 Prozess- und Organisationssicht 6.4.4 Objektorientierte Sicht 6.4.5 Hard- und Softwareauswahl auf der Basis des Kommunikationsnetzdesigns 6.5 Systemimplementierung und -test

XIII 458 460 461 462 463 463 464 466 466 467 469 470 471 472 473 474 475 476 477 477 478 479 479 480 483 483 484 495 495 499 504 507 508 519 519 524 526 530 537 540

XIV 6.6 Systemverifikation 6.7 Systemeinfuhrung und -Übergabe 6.8 Systemwartung

Inhaltsverzeichnis 552 556 558

Literaturverzeichnis

561

Stichwortverzeichnis

587

Abbildungsverzeichnis Bild 1 -1: Bild 1-2: Bild 2-1: Bild 2-2: Bild 2-3: Bild 2-4: Bild 2-5: Bild 2-6: Bild 2-7: Bild 2-8: Bild 2-9: Bild 2-10: Bild 2-11: Bild 2-12: Bild 2-13: Bild 2-14: Bild 2-15: Bild 2-16: Bild 2-17: Bild 2-18: Bild Bild Bild Bild Bild Bild Bild

2-19: 2-20: 2-21: 2-22: 2-23: 2-24: 2-25:

Bild Bild Bild Bild Bild Bild

2-26: 2-27: 2-28: 2-29: 2-30: 2-31:

Bild 2-32: Bild 2-33:

Hilfsmittel des Software-Engineerings Entwicklungsschritte der methodischen Hilfsmittel des Software-Engineerings Informationsverdichtung innerhalb der betrieblichen Hierarchie Einordnung des Datenmanagements Gliederung der Datenorganisation Datei- und datenbankorientierter Ansatz Komponenten des betrieblichen Informationssystems Operationen mit einer Datenbasis Datenbankanfrage Funktionen und Komponenten des Datenmanagements Hierarchischer Aufbau logischer Dateneinheiten MITARBEITER-Datensatz in Pascal-Notation Normale Segmentierung am Beispiel eines Lieferantensatzes Elementarfelder, multiple Felder und Periodengruppen Kategorien von Dateien Lineare Verknüpfungen am Beispiel einer Mitarbeiterdatei Hierarchische Struktur mit unterschiedlichen Dateien der Funktion Wareneinkauf Netzwerkartige Struktur mit unterschiedlichen Dateien der Funktion Wareneinkauf Relationale Struktur: Tupel, Attribute am Beispiel der Relation LIEFERANT Relationale Struktur: Wertemenge, Grad und Ordnung einer Relation am Beispiel der Relation LIEFERANT Operatoren der relationalen Algebra Entity-Typ »Kunde« Entity-Typ »Kunde« mit Attributen Rollenkonzept im ERM Zweistelliger Beziehungs-Typ mit Angabe der Kardinalität Generalisierung/Spezialisierung auf Datenobjektebene Komplexität eines zweistelligen Beziehungs-Typs mit (min,max)-Notation Optionale Attribute im ER-Modell Teilstrukturen im ER-Modell und im SER-Modell Mächtigkeit und Orthogonalität des relationalen Datenbankmodells Relation PRODUKTGRUPPENDATEN Mächtigkeit und Orthogonalität des NF2-Datenbankmodells Tabellarische Darstellung der NF2-Relation PRODUKT-GRUPPENDATEN Baumstruktur der NF2-Relation PRODUKTGRUPPENDATEN Operatoren NEST und DENEST

6 9 21 21 22 23 24 26 26 30 36 38 39 39 41 42 44 45 46 47 60 62 63 64 65 69 71 71 75 .78 78 79 80 80 81

XVI

Abbildungsverzeichnis

Bild 2-34: Nestung und Entnestung in tabellarischer Darstellung 82 2 Bild 2-35: Mächtigkeit und Orthogonalität des eNF -Datenbankmodells 83 Bild 2-36: Tabellarische Darstellung der eNF2-Relation PRODUKTGRUPPEN 84 Bild 2-37: Mächtigkeit und Orthogonalität des deduktiven Datenbankmodells...85 Bild 2-38: Verknüpfungen im deduktiven Datenbankmodell 86 Bild 2-39: Objektorientiertes versus traditionelles Paradigma 88 Bild 2-40: Grobkonzept des Auftragswesens 98 Bild 2-41: Auftragswesen: Datenobjekte und ihre Eigenschaften 99 Bild 2-42: ER-Diagramm: Auftragswesen (Grobentwurf) 100 Bild 2-43: Entwicklung des konzeptionellen Datenbankschemas und Umsetzung in das relationale Datenbankmodell 101 Bild 2-44: Auftragswesen: Formalisierte, unnormalisierte Relationen 103 Bild 2-45: Normalformen 105 Bild 2-46: Auftragswesen: Unnormalisierte Relation Verkaufsauftrag 106 Bild 2-47: Auftragswesen: Relationen in der 1. Normalform 107 Bild 2-48: Funktionale Abhängigkeit 109 Bild 2-49: Voll funktionale Abhängigkeit 110 Bild 2-50: Auftragswesen: Relationen in der 2. Normalform 111 Bild 2-51: Auftragswesen: Relationen in der 3. Normalform 113 Bild 2-52: Normalisierung: Transitive Abhängigkeit; der Attribut-Menge C von der Attribut-Menge A 114 Bild 2-53: ER-Diagramm des Auftragswesens mit Datenobjekten in 3. NF 116 Bild 2-54: Möglichkeiten der Adressierung 120 Bild 2-55: Serielle Speicherung - Beispiel: Mitarbeiterdatei 121 Bild 2-56: Sequenzielle Speicherung - Beispiel: Mitarbeiterdatei 122 Bild 2-57: Gestreute Speicherung - Beispiel: Mitarbeiterdatei 123 Bild 2-5 8: Klassen von Suchverfahren 126 Bild 2-59: Lineares Suchen 128 Bild 2-60: M-Wege Suchen 129 Bild 2-61: Binäres Suchen 130 Bild 2-62: Hash-Funktionen 132 Bild 2-63: Divisions-Rest-Verfahren 133 Bild 2-64: Faltung 134 Bild 2-65: Abschneiden - Beispiel 1 134 Bild 2-66: Abschneiden - Beispiel 2 135 Bild 2-67: Matrix der relativen Häufigkeiten pjj 135 Bild 2-68: Verkettungen - Ausschnitt der Funktion AUFTRAGSANNAHME. 137 Bild 2-69: Lineare Liste 139 Bild 2-70: Einfache Ringkettung 140 Bild 2-71: Next-Prior-Kettung als Ringkettung 141 Bild 2-72: Next-und OWNER-Kettung 141 Bild 2-73a: Hierarchiestufen 142 Bild 2-73b: Realisation 142 Bild 2-74: Binärer Wurzelbaum als Suchbaum 144

Abbildungsverzeichnis Bild 2-75: Bild 2-76: Bild 2-77: Bild 2-78: Bild 2-79: Bild 2-80: Bild 2-81: Bild 2-82: Bild 2-83: Bild 2-84: Bild 2-85: Bild 2-86: Bild 2-87: Bild 2-88a: Bild 2-88b: Bild 2-89: Bild 2-90: Bild 2-91a: Bild 2-91b: Bild 2-9lc: Bild 2-9 ld: Bild 2-92: Bild 2-93: Bild 2-94: Bild 2-95: Bild 2-96: Bild 2-97: Bild 2-98: Bild 2-99: Bild 2-100: Bild 2-101: Bild 2-102: Bild 2-103: Bild 2-104: Bild 2-105: Bild 2-106: Bild 2-107: Bild 2-108: Bild 2-109: Bild 2-110:

B-Baum B*-Baum Einstufiger Index Haupt- und Nebenindex Mehrstufiger Index Mehrfacher Index Mehrdimensionaler Index Deskriptoren in ADABAS C Dateiorganisationsformen - Überblick ISAM-Dateiorganisation: Aufbau der Indextabelle ISAM-Dateiorganisation nach Urladen der Datei Beispiel Produktdatei ISAM-Dateiorganisation, Situation nach Einfügen Beispiel Produktdatei Prinzip der VSAM-KSDS-Dateiorganisation Beispiel Produktdatei Inverted File Organisation Inverted File Organisation Löschen im AVL-Baum Aufbau einer B-Baum-Seite B-Baum nach Einfügen der Elemente 21,42, 11, 30 B-Baum nach Einfügen des Elements 16 B-Baum nach Einfügen der Elemente 36, 8, 25,4 B-Baum nach Einfügen des Elements 43 Feldverkürzung Aussparen nicht belegter Felder Schubladentechnik Dateizugriffe zweier betrieblicher Funktionen Dateizugriffe auf Basis des File-Konzepts Zentralisierung der Dateien Komponenten eines Datenbankmanagementsystems Vereinfachte Systemarchitektur eines DBMS Drei-Ebenen-Schema-Architektur Fünf-Schichten-Architektur (funktionsorientierte Sicht) Client/Server-Architektur mit zentralem Datenbankserver Funktionsverteilungen in Client/Server-Architekturen Grobklassifikation von Mehrrechner-Datenbanksystemen Integrierte versus föderative Mehrrechner-Datenbanksysteme Schema-Architektur von verteilten DBS Föderative verteilte Datenbank Verteilungsarten Merkmale operativer und managementunterstützender Systeme Struktur der Hardwarenutzung von operationalen und managementunterstützenden DV-Systemen

XVII 146 147 148 149 150 151 152 154 156 158 159 160 162 163 164 165 166 166 167 167 167 170 170 171 174 174 175 183 183 184 186 209 210 211 213 214 215 216 219 221

XVIII

Abbildungsverzeichnis

Bild 2-111: Architektur-Schichten der DW-basierten betrieblichen Informationsversorgung Bild 2-112: Datengewinnung im Data Warehouse-Konzept Bild 2-113: Einbindung unternehmensexterner Daten in das Data Warehouse Konzept Bild 3-1: Einfache Fileverarbeitung Bild 3-2: DB-Verarbeitung Bild 3-3: EVA-Prinzip Bild 3-4: Funktionenmodell Bild 3-5: Ebenen des Business Engineering nach H. ÖSTERLE Bild 3-6: ARIS-Architektur Bild 3-7: Darstellungselemente für EPK nach A.W. SCHEER, Teil 1 Bild 3 - 8 : Darstellungselemente für E P K nach A . W . SCHEER, Teil 2 Bild 3-9: Beispiel einer Angebotskalkulation in EPK-Darstellung Bild 3 -10: Beispiel einer Angebotskalkulation in EPK-Darstellung mit Datenfluss Bild 3 -11: Organisations-Daten-Matrix Bild 3-12: Fälle der Vererbung Bild 3-13: Beispiel Spezialisierung - Generalisierung Bild 3-14: Beispiel einer Aggregation Bild 3-15: Beispiel eines Klassendiagrammes in UML-Notation Bild 3-16: Beispiel eines Objektdiagrammes in UML-Notation Bild 3-17: Beispiel eines Zustandsdiagrammes Bild 3-18: Beispiel eines Sequenzdiagrammes Bild 4-1: Verbindlichkeitsgrad bei der Standardisierung Bild 4-2: Beziehung zwischen Benutzermaschine und Basismaschine Bild 4-3: Genereller Modulaufbau zur Bearbeitung einer abstrakten Datenstruktur Bild 4-4: Hierarchische Strukturen Bild 4-5: Modulstruktur und das Geheimnisprinzip Bild 4-6: Externe Qualitätssicherung Bild 4-7: Maßnahmen zur Qualitätssicherung Bild 4-8: Top-Down-Methode Bild 4-9: Symbole in Datenflussdiagrammen Bild 4-10: Datenflussdiagramm Bild 4-11: Verfeinertes Datenflussdiagramm Bild 4-12: Faktoren der Modulkopplung und Grad der Kopplung Bild 4-13: Gesamtkomplexität Bild 4-14: Spektrum der Kopplungsarten Bild 4-15: Spektrum der Bindungsarten Bild 4-16: Problemstruktur Bild 4-17: Hauptdatenströme (Datenflussgraph) Bild 4-18: Dekomposition des Problems in Module (Strukturgraph) Bild 4-19: Strukturübersicht Bild 4-20: Überblicksdiagramm

225 231 233 262 263 265 268 271 274 276 277

278 279 284 289 290 290 295 296 298 299 305 309 312 319 330 333 333 343 349 349 351 354 355 355 356 359 360 360 362 363

Abbildungsverzeichnis

XIX

Bild 4-21: Bild 4-22:

365

Detaildiagramm Strukturelement Reihung (Sequenz), Auswahl (Selektion), Wiederholung (Iteration) als Jackson-Baumdiagramm, als Datenstruktur und als Kontrollstruktur Bild 4-23: Ein- und Ausgabedatenstruktur Bild 4-24: Daten- und Programmstruktur Bild 4-25: Elementaranweisungen Bild 4-26: Programmstruktur mit Elementaranweisungen Bild 4-27: Struktogramm des entwickelten Programms Bild 4-28: S ADT-Aktivitätenmodell Bild 4-29: SADT-Modellhierarchie Bild 4-30: SADT-Diagrammbaum Bild 4-31: SADT-Formular Bild 4-32: SADT-Diagramm (Apotheke und Umsystem) Bild 4-3 3: SADT-Diagramm (Verfeinerung zweiter Kasten) Bild 4-34: Objektstrukturdiagramm »KUNDE« Bild 4-35: Systemspezifikationsdiagramm »KUNDE« Bild 4-36: Pseudocode des Prozesses »KUNDE-1« Bild 4-37: Systemstrukturdiagramm mit Funktionen Bild 4-38: Systematisierung und Vergleich der Softwarequalitätsmerkmale Bild 4-39: Hierarchisches Qualitätsmodell zur Softwarequalität Bild 4-40: Regelkreis zu Softwaremetriken Bild 4-41: Begriffe des Qualitätsmanagements nach ISO 8402 Bild 4-42: ITIL Rahmenstruktur Bild 4-43: Zuordnung ITIL Rahmenstruktur zum Ganzheitlichen Informationsmanagement Bild 4-44: Prozessschritte beim Incident Management Bild 4-45: Prozessschritte beim Problem Management Bild 4-46: Aufgabenzyklus Service Level Management Bild 4-47: Capacity Planung über mehrere Schichten hinweg Bild 4-48: IT Security Management Prozessmodell Bild 4-49: Matrix zur Risikobewertung Bild 4-50: Wechselbeziehungen bei der Steuerung von Geschäftszielen Bild 4-51: Application Management Zyklus Bild 4-52: Aufgabenspektrum ICT Infrastructure Management Bild 4-53: Prozessmodell bei der Planung und Implementierung von Service Management Bild 4-54: Verknüpfungsmöglichkeiten bei Anwendungen Bild 5-1: Gegenüberstellung von Daten und Aufgaben Bild 5-2: W-Fragen zur Datenanalyse Bild 6-1: Organigramm der EuroTaxi GmbH Bild 6-2: Gegenüberstellung der Stärken und Schwächen sowie der Chancen und Risiken der EuroTaxi GmbH Bild 6-3: Übersicht der Aufgaben und des Informationsbedarfs der Abteilungen

369 370 371 371 372 373 376 377 378 379 381 3 82 385 386 3 86 387 396 397 402 413 419 420 423 425 427 428 433 434 436 437 439 440 446 459 461 488 490 493

XX Bild 6-4: Bild 6-5: Bild 6-6: Bild 6-7: Bild 6-8: Bild 6-9: Bild 6-10: Bild 6-11: Bild 6-12: Bild 6-13: Bild 6-14: Bild 6-15: Bild 6-16: Bild 6-17: Bild 6-18: Bild 6-19: Bild 6-20: Bild 6-21: Bild 6-22: Bild 6-23: Bild 6-24: Bild 6-25: Bild 6-26: Bild 6-27: Bild 6-28: Bild 6-29: Bild 6-30: Bild 6-31: Bild 6-32: Bild 6-33: Bild 6-34: Bild 6-3 5: Bild 6-3 6: Bild 6-3 7: Bild 6-3 8: Bild 6-39:

Abbildungsverzeichnis Anforderungskatalog ETIS 494 ER-Diagramm für den Bereich Buchungsabwicklung und Fakturierung (Darstellung ohne Attribute) 496 Notation des SERM 498 SER-Diagramm für den Bereich Buchungsabwicklung und Fakturierung 499 Strukturübersicht für den Unternehmensbereich Vertrieb & Marketing 501 DV-technische Strukturübersicht der Funktion »Buchung durchführen« 502 Überblicksdiagramm der Teilfunktion »Buchung durchführen« 503 Prozesskette »Flugabwicklung« in EPK-Darstellung 504 Prozesskette »Flugabwicklung« in EPK-Darstellung mit Datenfluss 505 Teil-Prozesskette »Flugbuchung« in EPK-Darstellung 506 Zuordnung von Daten und Organisationseinheiten zu Funktionen ...509 Obj ektmodell für den Bereich Flugbuchung und Fakturierung 511 Szenarios der Dynamikmodellierung 513 Ereignisdiagramme für das Anlegen, Ändern und Stornieren einer Buchung 514 Zustandsdiagramm für die Klasse »regulärer Flug« 515 Funktionenmodell für den Bereich »Fakturierung« 517 Natürlichsprachliche Beschreibung der Funktionen 518 Ausschnitt des ERM zur Buchungsabwicklung und Fakturierung.... 519 Unnormalisierte Relation 522 Detaildiagramm der Teilfunktion »Buchung durchführen« 525 Struktogramm zur Teilfunktion »Buchung durchführen« 525 Benutzerberechtigungstabelle für den Zugriff auf Daten und Funktionen für den Prozess »Flugabwicklung« 528 Trigger zur Freigabe eines Fluges zur Abrechnung 529 Klassen mit Attributen und Operationen 532 Struktogramm für die Funktion »Berechne RechPos« 533 Kontrollfluss für die Klasse »regulärer Flug« 535 Entwurf des Kommunikationsnetzdesigns der EuroTaxi GmbH 538 Hard- und Software-Bedarf (ohne Entwicklungssoftware) 539 Abhängigkeitsbeziehungen der Relationen des Teilsystems »Buchung und Fakturierung« 541 Beispieldaten Relation »Buchung« 544 Beispieldaten Relation »Flug« 544 Beispieldaten Relation »Flug Flugstrecke« 544 Beispieldaten Relation »Kunde« 544 Beispieldaten Relation »Rechnung« 545 Ausgabetabelle SQL-Statement »Kunden mit Rechnung« 545 Ausgabetabelle SQL-Statement »Kunden mit Buchung Flug ET32« 546

Abbildungsverzeichnis Visual-Basic-Quellcode des Programmoduls »Buchung durchführen« Bild 6-41: Eingabemaske des Programmoduls »Buchung durchführen« Bild 6-42: Smalltalk-Quellcode zur Definition der Klassen »Flug« und »Regulärflug« (auszugsweise) Bild 6-43: Aufbau der Teilsysteme »Buchungsabwicklung und Fakturierung«, »Personalverwaltung« sowie »Flugzeugverwaltung und Flugplanung« (Skizze) Bild 6-44: Organigramm der EuroTaxi GmbH nach der Umstrukturierung (nur Zentrale, ohne Schalter an den Flughäfen)

XXI

Bild 6-40:

548 549 551

554 558

Abkürzungsverzeichnis 4GL 4GT a.a.O. ACID ACM ADBMS ADT AI Anm. ANSI ARIS ASCII Aufl. AVL B-Baum Bd. BDD BDSG bearb. BERM BFuP BSI BSP BWL bzgl. CACM CAD CAE CAM CAQ CARE CASE Cax CCITT CIM CIS

Fourth Generation Language Fourth Generation Technique am angegebenen Ort Atomicity Consistency Isolation Durability Association for Computing Machinery Aktives DBMS abstrakter Datentyp Angewandte Informatik Anmerkung American National Standards Institut Architektur integrierter Informationssysteme American Standard Code of Information Interchange Auflage Adelson Velskii Landis Bayer-Baum Band Business Data Directory Bundesdatenschutzgesetz bearbeitete Binary ERM Betriebswirtschaftliche Forschung und Praxis Bundesamt für Sicherheit in der Informationstechnik Business Systems Planning Betriebswirtschaftslehre bezüglich Communications of the ACM Computer Aided Design Computer Aided Engineering Computer Aided Manufacturing Computer Aided Quality Assurance Computer Aided Reverse Engineering Computer Aided Software Engineering Computer Aided Technik Comite Consultatif International Telegraphique et Telephonique Computer Integrated Manufacturing Chefinformationssystem

XXIV COBOL CODASYL Comp. Conf. CPU d.h. DA DAM DB DBA DBMS DBS DBTG DC-System DD DDBMS DDL DDS Dev. DFÜ DGOR DIN DM DML DOS DQS DS DSS DTP durchges. DV DVA DW E/A EAI ΕΑΝ EBCDIC EBIS

Abkürzungsverzeichnis Common Business Oriented Language Conference on Data Systems Languages Computer Conference Central Processing Unit das heißt Data Administration Direct Access Mode Datenbank Datenbankadministration, Datenbankadministrator Datenbankmanagementsystem Datenbanksystem Data Base Task Group Data Communication System Data Dictionary Distributed DBMS Data Definition Language Data Dictionary System Development Datenfernübertragung Deutsche Gesellschaft für Operations Research Deutsche Industrie-Norm Data Management data manipulation Language Disk Operating System Deutsche Gesellschaft für Zertifizierung von Qualitätsmanagementsystemen mbH Dateischnittstelle Decision Support System Desktop Publishing durchgesehene Datenverarbeitung Datenverarbeitungsanlage Data Warehouse Ein-/Ausgabe Enterprise Application Integration Europäische Artikelnummer Extended Binary-Coded Decimal Interchange Code European Business Information System

Abkürzungsverzeichnis ECA ECMA ed. EDI EDV EERM EISA ELAN EPK ERM ER-Typ erw. ESDS ESS et al. ETIS ETM E-Typ EVA f. ff. FiBu FLAM FORTRAN GAN GDSS GE GERM GERT ggf· GGS GIS GKS GMD GS GVS Haupthrsg. HIPO HMD

Event Condition Action European Computer Manufacturer Association edition Electronic Data Interchange Elektronische Datenverarbeitung Erweiterung des ERM Extended Industrial Standard Architecture Extended LAN ereignisorientierte Prozesskette Entity-Relationship-Model Entity-Relationship-Typ erweiterte Entry Sequenced Data Sets Executive Support System et alii EuroTaxi Informationssystem Event/Trigger-Mechanismus Entity-Typ Eingabe-Verarbeitung-Ausgabe folgende fortfolgende Finanzbuchhaltung Frankenstein-Lidzba-Verfahren Formula Translator Global Area Network Group Decision Support System Geldeinheiten General ERM General Evaluation and Review Technique gegebenenfalls Gütegemeinschaft Software e.V. Geografische Informationssysteme globales konzeptionelles Schema Gesellschaft für Mathematik und Datenverarbeitung Geräteschnittstelle globales Verteilungsschema Hauptherausgeber Hierarchy plus Input-Process-Output Handbuch der Modernen Datenverarbeitung

XXV

XXVI HP Hrsg. i.d.R. IBM ICT IEC IEEE IKS IM IMS IT incl. Int. IRM IRS IS ISAM ISDN ISO ISS ITIL IuK IV Journ. JSD JSP Kap. KonTraG KSDS LAN LKS max. MB MDBS MIS MOS MS MSS MUS

Abkürzungsverzeichnis Hewlett Packard Herausgeber in der Regel International Business Machines Information and Communications Technology International Electrotechnical Commission Institute of Electrical and Electronics Engineers Informations- und Kommunikationssystem Informationsmanagement Information Management System Information Technology inclusive International Information Resource Management Information Retrieval System Informationssystem Index Sequential Access Mode Integrated Services Digital Network Intenational Standardization Organization interne Satzschnittstelle Information Technology Infrastructure Library Informations- und Kommunikations- (in Zusammensetzungen) Informationsverarbeitung Journal Jackson Systems Development Jackson Structured Programming Kapitel Gesetz zur Kontrolle und Transparenz im Unternehmensbereich Key Sequenced Data Sets Local Area Network lokales konzeptionelle Schema maximal Megabyte multidimensionale DBS Management Information System mengenorientierte Systeme Microsoft Management Support System Management Unterstützungssystem

Abkürzungsverzeichnis neubearb. NF NI Nr. o.ä. o.g. O.J. o.Y. ODMG ODS OGC OLAP OLTP OMG OMT OODBMS OODBS OOPS OR OR OSA OSI PC PL1 PPS PRINCE Proc. PROLOG QL RDBMS Res. RfC ROI ROLAP R-Typ S. SA SAD SADT

neu bearbeitete Normalform Normenausschuss Informationssysteme Nummer oder ähnliches oben genannte ohne Jahr ohne Verfasser Object Data Management Group Operational Data Store Office of Government Commerce On-Line Analytical Processing On-Line TP Object Management Group Object Modelling Technique Objektorientiertes DBMS Objektorientiertes DBS Objektorientierte Programmiersprache Operations Research Operations Research Open Systems Architecture Open Systems Interconnection Personal Computer Programming Language 1 Produktionsplanungs- und Steuerungssystem Projects In Controlled Environments Proceedings Programming in Logic Query Language Relationales DBMS Research Request for Changes Return on Investment Relationales OLAP Relationship-Typ Seite Structured Analysis Structured Analysis and Design Structured Analysis and Design Technique

XXVII

XXVIII SAM SD SERM SFIS SLA SNA sog. SOM SOS SPARC SPS SQL SVD TCO TCP/IP TP TQM TÜV u.ä. u.a. u.U. Überarb. UDM UML USV UWA verb. Verf. vgl. VLDB Vol. vollst. VPN VSAM WAN WBS z.B. z.T. ZfB

Abkürzungsverzeichnis Sequential Access Mode Structured Design Strukturiertes ERM Strategisches Führungsinformationssystem Service Level Agreement System Network Architecture sogenannten Semantisches Objektmodell satzorientierte Schnittstelle Standard Planning and requirements Committee Systempufferschnittstelle Structured Query Language Schweizerische Vereinigung für Datenverarbeitung Total Cost of Ownership Transmission Control Protocol/Internet Protocol Transaction Processing Total Quality Management Technischer Überwachungsverein und ähnliches und andere, unter anderem unter Umständen überarbeitete Unternehmensdatenmodell Unified Modelling Language Unterbrechungsfreie Stromversorgung User Working Area verbesserte Verfasser vergleiche Very Large Data Base Volume Vollständig Virtual Private Network Virtual Storage Access Mode Wide Area Network Wissensbasiertes System zum Beispiel zum Teil Zeitschrift für Betriebswirtschaft

Abkürzungsverzeichnis ZfbF ZfP ZOR

Zeitschrift für betriebswirtschaftliche Forschling Zeitschrift für Planung Zeitschrift für Operations Research

XXIX

1 Einführung in die Entwicklung ganzheitlicher Informationssysteme Obwohl in den vergangenen Jahren die Beschäftigung mit Fragestellungen zur Entwicklung und Nutzung von (ganzheitlichen) Informationssystemen zugenommen hat, ist man derzeit in den Unternehmen von der Verwendung einheitlicher Entwicklungsstrategien oder Entwicklungs- und Nutzungsstandards weit entfernt. Generell ist die Entwicklung von Software ein sehr kreativer Prozess, bei dem Wünsche von Menschen (Auftraggebern) in der ihnen typischen Unschärfe und mit den üblichen Fehlern formuliert werden. Aus der weitgehend unvollständigen verbalen Formulierung seitens der Menschen soll nun aber etwas in formal eindeutiger Weise formuliert werden, das eine DVA in einer Form steuert, so dass alle späteren, ggf. ebenfalls unscharfen Wünsche der Auftraggeber erfüllt werden. Wenn diese kreative Entwicklungsleistung nicht nur für eine, sondern für alle simultan zusammenwirkenden betrieblichen Aufgaben auf der Basis der verfügbaren Daten erfolgt, so bezeichnen wir dies als Entwicklungsmanagement ganzheitlicher betrieblicher Informationssysteme. Es geht hier also nicht um das Entwicklungsmanagement integrierter Informationssysteme, mit dessen Hilfe aus verschiedenen Teilinformationssystemen im Rahmen eines synthetischen Systemansatzes7 ein mehr oder weniger gut zusammengesetztes System entsteht. Vielmehr wird beim Entwicklungsmanagement ganzheitlicher Informationssysteme darauf Wert gelegt, dass der konstruktive Systemansatz verfolgt wird, der durch den wechselseitigen Einsatz eines analytischen und eines synthetischen Vorgehens gekennzeichnet ist, wobei unbedingt mit dem analytischen Teil begonnen werden muss. Nur durch den Einsatz dieses wechselseitigen Top-Down- (Analyse) / Bottom-UpVorgehens (Synthese) ergeben sich die Teilsysteme aus dem Ganzen.2

Vgl. BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I: Grundlagen, 6., vollständig überarbeitete und neu gefasste Auflage, München 2004, S. 138. Vgl. auch BIETHAHN, J.: Ganzheitliches oder integriertes Informationsmanagement? in: BIETHAHN, J. (Hrsg.): Arbeitsberichte der Wirtschaftsinformatik, Georg-August-Universität Göttingen 1992, auch erschienen in: IBM DEUTSCHLAND G M B H (Hrsg.): Offene Grenzen offene Systeme, IBM-Hochschulkongress '92 Dresden, Referat WR7.

2

1 Einführung in die Entwicklung ganzheitlicher Informationssysteme

Diese Vorgehensweise wird in dieser Form nicht von allen Fachvertretern unterstützt. Doch findet man zunehmend Beiträge, in denen eine mehr oder weniger ganzheitliche Lösung angestrebt wird, dabei aber aus Gründen der Praktikabilität oft von integrierten Systemen ausgegangen wird.3 1.1 Bedeutung des Entwicklungsmanagements für das ganzheitliche Informationsmanagement Unter einem ganzheitlichen Informationsmanagement wird ein Informationsmanagement verstanden, das sich an den Zielen des Unternehmens orientiert und bei der Generierung von Informationen und der Gestaltung der Informationsflüsse die diffundierenden, ganzheitlich orientierten Wirkungsmechanismen des Produktionsfaktors Information berücksichtigt. Ein ganzheitliches Informationsmanagement muss alle Informationsflüsse organisieren. Es muss von der Sammlung und Erfassung bis hin zur Bereitstellung der jeweils gewünschten Informationen sowie alle damit verbundenen Beund Verarbeitungsprozesse in Zusammenhang planen, steuern, koordinieren, realisieren und kontrollieren/ Hierzu gehört also nicht nur die Bereitstellung aller Informationen in der gewünschten Genauigkeit (z.B. in Form von Daten), sondern auch die Organisation und Steuerung aller Datenflüsse, die Abbildung aller Funktionen, mit denen die gewünschten und gesammelten Daten be- und verarbeitet werden können. Dieses muss unter Berücksichtigung der Ressourcen mit Hilfe der betrieblichen Organisation erfolgen. Dabei ist es offensichtlich, dass beim ganzheitlichen Ansatz die Datensicht, die Funktionssicht und die Organisationssicht simultan mit der Steuerungssicht im Sinne von A.W. S C H E E R , in der die verschiedenen Sichten wieder zusammengeführt werden, verfolgt werden müssen. 5 Diese auch in der Architektur betrieblicher Informationssysteme (ARIS) beschriebene Vorgehensweise0 wird noch durch die systematische Anwendung des konstruktiven Systemansatzes verstärkt, so 3

4

s

6

Vgl. z.B. SCHEER, A.-W.: Wirtschaftsinformatik, Referenzmodelle für industrielle Geschäftsprozesse, 6., durchges. Aufl., Berlin u.a. 1995, S. 10, oder: ÖSTERLE, H.: Business Engineering: Von intuitiver Organisation zu rationalen Workflows, in: ÖSTERLE, H.; VOGLER, P.: Praxis des Workflow Managements, Grundlagen Vorgehen Beispiele, Braunschweig/Wiesbaden 1996, S. 1-16 (S. 1-18). Vgl. BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 28 In der Steuerungssicht werden die verschiedenen Sichten wieder zusammengeführt. Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 14 ff. Vgl. SCHEER, A.-W.: Architektur integrierter Informationssysteme: Grundlagen der Unternehmensmodellierung, 2., verb. Aufl., Berlin u.a. 1992, S. 18 und S. 55 ff.

1.1 Bedeutung des Entwicklungsmanagements

3

dass vom Gesamtsystem ausgehend über die verschiedenen Sichten (wie sie auch bei A.-W. SCHEER beschrieben sind und weshalb sie hier nicht mehr detailliert beschrieben werden müssen) ein ganzheitliches System entsteht.7 Wir beschränken uns bei unserer Vorgehensweise nicht auf genau vorher festgelegte Sichten. Vielmehr werden wir uns bemühen, die wesentlichen herauszufiltern und je nach Anwendungs- und/oder Modellierungszweck weitere Sichten zusätzlich zu berücksichtigen, wie z.B. - die Sicht der Objektorientierung Objektorientierung, Sicht der in der es darum geht, möglichst solche Einheiten (= Objekte) zu entwickeln, die sowohl bezüglich ihrer Struktur (= Daten), ihrer Eigenschaften (= Funktionen) als auch hinsichtlich ihrer Beziehungen untereinander (= Verbindung über Nachrichtenaustausch) zusammenpassen. Die Objekte sind dann besonders geschickt ausgewählt, wenn sie eventuell auch in anderen Sichten wiederverwendet werden können; - die Sicht der Prozessorientierung, in der zusammengehörende Funktionen (wie z.B. alle Tätigkeiten im Rahmen einer Personaleinstellung oder einer Auftragsabwicklung) als Prozesse zusammengefasst werden. Die Forderung nach einem ganzheitlichen Informationsmanagement setzt also die Berücksichtigung möglichst aller verschiedenen Sichten voraus, ohne die kaum ein - wirtschaftlich erstelltes, - übersichtliches, - ganzheitlich geplantes, - veränderbares, - erweiterbares und - wartbares Informationssystem entstehen kann.

7

Auch ARIS strebt an, »ein Informationssystem zur Unterstützung von Geschäftsprozessen ganzheitlich zu beschreiben.« Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 10.

4

1 Einführung in die Entwicklung ganzheitlicher Informationssysteme

Die Erfüllung all dieser Anforderungen setzt eine systematische Vorgehensweise bei der Entwicklung voraus, so dass als Ergebnis keine andere als eine ganzheitliche Lösung entstehen kann. Das führt dazu, dass wir nicht von einem einfachen Vorgehensmodell ausgehen, wie sie in großen Anzahlen in der Literatur aufgeführt werden, sondern von der von uns entwickelten Rahmenkonzeption, welche die Erstellung ganzheitlicher Systeme besonders unterstützt.5 Ein solches Vorgehen beginnt immer mit der Problemspezifikation unter Berücksichtigung des gesamten betrieblichen Umfeldes, um die Fehler, die man in der Vergangenheit gemacht hat, zu finden, sie sich bewusst zu machen und sie nicht erneut zu wiederholen. Die Problemspezifikation sollte sowohl bei Neukonzeptionen als auch bei Erweiterungen und Wartungen von Informationssystemen vorgenommen werden. Danach sind die verschiedenen Phasen der Rahmenkonzeption unter Beachtung aller verschiedenen Sichten zu durchlaufen, bis wieder ein neues ganzheitliches Informationssystem entstanden ist. Zwischen den einzelnen Ausprägungen eines Informationssystems, die im Laufe der Zeit entstehen, sind somit immer Phasen des Entwicklungsmanagements erforderlich, das insofern ein wesentlicher Bestandteil eines ganzheitlichen Informationsmanagements ist. 1.2 Ziele und Begriffe des Entwicklungsmanagements Das generelle Ziel des Entwicklungsmanagements9 ist es, festzulegen, wie ganzheitliche Informationssysteme entwickelt werden müssen, damit die Anforderungen eines ganzheitlichen Informationsmanagements erreicht werden. Heute gibt es eine sehr große Fülle unterschiedlichster Möglichkeiten, Software zu entwickeln. Aus wissenschaftlicher Sicht beschäftigt man sich mit diesen Fragestellungen im Rahmen des Software-Engineerings . Der Begriff »Software-Engineering« wurde erstmals auf den NATO-Tagungen in Garmisch (1968) und Rom (1969) verwendet. In Anlehnung an P. SCHMITZ soll Software-Engineering hier definiert werden als: »... Wissenschaft der Konzipierung und gezielten Anwendung von Prinzipien, Methoden, Verfahren und Werkzeugen zur Lösung technischer, ökonomi-

8

9

Vgl. BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 256 - 270. Vgl. RUF, W.: Ein Software-Entwicklungs-System auf der Basis des SchnittstellenManagement-Ansatzes: für Klein- und Mittelbetriebe, Berlin u.a. 1988, S. 7 ff.

1.2 Ziele und Begriffe des Entwicklungsmanagements

5

scher und organisatorischer Probleme bei der Entwicklung, Nutzung und Wartung von Software-Produkten ...«.10 Durch diese Definition wird ausgedrückt, dass man heute eher einem Denkansatz folgt, wie er auch in den Ingenieurwissenschaften üblich ist. Man betrachtet die Softwareentwicklung nicht mehr als eine Kunst, bei der es darum geht, durch »Genialität« und »Tricks« die letzten Feinheiten einer vorgegebenen Hardware auszunutzen. Ein zusammenfassendes Ziel des Software-Engineering ist es, - wirtschaftlich erstellte, - wirtschaftlich wartbare, - veränderbare, - ganzheitlich geplante Informationssysteme zu schaffen. Eine wesentliche Voraussetzung für die Entwicklung ganzheitlicher Informationssysteme, die den in Abschnitt 1.1 genannten Anforderungen entsprechen, ist ein systematisches Datenmanagement. Zudem bedarf es der Kenntnis im Umgang mit Prinzipien und erfahrungsbasierten Konzepten (aus denen wiederum Methoden, Verfahren und Tools resultieren), um eine weitgehend in sich geschlossene Vorgehensweise zur Erstellung von Informationssystemen anhand unserer Rahmenkonzeption zeigen zu können. Wie erwähnt, unterscheidet man beim Software-Engineering zwischen Prinzipien, Methoden, Verfahren und Tools. Weiterhin spielen in diesem Zusammenhang Strategien, Konzepte und Techniken der Softwareentwicklung, mit denen eine weitere Unterteilung vorgenommen wird, eine bedeutende Rolle. Eine zusammenfassende Darstellung der im Software-Engineering verwendeten Hilfsmittel und die Beziehungen zu den Ausgangsproblemen und Zielen zeigt Bild 1-1.

10

P.: Methoden, Verfahren und Werkzeuge zur Gestaltung rechnergestützter betrieblicher Informationssysteme (RBIS), in: AI: 2/1982, S. 73 (72-79). Diese Definition scheint sich zunehmend durchzusetzen. In die gleiche Richtung gehende Definitionen findet man zum Beispiel bei: STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, 7., vollst. Überarb. u. erw. Aufl., Berlin u.a., S. 221, SCHULZ, Α.: Software-Entwurf: Methoden und Werkzeuge in: ENDRES, A. (Hrsg.): Handbuch der Informatik, München/Wien 1988, S. 14, GEWALD, K.; HAAKE, G.; PFADLER, W.: Software Engineering, Grundlagen und Technik rationeller Programmentwicklung, 4. Auflage, München/Wien 1985, S. 26 (Hier wird auch ein Überblick über weitere Definitionen gegeben. S. 18 ff). SCHMITZ,

1 Einfuhrung in die Entwicklung ganzheitlicher Informationssysteme

6

Probleme technische Probleme

ökonomische Probleme

organisatorische Probleme

Ziele qualitative Ziele

Ziele des Anwendungsgebietes

wirtschaftliche Ziele

Prinzipien Strate^^

Methoden

Verfahren

einzelne Tools

Software-Entwicklungssysteme

Bild 1-1:

Hilfsmittel des Software-Engineerings

Die aufgeführten Begriffe werden im folgenden näher erläutert: Zu den Prinzipien der Softwareentwicklung zählen »... Grundsätze, die man seinem Handeln zugrundelegt. Sie sind allgemeingültig, abstrakt, allgemeinster Art. Prinzipien bilden eine theoretische Grundlage.«77 Prinzipien geben grundsätzliche Richtlinien an, mit denen man aus der Erfahrung her Ziele erreicht und stellen allgemeingültige Grundsätze im Sinne einer Norm dar. Sie beinhalten aber keine Vorschriften oder Regeln für die Zielerreichung. Auf das Software-Engineering bezogen, stellen sie die Grundlage für Methoden, Verfahren und Werkzeuge dar.72

11 12

BALZERT, H.: Allgemeine Prinzipien des Software Engineering, in: AI: 1/1985, S. 2 (1-8). Vgl. TRUÖL, K.; VffiBEG, U.: Strukturierter Programmentwurf - die datenorientierte Methode, GMD-Bericht Nr. 150, München/Wien 1985, S. 14.

1.2 Ziele und Begriffe des Entwicklungsmanagements

7

Beispiele für Prinzipien der Softwareentwicklung, die in Kapitel 4 noch eingehend behandelt werden, sind: -

das Prinzip der Abstraktion, das Prinzip der Modularisierung oder das Prinzip des »Information Hiding«.

Die meisten dieser Prinzipien wurden in den Jahren 1968-1974 erarbeitet.75 Aufgrund immer neuer oder geänderter Aufgabenstellungen und Erkenntnisse, kommen jedoch auch heute noch weitere hinzu. Methoden der Softwareentwicklung stellen »... planmäßig angewandte, begründete Vorgehensweisen zur Erreichung von festgelegten Zielen«74 dar. Sie beinhalten Vorschriften, die bei der Lösung bestimmter Aufgabenklassen anzuwenden sind, ohne dabei den Lösungsweg bis ins letzte Detail vorzuschreiben.75 Methoden bauen meist auf Prinzipien auf, oder sind so angelegt, dass nicht gegen bestimmte Prinzipien verstoßen wird. Mit ihnen wird versucht, festgelegte Ziele durch Vorgabe von Regeln und Arbeitsschritten (Vorgehensweisen) zu erreichen. Methoden haben einen universellen Charakter. Durch sie wird die Einhaltung der allgemein formulierten Prinzipien erleichtert. Beispiele für Methoden sind: Strukturierte Programmentwicklung, HIPO (Hierarchy of Input-Process-Output), SADT (Structured Analysis and Design Technique). Verfahren der Softwareentwicklung sind nach P. S T A H L K N E C H T Anweisungen zum gezielten Einsatz von (einzelnen oder mehreren) Methoden, i.d.R. also vollständig determinierte Methoden.76 Je nach übergeordnetem Gesichtspunkt kann ein Verfahren auch als Methode in das übergeordnete Verfahren integriert werden. Im Gegensatz zu den Methoden stehen hier konkrete, anwendbare Regeln im Vordergrund. Diese können den Inhalt von Standards und Normen bilden. Als Beispiele für Methoden sind JSP (Jackson Structured Programming) oder auch die DIN (Deutsche Industrie-Norm) der Datenverarbeitung nach Satzgruppen (DIN 66220) zu nennen. 75

15

16

Vgl. SCHULZ; Α.: Ein Klassifizierungs- und Bewertungsschema für Software-EngineeringWerkeuge, insbesondere CASE-Systeme, in: AI: 5/1986, S. 192 (191-197). BALZERT, H . : Die Entwicklung von Software-Systemen: Prinzipien, Methoden, Sprachen, Werkzeuge, Mannheim/Wien/Zürich 1982 (Nachdruck 1986), S. 22. Vgl. HEILMANN, H . : Softwareentwurfsmethodik - Definition und Klassifizierung, in: HMD: 110/1983, S. 5(3-15). Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 222.

8

1 Einführung in die Entwicklung ganzheitlicher Informationssysteme

Vor allem Methoden und Verfahren können nicht immer eindeutig voneinander unterschieden werden, was zur Folge hat, dass die Begriffe oft synonym verwendet werden. Zu den (Software-) Tools, im engeren Sinne auch als (Programmerstellungs-) Werkzeuge bezeichnet, gehören »... Programme, die die Herstellung, Prüfung, Wartung und Dokumentation von Programmen vereinfachen, beschleunigen oder in ihrer Qualität verbessern.«77 Tools können bestimmte Methoden unterstützen, jedoch ist dies nicht zwingend erforderlich. Bereits eine Untersuchung von P. STAHLKNECHT und A . WARNER aus dem Jahr 1986 zeigt, dass 51 von 79 untersuchten Entwicklungs-Tools keine spezielle Methode unterstützten.75 Neben den Entwicklungs-Tools wie Programm- und Struktogramm-Generatoren, sind an dieser Stelle beispielsweise auch Data Dictionaries oder Repositories zu nennen. Zwischen Prinzipien und Methoden werden die Konzepte der Softwareentwicklung eingeordnet. Konzepte bauen auf Prinzipien auf und können ihrerseits die Grundlage für Methoden und Tools bilden. Durch ein Konzept wird ein grundlegender Lösungsansatz festgelegt, der allerdings unterschiedliche Lösungswege zulässt.79 Unter Strategie versteht man die Festlegung von grundsätzlichen, gangbaren Wegen (z.B. Top-Down-Strategie, Bottom-Up-Strategie).20 Eine enge Verbindung zu den Methoden haben auch die (Entwicklungs-) Techniken, bei denen Detailaspekte im Vordergrund stehen. Somit ist es prinzipiell möglich, dass mehrere Techniken in einer Methode verwendet werden.27 Als Beispiele für Techniken können genannt werden: - Organisationstechniken (z.B. Checklistentechnik) - Planungstechniken (z.B. Netzplantechnik) - Darstellungstechniken - Strukturierungstechniken (z.B. Entscheidungstabellentechnik) 1 7

18

19

20 21

STAHLKNECHT, P.; WARNER, Α.: Stand der Entwicklung des Einsatzes von SoftwareEntwicklungswerkzeugen, in: Information management: 2/1986, S. 38 (36-53). STAHLKNECHT, P.; WARNER, Α.: Stand der Entwicklung, a.a.O., S. 45. Vgl. SCHUMANN, J.; GERISCH, M.: Software-Entwurf, Prinzipien - Methoden - Arbeitsschritte -Rechnerunterstützung, Berlin 1984, S. 59. Vgl. HÖCKER, H.-J.: Die Bewertung von Software-Entwurfsmethoden, Bremen 1984, S. 28. Vgl. PENZEL, H.-G.: Ein systematischer Vergleich von Entwurfsverfahren für betriebliche Informationssysteme, Dissertation, Mainz 1983, a.a.O., S. 186.

1.3 Aufgaben des Entwicklungsmanagements

9

Ein Softwareentwicklungssystem stellt allgemein eine Anzahl von aufeinander abgestimmten Tools dar, die mehrere Aufgaben aus mehreren Phasen des Softwareentwicklungsprozesses unterstützen.22 Bild 1-2 stellt die Entwicklungsschritte der methodischen Hilfsmittel des Software-Engineerings von 1968 bis heute dar.

Bild 1-2:

Entwicklungsschritte der methodischen Hilfsmittel des SoftwareEngineerings.

Nach diesen Begriffserklärungen wird nun auf die Aufgaben des Entwicklungsmanagements eingegangen. 1.3 Aufgaben des Entwicklungsmanagements Bisher mangelt es an einem allgemeingültigen und problemneutralen Vorgehen bei der Entwicklung von Informationssystemen. »Eine Ingenieurdisziplin, die allgemein anerkannte Prinzipien und Methoden zur Erstellung von Software

22

Vgl. RUF, W.: Ein Software-Entwicklungs-System, a.a.O., S. 10 f.

10

1 Einführung in die Entwicklung ganzheitlicher Informationssysteme

anwendet, ist erst im Entstehen.«23 Obwohl diese Aussage 10 Jahre alt ist, hat diese Disziplin bis heute noch kein endgültiges Konzept gefunden. Eine wesentliche Aufgabe des Entwicklungsmanagements besteht deshalb darin, eine problem- und unternehmensspezifische Auswahl der anzuwendenden Prinzipien, Methoden, Verfahren und Tools zu treffen. Diese Auswahl orientiert sich an den vom Informationsmanagement vorgegebenen entwicklungsbezogenen Zielen, die sich unter anderem auf die geplanten Kosten, die Entwicklungszeit und die angestrebte Softwarequalität beziehen. Dabei sind durch das Entwicklungsmanagement folgende Rahmenbedingungen für die Softwareentwicklung zu bilden, die als Vorgaben des Informationsmanagements anzusehen sind: -

vorhandene DV-Anlage und Peripherie, vorgegebene Schnittstellen zu bestehenden Softwareprodukten, vorgegebene Programmiersprachen, bisher verfolgte Sichten der Softwareentwicklung, Qualität und Erfahrung des Entwicklungsteams, bereits geplante, jedoch erst später zu realisierende DV-Aufgaben, konzeptuelle Datenmodelle.

Aus diesen Rahmenbedingungen ergibt sich die folgende Aufstellung wesentlicher Aufgaben des Entwicklungsmanagements: - Auswahl von gedanklichen Hilfsmitteln (Prinzipien, Strategien, Methoden und Verfahren), die bei der Softwareentwicklung berücksichtigt werden sollen, - Auswahl und Einsatz von Entwicklungstools, - Auswahl von maschinellen Hilfsmitteln, - Übertragung von wissenschaftlichen Erkenntnissen in die praktische Anwendung, - Organisation und Durchführung von Schulungsmaßnahmen bezüglich der: -Projektabwicklung, -gedanklichen Hilfsmittel, -maschinellen Hilfsmittel und -des Anwendungsbereiches. - Festlegung der einzuhaltenden Entwicklungs-Standards, - Entscheidung »make or buy«25. (Die »make or buy«-Entscheidung muss sowohl für Teile der zu entwickelnden Software als auch für die einzusetzenden Tools getroffen werden.) 23 24

BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 3. Vgl. dazu Kapitel 2.4.

1.3 Aufgaben des Entwicklungsmanagements

11

Das Entwicklungsmanagement ist daher gefordert, neue wissenschaftliche Erkenntnisse bei der Entwicklung ganzheitlicher Informationssysteme zu berücksichtigen (Transferaufgaben). Selbstverständlich kann dies nur unter Beachtung der wirtschaftlichen Rahmenbedingungen erfolgen. Für die Softwareentwicklung konnten sich bisher, nicht zuletzt aufgrund der enormen Fortschritte im Hardwarebereich, keine langfristigen Entwicklungsmethoden etablieren. Die Anpassung der Softwareentwicklung an neu gewonnene Erkenntnisse aus dem Software-Engineering-Bereich und die Nutzung neuer Hardwaremöglichkeiten für betriebsindividuelle Aufgabenstellungen gehören daher zu den Aufgaben des Entwicklungsmanagements.26 Nach dieser Klärung von Zielen, Aufgaben und wesentlichen Begriffen zum Entwicklungsmanagement wird im nächsten Kapitel das Datenmanagement behandelt.

25

26

Vgl. BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 184-203. Vgl. BIETHAHN, J.: Forschungs- und Entwicklungsmanagement - Utopie oder Wirklichkeit, in: Zß: Seoul, 4/1986, S. 211 ff. (198-223).

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements Unternehmen sehen sich seit einigen Jahren durch die fortschreitende Globalisierung der Märkte, zunehmendem Wettbewerbsdruck, einer Verkürzung der Produktlebenszyklen und der Verschärfung gesetzlicher Bestimmungen neuen Herausforderungen gegenübergestellt. Um in dieser sehr dynamischen Umwelt zu überleben, ist es für die Unternehmen erforderlich, schneller auf die Bedürfnisse der Kunden zu reagieren, die Qualität ihrer Produkte und Dienstleistungen zu erhöhen und die Kosten in den Bereichen Produktion und Verwaltung zu senken. Damit die Entscheidungsträger aller Hierarchieebenen frühzeitig sowohl unternehmensinterne als auch externe Veränderungen erkennen und eventuell sogar prognostizieren können, müssen alle für diese Aufgaben relevanten Daten und Informationen zum richtigen Zeitpunkt zur Verfügung stehen. Auf Grundlage dieser Daten und Informationen sowie der Erfahrung der Entscheidungsträger werden operative, taktische und strategische Entscheidungen getroffen, deren Qualität für die weitere Entwicklung eines Unternehmens maßgeblich ist. Die schnelle Bereitstellung der notwendigen Information zum richtigen Zeitpunkt am richtigen Ort ist heute somit eine Schlüsselressource für das erfolgreiche Bestehen eines Unternehmens im Wettbewerb. Sie ist für die Lösung aller betrieblichen Aufgaben zum kritischen Erfolgsfaktor geworden.27 Die effiziente Datenbereitstellung ist die eigentliche Aufgabe der betrieblichen Informations- bzw. Datenverarbeitung. Sie beschäftigt sich bekanntlich mit der Erfassung, der Speicherung, dem Transport, der Transformation sowie der Ausgabe großer Informations- und Datenmengen.25 Die Vielzahl der im Unternehmen vorhandenen - vielfach aber nicht rechtzeitig für betriebliche Entscheidungen verfügbaren - Daten führt zu der Einsicht, dass das Datensystem eines Unternehmens ebenso zu managen ist, wie andere Ressourcen. Daher ist das Management des Datensystems die Grundlage und die Voraussetzung für das in diesem Buch behandelte Entwicklungsmanagement. 27

28

Vgl. MUCKSCH, H.; HOLTHUIS, J.; REISER, M.: Das Data Warehouse-Konzept - ein Überblick,

in: Wirtschaftsinformatik Vol. 38, 4/1996, S. 421 (421-434). Vgl. ZEMANEK, H.: Datenverarbeitung, in: SCHNEIDER, H.-J. (Hrsg.): Lexikon der Informatik und Datenverarbeitung, München/Wien 1983, S. 147 sowie MEYER, B.: Informationsverarbeitung, in: SCHNEIDER, H.-J. (Hrsg.): Lexikon der Informatik und Datenverarbeitung, München/Wien 1983, S. 271.

14

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Dieses Kapitel zum Datenmanagement verdeutlicht, wie und mit welchen Mitteln die Daten eines Unternehmens unabhängig von einzelnen Anwendungssystemen strukturiert und organisiert werden können und müssen. Darüber hinaus sei auch hervorgehoben, dass das Datenmanagement Voraussetzung für den Datenverarbeitungsbetrieb mit nicht selbst entwickelter oder angepasster Software, wie z.B. Standard-Software, ist. Datenmanagement ist somit neben seiner Bedeutung für das Entwicklungsmanagement eine erforderliche Basis für die Informationsverarbeitung insgesamt. Deshalb wird in Kapitel 2.1 allgemein auf die Bedeutung des Datenmanagements eingegangen. Kapitel 2.2 befasst sich sodann mit den Aufgaben und Funktionen des Datenmanagements. Anschließend werden in Kapitel 2.3 grundlegende Fragen der logischen Datenorganisation behandelt, bevor im Kapitel 2.4 das Vorgehen bei der Entwicklung eines zielsystemunabhängigen29 konzeptionellen Datenmodells erläutert wird. In Kapitel 2.5 beschäftigen wir uns mit den Grundlagen der physischen Datenorganisation, die als DV-technische Voraussetzung für das physische Datenbankdesign anzusehen ist. Im Anschluss daran werden in Kapitel 2.6 Systeme, Ansätze und Konzepte für klassische monolithische Datenverwaltungssysteme vorgestellt und diskutiert; in Kapitel 2.7 werden weitergehende Ansätze der Datenverwaltung behandelt. Das Thema Datenmanagement wird in Kapitel 2.8 mit einer Darstellung von Systemen zur Metadatenverwaltung und ihren Einsatzmöglichkeiten bei der Entwicklung von betrieblichen Informationssystemen abgerundet. 2.1 Begriff und Bedeutung des Datenmanagements Betriebliche Informationen sind aufgrund negativer Erfahrungen der Vergangenheit30 zum wirtschaftlichen Gut geworden, so dass sie als Produktionsfaktor zu behandeln sind.57 Nach LJ. HEINRICH und P. BURGHOLZER führt dies zu 29

30

^

Der Begriff »zielsystemunabhängig« bezieht sich hier lediglich auf das zugrunde liegende Datenbankschema. Die Entwicklung des konzeptionellen Schemas sollte in dieser Phase keinesfalls in Bezug auf ein konkretes Datenbanksystem erfolgen. Undurchsichtige Daten- und Programmkomplexe sowie historisch angewachsene »Datenfriedhöfe«, die weder für operative noch für strategische DV-Anwendungen nutzbar sind, zählen zu den bekanntesten Ausprägungen der DV vergangener Jahre. Vgl. AHRENS, L.; HOFFMANN, J.: Die Attribute sollten hierarchisch vererbt werden, in: Computer Woche: 15. Jg., Nr. 30 vom 22.7.1988, S. 28 (28/29). Diverse Standpunkte zu dieser Aussage sind zu finden in: BROCKHAUS, R.: Informationsmanagement als ganzheitliche, informationsorientierte Gestaltung von Unternehmen: organisatorische, personelle und technologische Aspekte, Göttingen 1992, S. 39; BULLINGER, HJ.: Anforderungen des Technologietrends an Forschung und Industrie, in:

2.1 Begriff und Bedeutung des Datenmanagements

15

einer neuen Sicht der Informationsfunktion. Sie wird nicht mehr nur als eine Unterstützungsfunktion für andere Aktivitäten, sondern im Sinne einer eigenständigen, gleichberechtigten Unternehmensfimktion angesehen.52 Die maschinelle Verarbeitung von Daten, auf deren Grundlage betriebliche Entscheidungen getroffen werden, ist von enormer Bedeutung33 und somit als lebensnotwendige Aufgabe in einem Unternehmen anzusehen.34 Die Geschwindigkeit, mit der die betriebliche Datenverarbeitung Informationen bereitstellt, wird zu einem kritischen Faktor für den Erfolg des Unternehmens, da von ihr die Aktions- und Reaktionsgeschwindigkeit auf den unternehmensrelevanten Märkten abhängig ist.3·5 Bereits das vor ca. 30 Jahren in den USA aufgekommene Information Resource Management (IRM) war eng mit dieser Erkenntnis verbunden.36 IRM wurde als »...umfassender strategisch orientierter Management-Ansatz...«37 verstanden, der die Interdependenzen zwischen der Unternehmensstrategie und der Informations- und Kommunikationstechnik hervorhebt. Der Aufgabenschwerpunkt der betrieblichen Informationsverarbeitung erweiterte sich zusätzlich zur Verarbeitung operativer Massendaten zunehmend in den Bereich

32

33

34

35

FHG-BERICHTE: Information als Produktionsfaktor 1/1986, S. 3; EISENHOFER, Α.: Information als Produktionsfaktor Strategie für Entscheidungsunterstützungssysteme, in: BULLINGER, HJ. (Hrsg.): Integrierte Bürosysteme, Heidelberg/New York/Tokyo 1984, S. 433; PICOT, Α.; FRANCK, E.: Die Planung der Unternehmensressource Information I: in: WISU-. 10/1988, S. 544 (544-549) und SCHULZE-WISCHLER, B.: Lean Information Computergestützte Systeme in der mittelständischen Industrie, Wiesbaden 1995, S. 32 ff. Vgl. HEINRICH, L.J.; BURGHOLZER, P.: Informationsmanagement, 3., korr. Auflage, München/Wien 1990, S. 141, HEINRICH, L.J.: Informationsmanagement, 5. Auflage, München/Wien 1 9 9 6 , S. 8, sowie MARTINY, L.; KLOTZ, M . : Strategisches Informationsmanagement, 2., verbesserte Auflage, München/Wien 1990, S. 13-19. M. VETTER spricht sogar vom »Jahrhundertproblem der Informatik«, welches »... in der Bewältigung des Datenchaos, das infolge unkontrolliert gewachsener Datenbestände fast überall entstanden ist«, besteht. VETTER, M.: Aufbau betrieblicher Informationssysteme mittels konzeptioneller Datenmodellierung, 5., durchgesehene Auflage, Stuttgart 1989 und VETTER, M . : Das Jahrhundertproblem der Informatik, in: MÜLLER-ETTRICH, G . (Hrsg.): Effektives Datendesign: Praxis-Erfahrungen, Köln 1989, S. 11-31. Vgl. IBM DEUTSCHLAND GMBH (Hrsg.): Daten-Management - für eine unternehmensweite Produktivität. IBM-Form GZ 12-1093-0, Stuttgart 1982, S. 5. Vgl. MARTINY, L.; KLOTZ, M.: Strategisches Informationsmanagement, a.a.O., S. 17 sowie SEIBT, D . : Information Resources Management, in: MERTENS, P . (Haupthrsg.): Lexikon der Wirtschaftsinformatik, 2., vollständig neu bearbeitete und erweiterte. Auflage, Berlin u.a. 1 9 9 0 , S. 2 1 2 f. ( 2 1 2 - 2 1 5 ) .

36

3 7

Vgl. MARTINY, L.; KLOTZ, M . : Strategisches Informationsmanagement, a.a.O., S. HEINRICH, L.J.: Informationsmanagement, a.a.O., S. 9. SEIBT, D . : Information Resources Management, a . a . O . , S. 180.

17,

sowie

16

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

der adäquaten Bereitstellung entscheidungsrelevanter Informationen für das Management. Im Laufe der vergangenen Jahrzehnte wurden diverse Ansätze und Systeme entwickelt, die sich in der verwirrenden Vielfalt unterschiedlicher Akronyme, wie: - CIS (CheflnformationsSystem), - DSS (Decision Support System) bzw. EUS (EntscheidungsUnterstützungsSystem), - EIS (Executive Information System) bzw. FIS (Führungsinformationssystem), - ESS (Executive Support System), - GDSS (Group Decision Support System), - MIS (Management Information System), - MSS (Management Support System) bzw. MUS (ManagementUnterstützungsSystem) und - SFIS (Strategisches Führungsinformationssystem) ausdrücken.35 Die begriffliche Einordnung der genannten Systeme ist aufgrund ihrer vielfaltigen Einsatzgebiete, die sich je nach Größe und Branche eines Unternehmens unterscheiden sowie die unscharfen Grenzen ihrer Funktionalität zu anderen Systemen in der Literatur jedoch keineswegs einheitlich.39 Die Steuerung der betrieblichen Datenverarbeitung unter rein technischen Aspekten muss sich folglich zu einem systematischen Datenmanagement entwickeln/ 0 In den Jahren 1977 bis etwa 1987 wurden die Daten- und die Datenbankadministration als neue Funktionen der Datenverarbeitung diskutiert/7 »... Data Vgl. zu diesem Thema u.a. BEHME, W . ; SCHIMMELPFENG, K . : Führungsinformationssysteme: Geschichtliche Entwicklung, Aufgaben und Leistungsmerkmale, in: BEHME, W.; SCHIMMELPFENG, K. (Hrsg.): Führungsinformationssysteme: Neue Entwicklungstendenzen im EDV-gestützten Berichtswesen, Wiesbaden 1993, S. 12 (3-16). Zum Begriff »SFIS« vgl. GRIMM, U.; SOKOLOWSKY, P. (Hrsg.): Strategische Führungsinformationssysteme, Theoretische Grundlagen, praktische Erfahrungen, Wiesbaden 1995. 39

Zur Charakterisierung und Abgrenzung vgl. GABRIEL, R.; CHAMONI, P.; GLUCHOWSKI, P.:

Einsatz von IuK-Systemen zur Unterstützung des Managements - Management Support Systeme I -, Arbeitsbericht des Lehrstuhls für Wirtschaftsinformatik, Nr. 95-14, RuhrUniversität Bochum, Februar 1995; GLUCHOWSKI, P.; GABRIEL, R.; CHAMONI, P.: Strukturbe-

stimmende Merkmale von Managementunterstützungssystemen - Management Support Systeme II Arbeitsbericht des Lehrstuhls für Wirtschaftsinformatik, Nr. 95-16, RuhrUniversität Bochum, April 1995. 40 41

Vgl. IBM DEUTSCHLAND G M B H (Hrsg.): Daten-Management, a.a.O., S. 5. Vgl. DEBLASIS, J.-P.; JOHNSON, T.H.: Database Administration - Classical Pattern, Some Experiences and Trends, in: Proc. Of The 1977 AFIPS-NCC: Dallas, Texas 1977, S. 1-7;

2.1 Begriff und Bedeutung des Datenmanagements

17

Administration (DA) is the establishment and enforcement of policies and procedures for managing the company's data as a corporate resource. It involves the collection, storage and dissemination of data as a globally administered and standardized resource«/ 2 Nach J. N I E D E R E I C H H O L Z und C. W E N T Z E L soll sich der Verantwortungsbereich der Datenadministration »... auf möglichst alle Daten eines Unternehmens, mindestens aber auf alle DV-gestützten Daten, beziehen...«/5 Die Praxis zeigte jedoch nur geringe Ambitionen etwas derartiges einzuführen44, was auf eine unklare Terminologie bzgl. der Ziele und Aufgaben der Datenadministration und/oder des Datenmanagements zurückzuführen war/ 5 Während bspw. A.W. HEINRICH die Begriffe »Datenadministration« und »Datenmanagement« synonym verwendete/ 6 definierte M.L. GlLLENSON letzteres wie folgt: »... Data Management (DM), is primarily a planning and analysis type function. It may be responsible for data planning, accountability, training, policy development standards setting, database design and liaison support to application development groups«/ 7 Gegenstand dieses Managementbereiches ist das Datensystem der Unternehmung, das eine Abbildung der Realität in Daten für die Menge der zu lösenden Aufgaben darstellt/* Nach L . J . H E I N R I C H und P. B U R G H O L Z E R bezeichnet Datenmanagement das »... Leitungshandeln des Informationsmanagements

R.: What Do Data Administrators Really Do?, in: Datamation: Vol.26, 8/1980, S. 131-134 sowie MÜNZENBERGER,H.: Database Administration Experience From a European Survey, in: Proc. of the European conf. on evaluation and implementation of database systems: September 1980, S. 25 f. KAHN, B . K . : Some Realities of Data Administration, in: CACM: Vol. 26, 10/1983, S. 794 (794-799); vgl. auch GILLENSON, M.L.: The State of Practice of Data Administration - 1 9 8 1 , in: CACM: Vol. 25, 10/1982, S. 699 f. (699-706). Vgl. NIEDEREICHHOLZ, J.; WENTZEL, C.: Voraussetzungen und organisatorische Wirkungen des Informationsmanagements, in: AI: 7/1985, S. 286 (284-290). MILLAR, V.E.: Decision-oriented information, in: Datamation: Vol. 30, 1/1984, S. 162 (159162). Eine ausführliche Diskussion dieser Thematik findet man bei TRAUTH, E.M.: The Evolution of Information Resource Management, in: Information & Management: Vol. 16, 5/1989, S. 258-260 (257-268). Vgl. HEINRICH, A.W.: Datenadministration, in: MERTENS, P. (Haupthrsg.): Lexikon der Wirtschaftsinformatik, a.a.O., S. 114 (114 f). GILLENSON, M.L.: Trends in Data Administration, in: MIS Quarterly: Vol.9, 12/1985, S. 317-325. Vgl. HEINRICH, L.J.; BURGHOLZER, P.: Informationsmanagement, a.a.O., S. 1 1 3 . MCCRIRICK, I.; GOLDSTEIN,

42

43

44

45

46

47

48

18

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

bezüglich des Datensystems der Unternehmung«^, unabhängig davon, ob die Daten EDV-gestützt oder manuell gefuhrt werden. Das betriebliche Datenmanagement besteht aus Personen,50 Produkten57 sowie Funktionen52 und hat die Aufgabe, die nachfolgend genannten Ziele zu erreichen:55 - Optimale Nutzung der betrieblichen Daten, - Verbesserung der Qualität der betrieblichen Entscheidungsgrundlage (Informationen), - Steigerung der Produktivität der Anwendungssystementwicklung durch den gezielten Einsatz von Datenbanksystemen und - die Verbesserung der Informations-Infrastruktur des Unternehmens. Der Nutzen von Daten wird durch folgende Qualitätsanforderungen bestimmt:54 - Richtigkeit: Alle Daten müssen richtig sein. Sie müssen bereits so erhoben sein, dass sie allen Anforderungen bezüglich ihrer späteren Verwendung entsprechen. - Aktualität: Die Daten sind möglichst zum Zeitpunkt ihres Anfallens automatisch zu erfassen. 49

Vgl. HEINRICH, L.J.; BURGHOLZER, P.: Informationsmanagement, a.a.O., S. 115.

50

Nach L.J. HEINRICH / P. BURGHOLZER zählen zu den mit dem Datenmanagement befaßten Personen der Entwicklungsadministrator, der Datenadministrator, gegebenenfalls ein Datenbankadministrator und die Anwendungssystem-Administratoren unter Leitung eines Informationssystem-Managers. Vgl. HEINRICH, L.J.; BURGHOLZER, P.: Informationsmanage-

51

53

ment, a.a.O., S. 145. Als Produkte werden ein Datenbanksystem, ein Datenlexikon (Data Dictionary/Repository) sowie eine geeignete Abfragesprache benötigt. Vgl. IBM DEUTSCHLAND G M B H (Hrsg.): Daten-Management, a.a.O., S. 17. Es umfaßt alle Planungs-, Überwachungs- und Steuerungsaufgaben einschließlich aller organisatorischen und technischen Fragestellungen, die im Zusammenhang mit dem Entwurf, der Haltung und der Bereitstellung von Daten, sowohl für die Nutzer aus den betrieblichen Bereichen als auch der Datenverarbeitung stehen. Vgl. dazu u.a. SCHULTE, U.: Praktikable Ansatzpunkte zur Realisierung von Datenmanagement-Konzepten, in: Information Management: 4/1987, S. 27 (26-31). Vgl. IBM DEUTSCHLAND G M B H (Hrsg.): Daten-Management, a.a.O., S. 6 - 9 und HEINRICH, L . J . ; BURGHOLZER, P . : I n f o r m a t i o n s m a n a g e m e n t , a . a . O . , S . 142.

54

V g l . BIETHAHN, J.; ROHRIG, N . : D a t e n m a n a g e m e n t ,

i n : KURBEL, K . ; STRUNZ, H .

(Hrsg.):

Handbuch Wirtschaftsinformatik, Stuttgart 1 9 9 0 , S. 7 4 0 f. ( 7 3 8 - 7 5 5 ) ; HOLTHUIS.J.; MUCKSCH, H.; REISER, M . : Das Data Warehouse Konzept - Ein Ansatz zur Informationsbereitstellung für Managementunterstützungssysteme, in: MUCKSCH, H. (Hrsg.): Arbeitsberichte des Lehrstuhls für Informationsmanagement und Datenbanken, Nr. 95-1, EUROPEAN BUSINESS SCHOOL (ebs) Schloß Reichartshausen, Oestrich-Winkel 1995, S. 5 f.; INMON, W.H.: Untangling the Web, in: Database Programming & Design: 5 / 1 9 9 3 , S. 7 4 ( 7 4 f.).

2.1 Begriff und Bedeutung des Datenmanagements

19

- Aufgabenbezogenheit / Relevanz: Alle Daten müssen aufgabenbezogen ermittelt und verarbeitet werden. - Genauigkeit: Die Genauigkeit muss auf das Arbeitsgebiet des jeweiligen Entscheidungsträgers abgestimmt sein. So sind z.B. im Bereich der Finanzbuchhaltung alle Beträge mit zwei Nachkommastellen zu führen, während im Bereich der Absatzplanung auf größere Einheiten gerundet wird. - Vollständigkeit: Alle Daten, die für die betrieblichen Aufgaben benötigt werden, müssen tatsächlich gesammelt vorliegen und auch vollständig dem Entscheidungsträger zur Verfügung gestellt werden.55 Nur so kann verhindert werden, dass er aufgrund fehlender Daten falsche Entscheidtingen trifft. - Konsistenz / Zusammenhangbezogenheit: Alle Daten müssen im Zusammenhang und nicht isoliert gesehen werden (ganzheitliche Betrachtungsweise). Die Konsistenz der Daten lässt sich nur gewährleisten, wenn die tatsächlichen Abhängigkeiten zwischen ihnen bekannt sind. Die Konsistenzprüfung sollte bereits bei der Dateneingabe - möglichst automatisch erfolgen.5* Daten, die aus ihrem ursprünglichen Umfeld gelöst wurden und mit diesem nicht mehr in Zusammenhang gebracht werden können, stellen für den Entscheidungsträger nur sehr unsichere Informationen dar. - Zugriffsmöglichkeit: Daten sind letztendlich für den Entscheidungsträger nur dann nützlich, wenn er einen schnellen Zugriff auf sie hat. Vorhandene, aber einem Benutzer nicht zugängliche Daten sind für diesen nicht existent. Dabei werden unter dem Begriff Zugriffsmöglichkeiten nicht nur die technischen und organisatorischen Voraussetzungen, sondern auch die Möglichkeiten der Herausfilterung bestimmter Daten aus einem Datenpool zusammengefasst. - Flexibilität: Die gespeicherten Daten müssen form-, manipulier- und transformierbar sein. So ist es bspw. nicht ausreichend, die Umsatzzahlen eines vorgegebenen Zeitraumes lediglich nach Produkten aufgeschlüsselt zur Verfügung zu stellen. Der Entscheidungsträger muss in die Lage versetzt werden, diese Zahlen entsprechend seinen individuellen Anforderungen nach weiteren Kriterien, wie z.B. Produktgruppen, Absatzkanälen oder frei bestimmbaren Zeiträumen, zu gliedern. 55

50

Diese Forderung darf aber nicht dazu fuhren, daß alle Daten, die nur auf irgendeine Art und Weise speicherbar sind, auch tatsächlich in dem Datensystem gesammelt werden. Diese Forderung beinhaltet, daß man sich von vornherein Gedanken macht, zu welchem Zweck die Daten benötigt werden. Es ist dabei sicherzustellen, daß nicht nur die Daten, die 80 bis 90% aller Anwendungsfälle ausmachen gesammelt werden. Weiterhin sind Meßeinrichtungen zu installieren und Verarbeitungsvorschriften zu erstellen, um diese Forderung zu erfüllen.

20

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

- Zeit- und Zeitraumbezug: Sie müssen dem Entscheidungsträger darüber hinaus zeitgerecht zur Verfügung stehen, da sie bei verspäteter Verfügbarkeit nur einen stark reduzierten oder sogar überhaupt keinen Nutzen für eine bestimmte Aufgabenstellung haben können. Werden bspw. neben den Daten, die aus operationalen DV-Systemen gewonnen werden, auch historische Daten über einen langfristigen Zeitraum gesammelt, so lassen sich wesentlich differenziertere Trendanalysen durchführen, als dies mit den kurzfristigen Daten aus dem Tagesgeschäft möglich wäre. Erst die frühzeitige Erkennung von Trends ermöglicht es Unternehmen, rechtzeitig auf Änderungen in ihrem Umfeld zu reagieren und somit entscheidende Wettbewerbsvorteile gegenüber ihren Konkurrenten zu erzielen.57 - Transportierbarkeit: Daten, die an einen bestimmten Ort oder ein bestimmtes System gebunden sind, haben für den Entscheidungsträger einen wesentlich geringeren Nutzen als Daten, die transportiert werden können und somit an beliebigen Orten verfügbar sind. - Sicherheit: Daten können für ein Unternehmen Wettbewerbsvorteile gegenüber der Konkurrenz darstellen. Sie sind daher vor unautorisiertem Zugriff zu schützen. Für eine konkrete Aufgabenstellung kann unter Umständen auch eine beliebige Kombination relevanter Faktoren ausreichend sein.5S Nur unter Berücksichtigung der genannten Anforderungen kann eine hinreichende Datenqualität erwartet werden. Die Vernachlässigung obiger Anforderungen führt dagegen automatisch zu falschen oder widersprüchlichen Managemententscheidungen, welche wiederum negative Auswirkungen auf das gesamte Unternehmen haben können. Unrichtige, ungenaue, nicht vollständige, aber auch nicht aktuelle Daten sind für jeden Anwender von nur geringem Wert. Noch schwerwiegender ist es aber, wenn sich bspw. Berichte verschiedener Abteilungen widersprechen, da die zugrunde liegenden Daten nicht übereinstimmen. Weiterhin muss die Informationsbereitstellung in unterschiedlich verdichteter Form erfolgen, damit die Entscheidungsträger verschiedener Hierarchiestufen mit den Informationen, welche für die jeweilige Entscheidungsfindung relevant sind, versorgt werden können. Im allgemeinen ist die Informationsverdichtung mit steigender Hierarchieebene und Verantwortung des einzelnen Mitarbeiters höher. 57

58

Vgl. LEWINSON, L.: Data Mining: Tapping into the Mother Lode, in: Database Programming & Design·. 2/1994, S. 50 (50-56). Vgl. INMON, W.H.: Untangling the Web, a.a.O., S. 74.

2.1 Begriff und Bedeutung des Datenmanagements

21

Bild 2-1: Informationsverdichtung innerhalb der betrieblichen Hierarchie59 Die bisherigen Ausführungen haben gezeigt, dass das Datenmanagement sowohl operative als auch dispositive und strategische Aspekte zu berücksichtigen hat.00 Bild 2-2 verdeutlicht die hierarchische Einordnung des Datenmanagements.

Bild 2-2: Einordnung des Datenmanagements Im Rahmen des Datenmanagements nimmt die Datenorganisation eine grundlegende Stellung ein. Nach H. WEDEKIND umfasst sie -

die Bildung von logischen Organisationseinheiten (Dateneinheiten) sowie die Festlegung ihrer Wertebereiche, - die Zuordnung der Dateneinheiten zu Speicherplätzen sowie 59 60

HOLTHUIS, J.; MUCKSCH, H.; REISER, M.: Das Data Warehouse Konzept, a.a.O., S. 6. Vgl. hierzu HEINRICH, L.J.; BURGHOLZER, P.: Informationsmanagement, a.a.O., S. 141 und MARTINY, L.; KLOTZ, M.: Strategisches Informationsmanagement, a.a.O., S. 83-132.

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

22

-

die Festlegung einer formalen Ordnung, um die gespeicherten Dateneinheiten wiederauffinden zu können. 07

Damit kann unter dem Begriff Datenorganisation die Gesamtheit aller Verfahren zur Darstellung, Speicherung und Verwaltung von Datenbeständen im Arbeitsspeicher und auf den externen Speichermedien eines Rechners verstanden werden. Die Datenorganisation lässt sich in einen logischen und einen physischen Bereich unterteilen. 62 Beide Bereiche können, wie Bild 2-3 zeigt, noch weiter gegliedert werden.

Datenorganisation

Logische Datenorganisation

Physische Datenorganisation

_ logische Datenstrukturen

_ physische Speicherstrukturen

- logische Zugriffspfade

- physische Speicherzuordnung

Bild 2-3: Gliederung der Datenorganisation Die Organisation der betrieblichen Daten kann entweder dateiorientiert oder datenbankorientiert erfolgen. 63 Kennzeichnend für den dateiorientierten oder konventionellen Ansatz ist eine Verflechtung von Anwendungsprogrammen und Daten, da die benötigten Dateien im jeweiligen Anwendungsprogramm zu

61

Vgl. WEDEKIND, H.: Datenorganisation, 2., verbesserte Auflage, Berlin/New York 1972, S. 30. Vgl. auch LUFT, A.L.: Dateiorganisation, in: MERTENS, P. (Haupthrsg.): Lexikon der Wirtschaftsinformatik, Berlin/Heidelberg/New York 1987, S. 92 (92-94). Eine umfassende Darstellung der logischen und physischen Ebenen der Datenorganisation nehmen M.E. SENKO u.a. in ihrem dreiteiligen Aufsatz vor: SENKO, M.E. u.a.: Data structures and accessing in data base systems, parts 1-3, in: IBM Systems Journal·. Vol. 12, 1/1973,

63

Vgl. MERTENS, P. u.a.: Grundzüge der Wirtschaftsinformatik, 3., verb.Auflage, Berlin u.a.

S. 3 0 - 9 3 . 1 9 9 5 , S. 56.

2.1 Begriff und Bedeutung des Datenmanagements

23

definieren sind und der Dateiaufbau sich an der Problemstellung orientiert. Aufgrund der starken Abhängigkeit von Datei und Programm ist diese Art der Problemlösung sehr unflexibel und wird hier nicht weiter betrachtet.04 Der datenbankorientierte Ansatz ist dagegen durch Datenunabhängigkeit, Datenintegrität sowie Redundanzarmut charakterisiert (Bild 2-4).65

Bild 2-4: Datei- und datenbankorientierter Ansatz^6 Die Sammlung der gespeicherten Informationseinheiten wird im datenbankorientierten Ansatz als Datenbank (DB) bezeichnet. Alle in der Datenbank gesammelten Daten und Texte werden mit Hilfe eines Datenbankverwaltungssystems für die Verarbeitung bereitgehalten. Datenbank und Datenbankverwaltungssystem bilden eine - aus der Sicht des Datenmanagements sogar die wichtigste operative - Basiskomponente eines idealtypischen ganzheitlichen Informationssystems (Bild 2-5).67

64

Vgl. STUCKY, W.; KRIEGER, R . : Datenbanksysteme, in: KURBEL, Handbuch Wirtschaftsinformatik, Stuttgart 1990, S. 840 (837-856).

65

Vgl. SCHLAGETER, G.; STUCKY, W.: Datenbanksysteme, a.a.O., S. 2 4 f.

66

In Anlehnung an: MERTENS, P. u.a.: Grundzüge der Wirtschaftsinformatik, a.a.O., S. 56 und STUCKY, W.; KRIEGER, R . : Datenbanksysteme, a.a.O., S. 8 4 1 . Vgl. BIETHAHN, J.; MUCKSCH, H . ; RUF, W . : Ganzheitliches Informationsmanagement, Band I, a.a.O., Kap. 5.

67

K . ; STRUNZ,

H. (Hrsg.):

24

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Betriebssystem Daten-/ Textbank

Datenverwaltungssystem

Programmsystem

OD

C

Α

D

Β

CD

Entnestung

C

D

Bild 2-33: Operatoren NEST und DENEST

Die Anwendung der Operatoren Nestung und Entnestung zeigt Bild 2-34 in tabellarischer Form. Das NF2-Datenbankmodell bemüht sich im wesentlichen um die Behebung des Aggregierungsproblems, in dem es die Spezifizierung reiner Hierarchien erlaubt. Gegenüber dem klassischen relationalen Modell enthält es zusätzliches semantisches Wissen, denn die nicht-atomaren Attribute sind direkt an ein übergeordnetes Tupel gebunden und verschwinden bei einer Löschung dieses Tupels automatisch. Ein weiterer Vorteil des NF2-Datenbankmodells ist die höhere Anwenderfreundlichkeit. Die Darstellung zusammengehöriger Informationen in wenigen NF2-Relationen erspart dem Anwender die langwierige Verknüpfung einzelner Daten aus vielen verschiedenen normalisierten Relationen. Dieses Modell beschreibt die Bestandteile des jeweiligen Datensystems in einer für die meisten Anwender gewohnten tabellarischen Struktur. Auch die im relationalen Modell nicht enthaltene Semantik zwischen Relationen ist hier, bezogen auf hierarchische Abhängigkeiten, vorhanden. Sie ermöglicht es dem Benutzer, die für ihn relevanten Informationen ohne zeitraubende Navigation im Datenbanksystem aufzufinden. Es entfallen zudem die notwendigen Verbundoperationen, die im

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

82

klassischen relationalen Datenbankmodell aufgrund der Vielzahl der einzelnen Relationen notwendig sind. Die gemeinsame Speicherung inhaltlich zusammengehörender Daten ergibt zudem eine Effizienzsteigerung hinsichtlich der Performance bei der Realisierung dieses Datenbankmodells.270 RT

RT'

A

Β

c

D

a1 a1 a1 a2 a2 a2

b1 b1 b1 b1 b1 b2

c1 c2 c3 c3 c1 c4

d1

Nestun

Β

CD

d1 d2 d2 d1 d2

a1

b1

c1 d1 c2 d1 c3 d2

a2

b1

c3 d2 c1 d1

a2

b2

c4 d2

Entnestung

Bild 2-34: Nestung und Entnestung in tabellarischer

Darstellung

2.4.2.4.2 Das erweiterte Non-First-Normal-Form-Datenbankmodell Das NF2-Datenbankmodell bietet zwar Konzepte zur Lösung der hierarchischen Darstellung komplexer Informationsobjekte, es löst jedoch nicht das Problem der Reihenfolge bzw. der Ordnung der Daten, wie es in geografischen Informationssystemen oder in Steuerungssystemen der Fertigungsindustrie von Bedeutung ist. Insbesondere im technischen Bereich geht man häufig mit Vektoren, Matrizen, Folgen von Messwerten, etc. um. Hier spielt demnach die Reihenfolge bzw. Ordnung der Daten eine gewichtige Rolle. Um die Integration von betriebswirtschaftlichen mit den genannten naturwissenschaftlichen Daten zu erreichen, wurde basierend auf dem Konzept des NF2-Datenbankmodells das erweiterte oder extended Non-First-Normal-Form-(eNF2) Datenbankmodell entwickelt. Das eNF2-Datenbankmodell erweitert das NF2-Datenbankmodell um strukturelle Konzepte wie

210 VGL GÄRTNER, M.: Die Eignung relationaler und erweiterter relationaler Datenmodelle für das Data Warehouse a.a.O.; S. 156.

2.4 Konstruktion und Modellierung eines Datensystems -

83

Listen (geordnete Relationen), Multisets (Dies sind Sets, die Duplikate besitzen können.), genestete Tupel und genestete (Multi-) Sets.277

Der Konstruktor Relation taucht in diesem Modell nicht mehr explizit auf, so dass man sich unter einer Relation (Bild 2-35) die Bezeichnung einer abkürzenden Schreibweise für eine Menge von Tupeln vorzustellen hat. Es können demzufolge beliebig komplexe Objekte in einer einzigen »Relation« abgebildet werden.

Die Weiterführung des Beispiels aus Kapitel 2.4.2.4.1 zum eNF2-Datenbankmodell zeigt Bild 2-36. Hier sei angenommen, dass die Bestandteile der Schränke automatisiert mit einer computergestützten Zuschneidemaschine bearbeitet werden. Die Steuerdaten sind dazu in Form der Angabe der Eckpunkte der zuzuschneidenden Teile in das Datenbankmodell einzufügen. Verbal verdeutlicht die eNF2-Relation folgenden Sachverhalt: Im Set PRODUKTGRUPPENDATEN wurde das Tupel BESTANDTEILE um die Liste ECKPUNKTE, deren Bestandteile wiederum Listen sind, erweitert. In

211

212

Vgl.

KÜSPERT, K.;

SAAKE, G.; WEGENER, L.: D u p l i c a t e

Detection

and D e l e t i o n

in

the

Extended NF 2 Data Model, in: LITWIN, W.; SCHEK, H.-J. (Hrsg.): INRIA -Foundation of Data Organisation and Algorithms, 3rd International Conference (FODO 1989), Paris, 21.-23. Juni 1989, Lecture Notes in Computer Science 367, Berlin/Heidelberg/New York 1989, S. 83-100. Quelle: LANG, S.M.; LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 98.

84

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

diesen »Listen einer Liste« sind die Steuerungsdaten der Zuschneidemaschine als X,Y-Koordinaten eingetragen. {PRODUKTGRUPPENDATEN) PRODUKT-

PRODUKT-

{PRODUKTE}

GRUPPEN-

GRUPPEN-

PROD.

PROD.

[BESTANDTEILE]

NUMMER

NAME

TYP

NAME

ART.

ART.

NR.

NAME

4735

Tür

A3000

Schränke

001

Einbau-

ANZ

1

Typ: A

schrank





5789

Seiten-

2

wand



6834

Rück-

1

wand



002

Kleider-

4710

schrank

Tür

2



Typ: Β

6754

Seiten-

2

< >

wand

Bild 2-36: Tabellarische Darstellung der eNF2-Relation

PRODUKTGRUPPEN

Sets und Tupel werden analog zum NF2-Datenbankmodell in geschweiften bzw. eckigen Klammern eingefasst. Zur Darstellung von Listen verwendet man die Symbole ''. Die hier gezeigte Erweiterung des Beispiels verlangt ein Datenbankmodell, das sowohl Konzepte für Standardanwendungen als auch für Nicht-StandardAnwendungen enthält. Mit dem eNF2-Datenbankmodell lässt sich insbesondere die Semantik innerhalb komplexer Informationsobjekte - damit sind die Beziehungen zwischen den einzelnen Bestandteilen eines solchen Objektes gemeint - besser wiedergeben.

2.4 Konstruktion und Modellierung eines Datensystems

85

2.4.2.4.3 Deduktive Datenbankmodelle Wie bereits erwähnt, steht bei einem deduktiven Datenbankmodell die Ableitung neuer Daten aus gespeicherten Fakten anhand eines Berechnungsmodells im Vordergrund. Das deduktive Datenbankmodell basiert auf der Erkenntnis, dass in den gespeicherten Daten einer Datenbank viele indirekte Sachverhalte und somit zusätzliches Wissen verborgen sind. Eine Extraktion dieses Wissens lässt sich nur mittels geeigneter Abfragemechanismen bewerkstelligen. Dazu werden Konzepte der Logikprogrammierung i.d.R. mit den Konzepten relationaler Datenbanken verbunden. Man spricht von einem deduktiven Datenbanksystem, wenn ein relationales Datenbanksystem - oder eine Erweiterung davon - eine Sprache als primäre Endbenutzersprache zur Verfügung stellt, die mit Hilfe von Regeln aus gespeicherten Fakten neue Daten ableitet. 273 Daher werden Systeme, denen ein deduktives Datenbankmodell zugrunde liegt, auch den erweiterten Sprachschnittstellen von Datenbanksystemen zugeordnet. 2 ^ Die Datenbasis eines deduktiven Datenbanksystems besteht aus einer Menge von Regeln und Fakten, deren konkrete Ausprägung explizit eingegeben werden muss. Die Fakten entsprechen den gespeicherten Basisdaten der bisher betrachteten Datenbasen. Die Faktendatenbasis wird auch als extensionale Datenbasis bezeichnet. Die Tupel, die nicht direkt als Grundfakten gespeichert sind, jedoch über Regeln abgeleitet werden können, bilden die sog. intensionale Datenbasis. Zwischen Fakten und Regeln existiert - wie Bild 2-37 verdeutlicht - kein struktureller Zusammenhang.

Bild 2-37:

Mächtigkeit und Orthogonalität des deduktiven Datenbankmodells215

Der Zusammenhang zwischen Fakten und Regeln wird erst durch den Ableitungsmechanismus hergestellt (Bild 2-38). Als Ergebnis einer Datenbankabfrage erhält man im Trivialfall wieder die gespeicherten Fakten, ansonsten

213 YGI

LANG, S . M . ; LOCKEMANN, P . C . : D a t e n b a n k e i n s a t z , a . a . O . , S. 1 6 1 s o w i e VOSSEN, G.:

Datenmodelle, a.a.O., S. 616. 2 1 4

V g l . HEUER, Α . ; SAAKE, G . : D a t e n b a n k e n , a . a . O . , S. 4 5 0 .

215

Quelle: LANG, S.M.; LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 162.

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

86

abgeleitete, und somit nicht explizit gespeicherte Daten. Diese kompakte Form der Datenhaltung vermeidet Redundanz im Datenbestand. Der Anwender muss auch nicht mehr wissen, ob das Ergebnis seiner Abfrage physisch in der Datenbasis gespeichert ist.

Sowohl die Fakten- als auch die Regeldarstellung erfolgt deklarativ mit Hilfe einer geeigneten Einschränkung der Prädikatenlogik erster Stufe, da dann auch das Berechnungsmodell auf einem prädikatenlogischen Ableitungsmechanismus basieren kann.277 Damit lassen sich sowohl relationenalgebraische als auch rekursive Anfragen formulieren. Im Gegensatz zu Logikprogrammiersprachen wie bspw. PROLOG (= Programmieren in Logik)27* werden jedoch keine Regel- und Faktenlisten, sondern Regel- und Faktenmengen betrachtet. Die Regelmengen sind dabei so zu optimieren, dass die Ableitung neuer Fakten mittels mengenbasierter Abfragen erfolgen kann. Die wohl bekannteste regelbasierte Abfragesprache im Datenbankbereich ist DATALOG. Die Abfragesprache DATALOG basiert im Gegensatz zu PROLOG auf einer Bottom-Up-Auswertung, indem - ausgehend von den Basisrelationen mittels der Regeln - schrittweise jeweils Mengen von abgeleiteten Fakten berechnet werden.279

2 1 6

Quelle: LANG, S.M.; LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 162.

217

Vgl.

dazu insbesondere DAS, S.K.: Deductive Databases and Logik Programming,

W o k i n g h a m / R e a d i n g / M e n l o Park

218

219

1992;

CERI, S.;

GOTTLOB, G.;

Programming and Databases, Berlin/Heidelberg/New GARDARIAN, G.; VALDURIEZ, P.: Relational Databases ding/Menlo Park/New York 1989, S. 315-377. Vgl. zu dieser Programmiersprache bspw. BRATKO, I.: Künstliche Intelligenz, Bonn/Reading/Menlo Park 1987. DATALOG wird ausführlich beschrieben in: CERI, S.; Programming and Databases, a.a.O., S. 75-144.

TANCA, L.:

Logic

York 1990, Kap. 5-7 sowie and Knowledge Bases, ReaPROLOG: Programmierung für GOTTLOB, G.; TANCA, L.: Logic

2.4 Konstruktion und Modellierung eines Datensystems

87

2.4.2.4.4 Objektorientierte Datenbankmodelle

Alle bislang geschilderten Datenbankmodelle beheben zwar einige der in Kapitel 2.4.2 aufgeführten Schwächen des klassischen relationalen Datenbankmodells; keine dieser Erweiterungen verbindet jedoch alle Lösungsansätze gleichzeitig. Darüber hinaus sind zwei weitere Schwachstellen klassischer Datenbanksysteme bislang nicht genannt worden: - das Fehlen leistungsstarker Integritätskonzepte zur Sicherstellung der Konsistenz der Datenbasis und - die existierende Kluft zwischen Programmier- und Datenbankanfragesprache (impedance mismatch).220 Die den heutigen Anwendungssystemen inhärente Komplexität lässt sich ohne effiziente Konzepte zur Sicherstellung der Konsistenz nur unzureichend modellieren. Auch die Schnittstelle zwischen Datenbankanfragesprache und herkömmlicher Programmiersprache ist i.d.R. erst im Nachhinein konzipiert worden. Die Übergänge sind daher nicht nahtlos, da beide Sprachen zudem ein eigenes Typsystem verwenden. Gerade aber die Abbildung eines Typsystems auf ein anderes kann zum Verlust von Semantik führen. Mit den Konzepten der Objektorientierung griff man daher im Datenbankbereich eine Entwicklung aus den Programmiersprachen auf, die nicht nur die Schwachstellen der bisher aufgeführten Datenbankmodelle zu beheben verspricht, sondern darüber hinaus auch noch die Vereinbarung anwendungsspezifisch zu vereinbarender Funktionen ermöglicht.227 Derartige Modelle werden als objektorientierte Datenbankmodelle bezeichnet. Sie sind - ganz allgemein formuliert - eine Synthese von objektorientierten Konzepten und Datenbankmodellen. Zum besseren Verständnis der folgenden Ausführungen wird an dieser Stelle zunächst der Unterschied zwischen den bisher betrachteten Datenobjekten und dem nun verwendeten Objektbegriff verdeutlicht:222 Der Begriff »Objekt« hat hier eine völlig andere, viel umfassendere Bedeutung: Im objektorientierten Paradigma wird die ansonsten übliche Trennung zwischen Funktion und Daten aufgehoben. Die Diskurswelt wird im Sinne der Objektorientierung als eine Menge miteinander kommunizierender Objekte betrachtet, die sowohl Eigenschaften (Daten) als auch Verhalten (Methoden) umfassen. Objekte, die gemeinsame Eigenschaften und Verhaltensmuster gegenüber anderen Objekten aufweisen, fasst man zu (Objekt-)Klassen 220

Vgl. UNLAND, R.: Objektorientierte Datenbanken, a.a.O., S. 2 f. Vgl. LANG, S.M.; LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 175. 222 Ygj jju ,j e n Grundlagen der Objektorientierung auch Kapitel 3.6. 221

88

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

zusammen. Eine Klasse ist eine Vorlage (= Template), welche die Variablen und Methoden definiert, die einer bestimmten Art von Objekt zugeordnet werden sollen. Jedes Objekt ist eine Instanz (= Element) einer Klasse. Das Verhaltensrepertoire eines Objektes wird dem Benutzer über eine definierte Schnittstelle in Form von Operatoren verfügbar gemacht. Das Zusammenwirken von bzw. die Kommunikation zwischen Objekten erfolgt durch Nachrichtenaustausch. Sendet bspw. ein Objekt einen »Wunsch« in Form einer Nachricht an ein anderes Objekt, so wird dort eine nach außen verborgene, passende Folge von Operationen ausgeführt. Das Ergebnis dieser (objekt-)internen Operationsfolge wird wiederum als Nachricht an das anfragende Objekt zurückgesandt. Bild 2-39 verdeutlicht den Unterschied zwischen dem traditionellen und dem objektorientierten Paradigma.

objektorientiertes Paradigma

Bild 2-39: Objektorientiertes

traditionelles Paradigma ι 2 3

versus traditionelles

Paradigma223

Obwohl objektorientierte Datenbanksysteme (OODBS) seit 1987 am Markt verfügbar sind, besteht derzeit noch kein allgemeiner Konsens für Anforderungen an ein einheitliches objektorientiertes Datenbankmodell.224 So nennt der 223

224

Quelle: WINBLAD, A.L.; EDWARDS, S.D.; KING, D.R.: Object-Oriented Software, Reading

1990, S. 50. Zu nennen sind folgende Darstellungen, in denen Grundanforderungen für objektorientierte Datenbanken festgelegt sind: ATKINSON, M . u.a.: The object-oriented database system Manifesto, in: KIM,W.; NICOLAS, J.-M.; NISHIO, S. (Hrsg.): Proceedings 1st Int. Conf. on Deductive and Object-Oriented Databases, Kyoto 1989, S. 40-57; BEERI, C.: Formal models for object-oriented databases, in: KIM,W.; NICOLAS, J.-M.; NISHIO, S. (Hrsg.): Proceedings 1st Int. Conf. on Deductive and Object-Oriented Databases, Kyoto 1989, S. 370-395; BEERI,

2.4 Konstruktion und Modellierung eines Datensystems

89

Vorschlag von M. ATKINSON u. a. - bekannt als »The object-oriented database system Manifesto«225 - eine Vielzahl an Kriterien sowohl aus dem Bereich objektorientierter Programmiersprachen als auch dem der Datenbanken. Die aufgeführten Kriterien werden in unbedingt notwendige, optionale und offene Bestandteile eines OODBS untergliedert.22'* Nach C. BEERI umfasst ein objektorientiertes Datenbankmodell einen Struktur- und einen Operationsteil sowie zusätzliche, höhere Konzepte.227 Im Strukturteil eines objektorientierten Datenbankmodells werden die statischen Aspekte der Objekte und die zwischen Objekten existierenden Beziehungen beschrieben. Folgende Konzepte sollten verfügbar sein:22Ä -

Standardtypen (integer, string, etc.) Typkonstruktoren für komplex strukturierte Objekte Mit Hilfe von Typkonstruktoren können aus existierenden Datentypen neue, komplexere Datentypen aufgebaut werden. Der gewählte Typkonstruktor bestimmt den Aufbau des strukturierten Datentyps. Man unterscheidet zwischen einem Tupelkonstruktor (tuple of), einem Mengen- (set of) und einem Listenkonstruktor (list of). Der Tupelkonstruktor fasst eine bestimmte Anzahl von unterschiedlichen Komponenten zusammen. Es entsteht so ein Tupel bestehend aus Instanzen der zugrunde liegenden Typen, die daher auch als Komponententypen bezeichnet werden. Der Mengenkonstruktor ermöglicht es, aus einer Anzahl unterschiedlicher Objekte desselben Typs eine Menge zu bilden. Mit Hilfe des Listenkonstruktors wird ebenfalls eine Anzahl von Objekten desselben Typs zusammengefasst; nur ist in diesem Fall die Liste geordnet. Zudem können Objekte in der Liste mehrfach vorkommen.229 Nach R. UNLAND sind Typkonstruktoren zwar notwendige, aber noch nicht hinreichende Konstrukte für die Bildung komplex strukturierter Objekte. Er

C.: Α formal approach to object-oriented databases, in: Data & Knowledge Engineering: 4/1990, S. 353-382 sowie CATTELL, R.G.G. (Hrsg.): The Object Database Standard: ODMG93, Release 1.1, San Francisco 1994. 225 YGJ ATKINSON, M. u.a.: The object-oriented database system Manifesto, a.a.O., S. 40-57. 226 ygj. zum OODBS-Manifesto auch die Ausführungen in Kapitel 2.7.1.1. 227

228

2 2 9

Vgl. BEERI, C.: Formal models for object-oriented databases, a.a.O., S. 370-395 und BEERI, C.: A formal approach, a.a.O., S. 353-382. Vgl. dazu auch: HEUER, Α.; SAAKE, G.: Datenbanken, a.a.O., S. 115 ff. sowie HEUER, Α.: Objektorientierte Datenbanken, a.a.O., S. 275 ff. Vgl.

HEUER, Α . :

Objektorientierte

Datenbanken,

a.a.O.,

S. 2 7 9 ;

HEUER, Α . ;

SAAKE, G . :

Datenbanken, a.a.O., S. 117; LANG, S.M.; LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 184 f. sowie UNLAND, R.: Objektorientierte Datenbanken, a.a.O., S. 19.

90

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements verdeutlicht dies am Beispiel des Objektes »KONTO«:·230 Aus der Sicht einer Bank stellt ein Konto - zusammengesetzt aus den Attributen BLZ, KONTO-NR. und BANKBEZEICHNUNG - ein wesentliches Realweltobjekt dar, das fur einen Kunden steht, um den man sich bemühen muss. Aus der Sicht eines Arbeitgebers hingegen ist das Konto eines Mitarbeiters eher etwas Unwesentliches, da es problemlos durch ein anderes ersetzt werden könnte, obwohl es die gleichen Attribute aufweist. Hier erscheint die Unterscheidung in Objekt und Wert sinnvoll, da das Konstrukt KONTO im ersten Fall einen eigenständigen Entity-Typ darstellt und im anderen Fall lediglich einen zusammengesetzten Attributwert. Objekte können daher aus Anwendungssicht zwei Rollen annehmen. Einerseits repräsentiert ein Objekt etwas Eigenständiges, andererseits kann es als Unterobjekt bzw. als Komponente Bestandteil eines anderen Objektes sein. Man bezeichnet solche Objekte daher als Komponentenobjekte. In diesem Zusammenhang sind folgende weitere Unterscheidungen zu treffen:257 - Ein Objekt, dessen Existenz nicht von der Existenz anderer Objekte abhängt, wird als eigenständiges Objekt bezeichnet, anderenfalls handelt es sich um ein abhängiges Objekt. - Ein Objekt heißt exklusiv, wenn es nur ein eigenständiges Objekt und nicht zusätzlich noch Komponentenobjekt eines anderen Objektes ist, oder als Komponentenobjekt nur genau in einem anderen Objekt vorkommt. - Ein Objekt, das in mehreren anderen Objekten als Komponentenobjekt vorkommt, nennt man gemeinsames Objekt, bzw. überlappendes Objekt (= shared object). Die Zuordnungen abhängig / unabhängig und exklusiv / gemeinsam bilden jeweils ein Paar, wobei ein Objekt immer nur eine der beiden Eigenschaften jedes Paares annehmen kann. Es lassen sich daraus folgende Kombinationen bilden, deren Bedeutung mit Hilfe zweier Objekte (VORLESUNG und DOZENT) erläutert wird:252 - abhängig / exklusiv: (Spezialvorlesung, die genau ein Dozent halten darf)

230 231 232

Vgl. UNLAND, R.: Objektorientierte Datenbanken, a.a.O., S. 20. Vgl. UNLAND, R.: Objektorientierte Datenbanken, a.a.O., S. 21 f. Das Beispiel zur Verdeutlichung der Kombinationen ist entnommen aus: UNLAND, R.: Objektorientierte Datenbanken, a.a.O., S. 21 f.

2.4 Konstruktion und Modellierung eines Datensystems

91

-

abhängig / gemeinsam: (Spezialvorlesung, die mehrere Dozenten gemeinsam halten) - unabhängig / exklusiv: (Pflichtvorlesung, die genau ein Dozent hält) - unabhängig / gemeinsam: (Pflichtvorlesung, die mehrere Dozenten gemeinsam halten) Es sei hierbei unterstellt, dass eine Spezialvorlesung dann aus dem Vorlesungsangebot gestrichen wird, wenn der Dozent, der diese Veranstaltung anbietet, die Hochschule verlässt. Eine Pflichtvorlesung wird jedoch auch bei einem Universitätswechsel eines Dozenten noch im Vorlesungsangebot enthalten sein. - Objektidentität Für jedes Objekt in der Datenbank wird ein eindeutiger, für den Benutzer unsichtbarer Objektidentifikator vom System vergeben.233 »Die Identität eines Objektes ist während seiner Lebensdauer unveränderlich.«234 Objekte sind somit durch ihre Existenz unterscheidbar und nicht mehr nur durch eine Beschreibung ihrer Eigenschaften wie bspw. im relationalen Datenbankmodell. - Klassen Objekte mit ähnlichen Eigenschaften werden - wie bereits erwähnt - zu Klassen zusammengefasst. Sie beschreiben den aus Standarddatentypen und Typkonstruktoren gebildeten Zustandstyp der Objekte, die Menge der vorgesehenen Objektidentitäten (= Objektvorrat bzw. abstrakte Domäne) und die Menge der aktuell vorhandenen Objekte (= Objektbehälter bzw. Instanzen). Zum anderen beschreiben Klassen auch die Methoden, mit denen Objekte einer Klasse manipuliert werden können. Klassen können darüber hinaus in diversen Beziehungen zueinander stehen. Man unterscheidet üblicherweise die Komponentenbeziehung und die IS-ABeziehung, die der IST-Beziehung des ER-Modells ähnelt.235 Durch Komponentenbeziehungen werden objektwertige Attribute beschrieben. So könnte man bspw. die Klasse VORLESUNGEN als Komponentenklasse der Klasse DOZENTEN auffassen, da Vorlesungen bekanntlich nur von Dozenten gehalten werden. In objektorientierten Modellen gibt es mehrere Ausprägungen der IS-A233

Zu den diversen Möglichkeiten, Objektidentifikatoren zu vergeben und zu implementieren vgl. bspw. HEUER, Α.: Objektorientierte Datenbanken, a.a.O., S. 289 ff.

234

LANG, S . M . ; LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 179.

235

V g l . HEUER, Α.; SAAKE, G.: Datenbanken, a.a.O., S. 117.

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

92

Beziehung. Man unterscheidet Klassen-, Typ- und Implementierungshierarchien.·256 In einer Klassenhierarchie ist die Objektmenge der Unterklasse immer eine Teilmenge der Objektmenge der Oberklasse. So ist bspw. die Objektmenge der Klasse PROFESSOREN eine Teilmenge der Objektmenge HOCHSCHULANGEHÖRIGE. Die Typhierarchie - auch Subtyp-Beziehung genannt - bedeutet, dass die Unter- (Sub-) Klasse mehr Eigenschaften aufweist, als der Typ der Oberklasse. So hat der Typ PROFESSOR neben den Eigenschaften des Typs HOCHSCHULANGEHÖRIGER bspw. auch noch die Eigenschaften LEHRBEFUGNIS und LEHRVERPFLICHTUNG. Die Implementierungshierarchie ist für Datenbankmodelle ohne Bedeutung. Sie stammt aus der Programmierpraxis und bedeutet, dass die Unterklasse Attribute, Methoden und deren Implementierungen erbt.257 Wie bei jedem anderen Datenbankmodell auch, enthält der Operationenteil geeignete Anfrage- und Änderungsoperationen. Für Anfragen müssen bspw. Operationen für Selektionen im Objektbehälter einer Klasse bzw. für spezielle Verbünde Pfadausdrücke zu Komponenten dieser Klasse verfügbar sein. Zu den Update-Operationen gehören u.a. das Erzeugen und Löschen von Objekten sowie das Ändern des Objektzustandes.255 Zu den höheren Konzepten eines objektorientierten Datenbankmodells gehören Meta-Klassen, Methoden, die Vererbung, das Overriding von Methoden sowie die Einkapselung. Auf die Erläuterung der genannten Konzepte wird an dieser Stelle verzichtet, da auf sie im Rahmen der Ausführungen zur objektorientierten Softwareentwicklung noch eingegangen wird. 259 2.4.3

Entwicklung des von Ausprägungen des Zielsystems unabhängigen konzeptionellen Datenbankschemas

Die im Datensystem als Datenobjekte abzubildenden Sachverhalte der Diskurswelt werden i.d.R. über einen langen Zeitraum - zumindest was die grundlegenden Entity-Typen wie Kunden, Produkte, Aufträge, Rechnungen etc. betrifft - weitestgehend unverändert bleiben. Die seitens der Anwendungen an 236

Vgl. HEUER, Α.; SAAKE, G.: Datenbanken, a.a.O., S. 118.

257

Vgl. dazu die Ausführungen in Kapitel 3.6. 238 Vgl. HEUER, Α.; SAAKE, G . : Datenbanken, a.a.O., S . 119 sowie LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 185. 239 y g j ( j a z u jjjg Ausführungen in Kapitel 3.6.

LANG,

S.M.;

2.4 Konstruktion und Modellierung eines Datensystems

93

das Datensystem gestellten Anforderungen können sich jedoch als recht kompliziert erweisen. Diese Anforderungen muss eine einmal entworfene Datenbasis für die operativen Systeme auch mittel- bis langfristig erfüllen können. Ihre Entwicklung ist daher als eine Investition mit weitreichenden Auswirkungen anzusehen, die sorgfältig geplant und ausgeführt werden muss.240 Die Planung und Entwicklung einer zentralen Datenhaltung für viele unterschiedliche betriebliche Anwendungssysteme zählt daher zu den strategischen Aufgaben des Informationsmanagements. Im Rahmen einer Informationsbedarfsanalyse sind dabei zunächst die für die Aufrechterhaltung des Unternehmenszweckes notwendigen Geschäftsabläufe bzw. Arbeitsabläufe näher zu untersuchen. Ermittelt werden die zur Durchführung dieser Aufgaben notwendigen und relevanten Informationsobjekte und ihre Beziehungen untereinander. Mit der Informationsbedarfsanalyse verfolgt man den Zweck, die in der Gesamtunternehmensanalyse ermittelten Informationen zu konkretisieren und prüft aus der Sicht der »Miniwelt des Anwendungsfalles«, welche konkreten Informationen für die geplanten Anwendungen von Interesse sind.247 Die gesammelten Informationen sind zu gliedern, zu klassifizieren und zu beschreiben. Für diese Aufgabe werden die Methoden zur Erhebung und Darstellung eines Systemzustandes herangezogen.242 Für jeden Arbeitsablauf ist zu prüfen, welches Unternehmensmitglied in diesem Bereich verantwortlich ist und welche konkreten Informationen für eine reibungslose Fortführung der Arbeit benötigt werden. Da es sich bei betrieblichen Anwendungen i.d.R. um sehr komplexe Systeme handelt, kann die Informationsbedarfsanalyse nur in den seltensten Fällen in einem Schritt durchgeführt werden. Vielmehr bietet es sich an, in leichter zu überblickenden Teilschritten vorzugehen. In Anlehnung an H.C. MAYR u.a. umfasst die Informationsbedarfsanalyse folgende Teilphasen:245

240

In Analogie zu den Vorgehensmodellen des allgemeinen Softwareentwurfs läßt sich auch der Datenbankentwurf in mehrere Teilschritte untergliedern. Vgl. bspw. HEUER, Α . ; SAAKE, G.: Datenbanken, a.a.O., S. 136 f. sowie LANG, S.M.; LOCKEMANN, P.C.: Datenbankeinsatz, a.a.O., S. 292 f. 241 Ygi Begriff Informationsbedarf: WINDLER, Α . : Informationsbedarf, in: MERTENS, P. (Haupthrsg.): Lexikon der Wirtschaftsinformatik, Berlin/Heidelberg/New York 1987, S. 184 f. 242 Vgl. BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band 1, a.a.O., S. 348 ff. 245 Auf die einzelnen Teilschritte der Informationsbedarfsanalyse wird hier nicht weiter eingegangen. Vgl. dazu MAYR, H.C.; DITTRICH, K . R . ; LOCKEMANN, P.C.: Datenbankentwurf, Z U J J J

94

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

1. 2. 3. 4. 5. 6. 7.

Identifikation der Organisationseinheiten Identifikation der ggf. zu unterstützenden betrieblichen Aufgaben Erstellung eines Anforderungs-Sammelplans Sammlung der Anforderungen bei den Informationslieferanten Filterung der gesammelten Anforderungen Klassifikation der gefilterten Anforderungen Übertragung der klassifizierten Informationsobjekte, Operationen und Ereignisse in formalisierte Verzeichnisse.

Eine derart systematisch durchgeführte Informationsbedarfsanalyse liefert nicht nur Ergebnisse für den Datenbankentwurf, sondern dient auch als Grundlage für die Entwicklung der betrieblichen Anwendungssysteme. Parallel zur Informationsbedarfsanalyse sind auch die bereits vorhandenen Datenbestände zu untersuchen und auf ihre Bedeutung sowie ihre Weiterverwendbarkeit zu überprüfen. Das Ergebnis der Informationsbedarfsanalyse ist anschließend in einer semantischen Analyse in Entity-Typen sowie Beziehungs-Typen zu transformieren. Dabei sind auch die untersuchten vorhandenen Datenbestände einzubeziehen. Die größte Schwierigkeit bei der Entwicklung eines unternehmensweiten konzeptionellen Datenbankschemas liegt in seiner Größe und Komplexität begründet. Man wird daher die Modellentwicklung nicht in einem Entwurf vornehmen, sondern zunächst einzelne Teilbereiche betrachten, für diese Teilschemata entwickeln, die in einem nachfolgenden Schritt zum konzeptionellen Gesamtschema zusammengefasst werden. Der Aspekt der Entwicklung verschiedenster Anwendungssysteme unter Berücksichtigung des unternehmensweiten konzeptionellen Datenbankschemas darf aber keinesfalls vernachlässigt werden, da eine Anwendungssystementwicklung aus isolierter Sicht des jeweiligen Bereichs oder Projektes gegen jegliches einheitliche Vorgehen beim ganzheitlichen Aufbau betrieblicher Informationssysteme verstößt.·244 Praktikabel ist das unternehmensweite konzeptionelle Datenbankschema auch nur, wenn bei seiner Entwicklung sämtliche Unternehmensziele mitberücksichtigt und die zuständigen Mitarbeiter der unterschiedlichen Unternehmensbereiche und Abteilungen in die Entwicklung mit einbezogen

a.a.O., S. 489 f. sowie WIEDERHOLD, G.: Datenbanken, Analyse - Design - Erfahrungen, Band 2: Datenbanksysteme, München/Wien 1981, S. 50 f. 244 VGL VETTER, M.: Strategie der Anwendungssoftware-Entwicklung: Planung, Prinzipien, Konzepte, Stuttgart 1988, S. 16 f.

2.4 Konstruktion und Modellierung eines Datensystems

95

wurden. Zudem sollten die Gesamtzusammenhänge der Daten so unabhängig wie möglich von der gerade realisierten Unternehmensorganisation sein. Je nach dem vorherrschenden Stand der Informationsverarbeitung im Unternehmen kann das Vorgehen beim konzeptionellen Datenbankentwurf durch einen Top-Down- oder einen Bottom-Up-Ansatz erfolgen. Grundsätzlich empfiehlt sich eine Top-Down-Vorgehensweise. »Durch Kommunikations- bzw. Informationssystemstudien wird ein repräsentativer Teilbereich des Unternehmens betriebsorganisatorisch untersucht und die jeweiligen Daten und Prozessmodelle daraus abgeleitet.«245 Der Zerlegungsvorgang geht zunächst von ungeordneten Datenelementen aus, die nach relativ groben Kriterien in Teilmengen zerlegt werden. Anschließend erfolgt eine immer stärkere Verfeinerung, bis schließlich einfache Datenstrukturen erreicht werden. Genau den umgekehrten Weg (Bottom-Up) verfolgt die Struktursynthese, bei der elementare Elemente zu gröberen Einheiten verdichtet werden.·246 Ein solches Bottom-Up-Vorgehen könnte dann sinnvoll sein, wenn die DV im Unternehmen bereits lange Zeit auf einem hohen Niveau mit breiter Datenbasis und gutem Systementwicklungsstand eingesetzt wird und lediglich eine Reorganisation der Systeme vorgenommen werden muss. Beim Bottom-UpAnsatz können dann die Daten der vorhandenen Datenbasis die Grundlage des neuen konzeptionellen Datenbankschemas bilden. Üblicherweise erfolgt die Transformation der Ergebnisse der Informationsbedarfsanalyse in das unternehmensweite konzeptionelle Datenbankschema in drei Teilschritten: Zunächst werden spezielle Sichten verschiedener Fachabteilungen auf die Gesamtsicht des Datensystems konstruiert.247 Dieser Teilschritt beinhaltet auch das Erkennen von funktionalen Abhängigkeiten zwischen den einzelnen Datenobjekten. Man bezeichnet die Erfassung, Abgrenzung und Abstraktion des für die Problemstellung relevanten Teils der Umwelt daher auch als »Konstruktion von Datenstrukturen«. Zudem werden die Eigenschaften der konstruierten Datenobjekte untersucht und die Bestimmung ihrer Wertemengen vorgenommen. Die konstruierten Datenobjekte werden dann im zweiten Teilschritt gemäß der Anforderungsspezifikation in formalisierter, aber leicht verständlicher Form

245

246

BIETHAHN, J.; ROHRIG, N . : D a t e n m a n a g e m e n t , a.a.O., S. 7 4 4 .

Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 15. 247 Ygj (JAZU (JJE Ausführungen zum logischen Design der Anwendungen in Kapitel 2.4.5.

96

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

auf sachliche Richtigkeit, Vollständigkeit und Widerspruchsfreiheit geprüft245, d.h., man beseitigt existierende Konflikte zwischen den konstruierten Teilsichten. Folgende Konflikte können durch die Konstruktion verschiedener Teilsichten entstehen und müssen daher gefunden und behoben werden:249 -

Namenskonflikte Unter einem Namenskonflikt versteht man die Verwendung verschiedener Begriffe für ein und dasselbe Konzept (Synonyme) sowie die Benennung eines Konzepts mit unterschiedlichen Bezeichnungen (Homonyme). Synonyme und Homonyme entstehen zwangsläufig durch die Mehrdeutigkeit unserer natürlichen Sprache und führen in Datenbasen häufig zu redundanter Speicherung derselben Datenobjekte.

-

Typkonflikte Typkonflikte treten dann auf, wenn für ein Datenobjekt, das in mehreren Sichten vorkommt, unterschiedliche Strukturen vorgesehen werden. Auch Typkonflikte entstehen zwangsläufig, da die diversen Sichten verschiedene Informationsbedarfe ihrer Anwendungen abdecken müssen.

-

Wertebereichskonflikte Wertebereichskonflikte beziehen sich auf die Eigenschaften von gleichen Datenobjekten in unterschiedlichen Anwendungssichten. So könnte bspw. das Attribut TELEFONNUMMER in der Anwendungssicht einer Abteilung als mehrstellige Zahl und in einer anderen Anwendungssicht als Zeichenkette definiert sein.

-

Bedingungskonflikte Bedingungskonflikte treten dann auf, wenn in verschiedenen Sichten verschiedene Integritätsbedingungen für einen Datenobjekt-Typ angegeben werden. So könnte bspw. der Datenobjekt-Typ MITARBEITER einmal mittels seiner Personalnummer identifiziert werden und in einer anderen Sicht über seinen Nachnamen.

-

Strukturkonflikte Strukturkonflikte entstehen, wenn der gleiche Sachverhalt durch unterschiedliche Datenmodellkonstrukte ausgedrückt wird.

248 V g L ( j a z u 2 4 9

aucjj

Punkt 7 der Teilschritte zur Informationsbedarfsanalyse.

V g l . HEUER, Α . ; SAAKE, G.: D a t e n b a n k e n , a . a . O . , S. 1 3 9 f.

2.4 Konstruktion und Modellierung eines Datensystems

97

Darüber hinaus findet man durch die Analysen des zweiten Entwicklungsschrittes auch bislang nicht beachtete Beziehungen zwischen den verschiedenen Anwendungssichten. In einem dritten Teilschritt erfolgt letztlich die Integration der verschiedenen Teilsichten in ein konsistentes Gesamtschema. Die Konstruktion der Datenobjekte sowie ihre Beschreibung und Darstellung erfolgt mit Hilfe der vorgestellten abstrakten semantischen Datenmodelle, und dient dem Abgleich der Vorstellungen der Abteilung Daten- / Informationsverarbeitung mit denen der betroffenen Fachbereiche und Abteilungen. Die bisherigen und auch die nachfolgenden Ausführungen in Kapitel 2.4.4 werden nun anhand eines Beispiels verdeutlicht.250 In unserem Beispielunternehmen sind folgende Umstellungsmaßnahmen bezüglich des Informationssystems geplant: Das Auftragswesen der Firma soll auf Datenbankbetrieb umgestellt werden. Die Auftragserfassung, die Kundenstammpflege und weitere diverse Auswertungen sollen im Dialog erfolgen; für die Rechnungsschreibung und einige Monatsauswertungen ist Batchbetrieb vorgesehen. Das Auftragswesen steht im Informationsaustausch mit Kunden, Vertretern, der Verkaufsleitung und Lieferanten. Ausgetauscht werden z.B. Aufträge, Kunden- und Lieferantenrechnungen. Aufgrund der durchgeführten Informationsbedarfsanalyse ergibt sich der Grobentwurf (Bild 2-40). Alle verwendeten Bezeichnungen sollten von Projektbeginn an in Zusammenarbeit mit den Fachabteilungen festgelegt werden, da sie das Informationsangebot des Unternehmens auf begrifflicher Ebene darstellen und die gemeinsame sprachliche Basis für die Kommunikation aller an der Organisation von DV-Abläufen beteiligten Personen bilden.25^

250

Vgl. Software AG: Ausbildung - ADABAS DB Design, Darmstadt 1989.

251 VGL VETTER, M . : Das Jahrhundertproblem der Informatik, a.a.O., S . 16.

98

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Die für das Auftragswesen ermittelten Informationsobjekte und ihre Eigenschaften veranschaulicht Bild 2-41. Das Ergebnis der semantischen Analyse und die Analyse der gesammelten Daten führt in unserem Beispiel zum nachstehend abgebildeten EntityRelationship-Diagramm der Grobstruktur des Auftragswesens. Auf eine Darstellung der Eigenschaften wird in Bild 2-42 aus Gründen der Übersichtlichkeit verzichtet. Das konzeptionelle Datenbankschema enthält nur typmäßige und keine wertmäßigen Aussagen über die zu modellierenden Datenobjekte. So kann die Aussage »Jeder Kunde des Unternehmens hat eine Kundennummer, einen Kundennamen sowie eine Anschrift und ist einer bestimmten Kundenkategorie

2.4 Konstruktion und Modellierung eines Datensystems

99

VERKAUFSAUFTRAG - Auftragsnummer - Kundennummer - Kundenname - Kundenadresse - Telefonnummer - Auftragsdatum - Auftragspositionen (bis zu 50): - Bestellmenge - Produktlinie - Produktnummer - Produktname

KUNDE - Kundennummer - Kundenname - Kundenadresse - Kundenkategorie - Rabatt - Vertriebsregion - Vertreternummer - Vertretername - Telefonnummer - Datum der Erstbestellung - Zahlungsmoral - laufender Umsatz - Vorjahresumsätze (bis zu 4): - Jahr - Betrag

KUNDENRECHNUNG - Auftragsnummer - Kundennummer - Kundenname - Kundenadresse - Telefonnummer - Rechnungsdatum - Rechnungsposition (bis zu 50): - Bestellmenge - Produktlinie - Produktnummer - Produktname - Einzelpreis - Rabatt - Verkaufspreis - Rechnungssumme - Sonderrabatt - Mehrwertsteuerbetrag - Rechnungsbetrag

PRODUKT - Produktlinie - Produktnummer - Produktname - Verkaufspreis - Bestand - Mindestbestand - Bestellkennzeichen - Bestelldatum - Bestellmenge - Linienrabatt - Lieferanten (bis zu 5): - Lieferantenname - Lieferantenadresse

LIEFERANT - Lieferantenname - Lieferantenadresse - Lieferangebote (bis zu n): - Produktlinie - Produktnummer - Einkaufspreis - Lieferfrist

Bild 2-41: Auftragswesen: Datenobjekte und ihre Eigenschaften

100

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

wird geliefert

Lieferant

Bild 2-42: ER-Diagramm: Auftragswesen (Grobentwurf)252 zugeordnet« aus dem Modell abgeleitet werden. Eine wertmäßige Betrachtung hingegen - »Der Kunde »MEIER« ist ein »GROSSKUNDE«. - ist aus dem konzeptionellen Datenbankschema nicht ersichtlich. Wertmäßigen Aussagen beziehen sich immer auf ein bestimmtes Datenobjekt und sind daher auch nicht allgemein gültig. Den bisherigen Prozessablauf sowie die Umsetzung des zielsystemunabhängigen konzeptionellen Datenbankschemas in das relationale Datenbankmodell verdeutlicht Bild 2-43. Der gesamte, in Bild 2-43 dargestellte Ablauf ist nicht als rein sequenzieller Prozess zu sehen, vielmehr wird das Vorgehen durchaus Rückkopplungen enthalten. 2.4.4 Umsetzung in das relationale Datenbankmodell

Betrachtungsgegenstand dieses Kapitels ist die Umsetzung des im Konstruktionsprozess entstandenen zielsystemunabhängigen konzeptionellen Datenbankschemas in die formalen Anforderungen eines realisierbaren Datenbankmodells(hierarchisches, Netzwerk-, relationales oder objektorientiertes

252

Die Pfeilspitzen verdeutlichen die Kardinalität der Beziehungen (1:1; l:n; n:m) und stellen lediglich eine mögliche Notationsform dar.

2.4 Konstruktion und Modellierung eines Datensystems

101

Bild 2-43: Entwicklung des konzeptionellen Datenbankschemas und Umsetzung in das relationale DatenbankmodelP5i Datenbankmodell). Aufgrund der Tatsache, dass für die Verwaltung der Datenbasis operativer kommerzieller Anwendungen relationale Datenbanksysteme gegenwärtig als State-of-the-Art gelten, haben wir zur Darstellung des nächsten Transformationschrittes als Zielmodell das relationale Datenbankmodell gewählt. Die Modellierung von Datenstrukturen kann - wie bereits erwähnt - in Abhängigkeit von der Ausgangssituation in einem Zerlegungs- oder einem 253

V g l . MAYR, H.C.; DITTRICH, K.R.; LOCKEMANN, P.C.: Datenbankentwurf; a.a.O., S. 4 8 9 f.

102

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Synthesevorgang erfolgen. Ein Beispiel für die Top-Down-Zerlegung, in der ungeordnete Datenelemente in einfachere Strukturen zerlegt werden, ist die von E.F. CODD begründete Normalformenlehre.254 Um die Normalformenlehre anwenden zu können, sind die Datenobjekte mit ihren Eigenschaften zunächst als sog. unnormalisierte Relationen darzustellen. Dabei sind im Rahmen des Formalisierungsprozesses (Bild 2-44) die beschriebenen Datenobjekte und ihre Eigenschaften in unnormalisierte Relationen zu überführen. Diese enthalten sowohl die Eigenschaften (Attribute) der Entities als auch Beziehungen zwischen einzelnen Attributen. Zur späteren Identifizierung der Tupel in den unnormalisierten Relationen sind ein Primärschlüssel und weitere Attribute als sog. Schlüsselkandidaten (= candidate keys) zu bestimmen.255 Bild 2-44 zeigt das Beispiel AUFTRAGSWESEN in Form unnormalisierter Relationen. Bedingt durch die implizit in den Relationen enthaltenen Beziehungen kommt es zu Redundanzen und sog. funktionalen Abhängigkeiten, die wiederum zu Speicheranomalien führen können.·256 Zur Beseitigung dieser Schwächen der unnormalisierten Relationen sind gewisse Gesetzmäßigkeiten, die unter dem Begriff Normalisierung oder Überführung in Normalformen zusammengefasst sind, zu beachten.257 In den Überlegungen zur Normalisierung werden Aussagen darüber getroffen, welche Attribute in einer Relation zusammengefasst werden sollen, ohne dass ein Informationsverlust eintritt. Unerwünschte Redundanzen von beliebigen Attributen werden dabei durch gezielte Redundanz von Schlüsseln ersetzt. Dazu müssen Relationship-Typen der Komplexität n:m als eigener Relationstyp definiert werden. Auch die l:n Beziehungen können nicht elementar behandelt werden; sie werden implizit dadurch dargestellt, dass der Schlüssel des »hierarchisch« übergeordneten Datenobjekt-Typs beim untergeordneten Datenobjekt-Typ als Sekundärattribut eingefügt wird.25Ä

254 255 250

257 258

Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 15. Vgl. ELMASRI, R.; NAVATHE, S.: Fundamentals of Database Systems, a.a.O., S. 144. Vgl. dazu u.a. BASTIAN, M.: Datenbanksysteme, a.a.O., S. 77; VETTER, Μ.: Aufbau, a.a.O., S. 115; VINEK, G.; RENNERT, P.F.; TJOA, Α.: Datenmodellierung, a.a.O., S. 80; WEDEKIND, H.: Datenbanksysteme I, 2., völlig neu bearbeitete Auflage, Mannheim/Wien/Zürich 1981, S. 200 f. Vgl. VETTER, M.: Aufbau, a.a.O., S. 115. Vgl. STUCKY, W.; KRIEGER, R.: Datenbanksysteme, a.a.O., S. 848.

2.4 Konstruktion und Modellierung eines Datensystems

103

VERKAUFSAUFTRAG + Auftragsnummer - Kundennummer - Kundenname - Kundenadresse - Kundentelefonnummer - Auftragsdatum * 50 Auftragspositionen - Auftragsmenge - Produktident - Produktname

KUNDE + Kundennummer - Kundenname - Kundenadresse - Kundenkategorie - Kategorierabatt - Vertriebsregion - Vertreternummer - Vertretername - Vertretertelefonnummer - Datum der Erstbestellung - Zahlungsmoral * 5 Umsatz - Jahr - Jahresumsatz

KUNDENRECHNUNG + Rechnungsnummer (+) Auftragsnummer - Rechnungsdatum - Kundennummer - Kundenname - Kundenadresse - Kundentelefonnummer * 50 Rechnungsposition - Auftragsmenge - Produktident - Produktname - Einzelpreis - Rabattbetrag - Verkaufspreis - Rechnungssumme - Sonderrabatt - Mehrwertsteuerbetrag - Rechnungsbetrag

PRODUKT + Produktident (+) Produktlinie) (+) Produktnummer) - Produktname - Einzelpreis - Bestand - Mindestbestand - Bestelldatum - Bestellmenge - Linienrabatt * 5 Lieferant - Lieferantenident

+ = Primärschlüssel (+) = Schlüsselkandidat ) = Zusammengesetzter Schüssel

LIEFERANT + Lieferantenident - Lieferantenname - Lieferantenadresse * η Lieferangebot - Produktident - Einkaufspreis - Lieferfrist

Bild 2-44: Auftragswesen: Formalisierte, unnormalisierte

Relationen

Ein solches (eingefügtes oder bereits vorhandenes) Attribut, bzw. eine Attributkombination einer Relation, das als gleiches Attribut bzw. als gleiche

104

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Attributkombination in einer anderen Relation als Primärschlüssel vorkommt, wird Fremdschlüssel (= foreign key) genannt und stellt eine referentielle Integritätsbedingung dar.259 Alle Beziehungen, die zwischen den Datenobjekten in unterschiedlichen Relationen vorkommen, werden im relationalen Datenbankmodell mit Hilfe des Primär-Fremdschlüssel-Prinzips abgebildet. Im Laufe des Normalisierungsprozesses steigt die Anzahl der Relationen, weil durch einen vorgenommenen Normalisierungsschritt eine komplexere Relation in mehrere einfachere mit je einer Beziehung aufgespalten wird. Ziele des Normalisierungsprozesses sind neben der - Elimination von Redundanzen, - die Vermeidung unerwünschter Abhängigkeiten im Zusammenhang mit Speicheroperationen wie Löschen, Ändern und Hinzufügen, - die ausschließliche Nutzung von einfachen Strukturen (Relationen) in der Datenbasis, - das »... eindeutige Festhalten realitätskonformer Sachverhalte...«200 als »... fundamentale Bedingung zur Erhaltung der Integrität...«267 der Datenbasis sowie - die Verringerung der Abhängigkeit der Relationen von Anfiragehäufigkeiten und -strukturen. E.F. CODD entwickelte hierzu - wie bereits erwähnt einen Normalisierungsprozess, der in Stufen abläuft, bis sich alle Relationen in der dritten Normalform (3.NF) befinden. Weitere Entwicklungen von Normalformen (z.B. BoYCECODD-Normalform, 4.NF, 5.NF, etc.) sind für die Mehrzahl der administrativ kaufmännischen Anwendungen von untergeordneter Bedeutung262 und werden hier nicht weiter verfolgt.265 Bild 2-45 gibt einen Überblick über die Normalformen.

259

Vgl. ELMASRI, R.; NAVATHE, S.: Fundamentals of Database Systems, a.a.O., S. 147. 260 y E T r E R ; M · Aufbau, a.a.O., S. 115. 261 y E T T E R > M.: Aufbau, a.a.O., S. 115. 262 Vgl. WEDEKIND, H.: Datenbanksysteme I, a.a.O., S. 201. 265 Der interessierte Leser sei auf die folgenden Literaturstellen verwiesen: KENT, W . : Α simple guide to five Normal Forms in Relational Database Theory, in: CACM: Vol. 26, 2/1983, S. 120-125; SMITH, H.C.: Database Design: Composing fully normalized tables from a rigorous Dependency Diagram, in: CACM: Vol. 28, 8/1985, S. 826-838; WEDEKIND, Η.: Datenbanken nach dem Relationenmodell, Beitrag zum Wirtschaftsinformatiksymposium 1974 der IBM Deutschland über Informationssysteme im Produktionsbereich vom 30.09.02.10.1974, S. 13 sowie BASTIAN, M.: Datenbanksysteme, a.a.O., S. 101.

2.4 Konstruktion und Modellierung eines Datensystems Unnormalisierte Form | 1. Normalform ι I 2. Normalform

105

Einführung von einfachen Wertemengen

Berücksichtigung funktionaler Abhängigkeiten (Einführung von Fremdschlüsseln) Vermeidung transitiver Abhängigkeiten

3. Normalform

Boyce-Codd-Normalform

4. Normalform

5. Normalform

Bild 2-45: Normalformen Die Erläuterung des Normalisierungsprozesses erfolgt anhand eines Ausschnitts aus dem »AUFTRAGSWESEN«. Die Formalisierung und Normalisierung der anderen Datenobjekte des Beispiels könnten Gegenstand von Übungsaufgaben und Praktika in entsprechenden Lehrveranstaltungen sein. Unnormalisierte Relationen können - wie Bild 2-46 zeigt - multiple Felder oder Periodengruppen beinhalten. 2.4.4.1.1 Herleitung der 1. Normalform Das Beispiel in Bild 2-46 zeigt, dass diese unnormalisierte Relation nur schwer zu handhaben ist, da sie einen hohen Grad an Redundanz aufweist. Jeder VERKAUFSAUFTRAG kann bis zu 50 AUFTRAGSPOSITIONEN mit den zugehörigen Elementen AUFTRAGSMENGE, PRODUKTIDENT und PRODUKTNAME enthalten. Die so definierte Periodengruppe AUFTRAGSPOSITION wird in der Normalformenlehre als Wiederholungsgruppe (= repeating group) bezeichnet.264 Die unnormalisierte Relation VERKAUFSAUFTRAG besitzt somit nichteinfache Attribut-Mengen, die 1 :n-Beziehungen innerhalb der Tabelle darstellen. 264

Vgl.

CODD, E.F.: Α

Relational Modell, a.a.O.,

S. 3 8 0

f.

106

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

> in

φ

__ Έ

γ ρ 8 = :0 £ 2£ ο •2> o"2 • ¥ >

fΟ Ο

I i ®s ωα

ο in o ο o ο ΙΟ CM τ-

ο W

ο ο in in σι ί-

< Ν Λ5 - a>

C \l ο ΙΟ

co coo
r2> P2>—> rx> Px

3. 4. 5. 6.

wobei Pj ein Zeiger auf einen direkten Nachfolger und η ein Referenzschlüssel zur Festlegung des Zugriffspfades auf die Blätter ist. Die Schlüssel in dem Teilbaum, auf den pj.j zeigt, sind kleiner η; diejenigen auf die pj zeigt, sind größer oder gleich η. Alle Wege von der Wurzel zu einem Blatt haben dieselbe Länge. Jeder Knoten mit Ausnahme der Wurzel und der Blätter hat wenigstens k+1 Söhne. Die Wurzel ist entweder ein Blattknoten oder hat wenigstens 2 Söhne. χ liegt in der Wurzel im Bereich zwischen 1 und 2k, in jedem anderen Knoten gilt: k < χ < 2k.325

50

19 /

10 15

23

\

19 20

\ •

•

•

... 80 Ν 100

• · •

50 74

23 30 t ^

•

t ^

•

•

80 90

100 120 t ^

Bild 2-76: B*-Baum

325

Vgl BAYER, R.; SCHKOLNICK, M.: Concurrency of Operations on B-Trees, in: Acta Informatica: Vol. 9/1978, S. 2 (1-21); WEDEKIND, H.: On the Selection of Access Paths in a Data Base System, in: KLIMBIE, J.W.; KOFFEMAN, K.L. (Hrsg.): Proc. IFIP Working Conf. on Data Base Management 1974, Amsterdam 1974, S. 388 if (385-397) und HÄRDER, Τ.: Implementierung von Datenbanksystemen, München/Wien 1978, S. 72.

148

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Beim Suchen in binären oder Vielwegbäumen wird das Suchprinzip durch Adressverweise abgebildet. Aufgrund der Struktur der Bäume setzt dies eindeutige Suchargumente voraus. Die Effizienz der Suchverfahren fordert die Ausgeglichenheit der Bäume. Bei häufigen Einfüge- und Löschoperationen im Baum bedeutet dies, dass in der Regel sehr zeitaufwendige Umstrukturierungen zur Erhaltung einer annähernd symmetrischen Verzweigung vorgenommen werden müssen.526 Die Diskussion der Güte der diversen, vorgestellten BaumKonzepte erfolgt im Rahmen der Behandlung von Dateiorganisationsformen.527 Beide Gruppen von Suchbäumen werden sowohl für Primär- als auch Sekundärdateien, z.B. bei den nachfolgend vorgestellten Indextechniken, eingesetzt. 2. Indextechniken Ein Index ist eine separate, sequenzielle Hilfsdatei, die für jeden Primärdatenbestand eingerichtet wird. Er besteht aus einer Reihe von Eintragungen; jede gehört zu einem Datensatz. Die Eintragungen setzen sich aus dem Wert eines Schlüsselattributes und einem Zeiger zusammen, der den sofortigen Zugriff zum betreffenden Datensatz erlaubt. Dabei ist vorauszusetzen, dass jeder Datensatz durch sein Schlüsselattribut eindeutig qualifiziert wird; Duplikate von Schlüsselattributen in einer Datei sind daher nicht zulässig. Eine solche Hilfsdatei zur Suche wird einstufiger Index genannt. 101

09

09

101

Bucher

102

17

10

106

Ommers

103

14

14

103

Ibssen

104

15

15

104

Montag

105

40

17

102

Limbach

106

10

38

107

Idfeld

107

38

40

105

Ormann

log. SNR

phys Adr.

/

/

V

\

phys. log. Adr. SNR

Mitarbeiterdatei

Bild 2-77: Einstufiger Index

326

Vgl. MICHELS, W.; STEINMETZ, G.; KAISER, W.: Datenbanken, a.a.O., S. 42.

327

Vgl. dazu Kapitel 2.2.4.

2.5 Physische Datenorganisation

149

Als Vorteile der Indextechniken sind zu nennen: - Bei Suchvorgängen ist es nicht notwendig, den gesamten Datenbestand zu durchsuchen. - Bei sehr großen Datenbeständen, die nicht in den Arbeitsspeicher passen, kann in vielen Fällen der Index im Hauptspeicher gehalten werden, so dass die Zahl der Zugriffe auf externe Speicher geringer wird. Falls man einen Index aufbaut, um über den Primärschlüssel auf eine Datei zuzugreifen, so spricht man von einem Haupt- oder Primärindex. Ein Index wird als Neben- oder Sekundärindex bezeichnet, wenn er sich auf ein Nebenordnungskriterium, das heißt einen Sekundärschlüssel, bezieht. 412 100 Kundenstammdatei

920 Hauptindex "KNR"

100

Meier

GÖ

611

Müller

KS

905

Otto

GÖ

605

Schulze

HH

"WOHNORT"

Bild 2-78: Haupt- und Nebenindex Man unterscheidet - wegen der Sortierung - vollständige und unvollständige Primärindizes. Ein Index ist dann vollständig, wenn zu jedem Schlüssel auch ein Eintrag vorhanden ist. Wird dagegen nur zu jeder Spur ein Wert im Index gehalten, z.B. nur der größte Schlüssel der Spur, so spricht man von einem unvollständigen Index. Ein Nebenindex muss, da die Datei bezüglich dieses Schlüssels unsortiert ist, stets vollständig sein. Da die Datei über den Nebenindex in einer neuen Ordnung erscheint, bezeichnet man sie als invertiert bezüglich dieses Nebenoder Sekundärindex.525 Die Organisation der Suche von Daten über derartige 328

Vgl.

SCHLAGETER, G.; STOCKY, W . :

Datenbanksysteme, a.a.O.,

S. 9 0 .

150

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Sekundärindizes oder Inverted Files heißt daher auch Inverted File Organisation. Bevor jedoch detailliert auf die Inverted File Organisation eingegangen wird, folgt zunächst die Vorstellung weiterer wesentlicher Indextechniken anhand des bereits bekannten Beispiels. a) Mehrstufiger Index Wird ein Index umfangmäßig zu groß, um ihn in den Arbeitsspeicher zu laden, so kann man für diesen Index, der stets geordnet ist, wiederum einen unvollständigen darüber liegenden Index (2. Indexstufe) aufbauen; insgesamt erhält man somit einen mehrstufigen Index.

b) Mehrfacher Index Bislang hatte jeder Satz im Index nur einen Adressverweis auf einen Datensatz, der im zugehörigen Block steht.529 Werden aber mehr als ein Adressverweis im Indexeintrag realisiert, so spricht man von einem mehrfachen Index. In diesem Fall speichert man z.B. die Kettenspur; dies ist eine Folge von Adressen der Sätze, die zu diesem Haussatz gehören, so dass eine Verkettung der Sätze entfallen kann.

329 Ygj

die Aussagen über einstufige Indizes.

2.5 Physische Datenorganisation

33

151 917 7 36

170

512 11

512

170 33 537

917

450

Mitarbeiterdatei

Bild 2-80: Mehrfacher Index Aus obiger Abbildung wird deutlich, dass die Stammdaten nicht mehr sortiert sein müssen. Nachteilig ist, dass die Sätze im Index im allgemeinen unterschiedliche Satzlängen besitzen. Diesen Nachteil kann man aber mit Zeigerlisten zum nächsten Indexeintrag umgehen. c) Mehrdimensionaler Index Werden in einem Index - außer den Kettenspuren für eine Datei - auch noch die Kettenspuren für den Zugriff auf andere Dateien eingetragen, so nennt man dies einen mehrdimensionalen Index. Dieser kann auch wieder ein einfacher oder mehrfacher Index sein. In unserem Beispiel Handelsbetrieb existieren unter anderem folgende Dateien: - Kunden (Stammdatei) - Mahnungen - Kundenrechnungskopf Auf alle drei Dateien erfolgt der Zugriff über den Schlüssel Kundennummer KNR. Ein Satz des Index könnte demnach folgendes Aussehen haben:

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

152

KNR 412

I

I

I

I

I

I

I

Adressver-

Kettenspur

Kettenspur

weis auf

der Datei

der Datei

Kunden

MAHNUNG

KUNDEN-

(stammdatei)

I

RECHNUNGSKOPF

Bild 2-81: Mehrdimensionaler Index Mit Hilfe eines Datensatzes im Index lässt sich so auf alle drei Dateien zugreifen. Laufen alle geplanten Zugriffe einer Datenbank über einen mehrdimensionalen Index, so wird dieser auch als Strukturdatei bezeichnet. d) Baumstrukturierte Indizes Ein Index lässt sich auch baumartig aufbauen. Es kann z.B. das sogenannte BBaum Konzept Anwendung finden. Dabei wird die Indexmenge in Seiten (pages) eingeteilt, die entweder im Arbeitsspeicher geladen, oder im Hintergrund, auf einem Massenspeicher ausgelagert sind. Ein Indexeintrag enthält einen Schlüsselwert s(i), einen Zeiger auf die nächste Hierarchiestufe des B-Baumes sowie einen Zeiger auf die Daten des Satzes mit Schlüssel s(i). 3. Invertierte Listen, Inverted-File-Konzept Im Gegensatz zur Primärindizierung ist für die Invertierung charakteristisch, dass für das Suchargument Duplikate zugelassen sind, das heißt das Suchargument muss einen Datensatz nicht eindeutig identifizieren. Bei der Invertierung wird zunächst für die als Suchargumente definierten Datenfelder einer Datei eine Hilfs- bzw. Sekundärdatei angelegt, die als Deskriptorenliste (Deskriptorwörterbuch) bezeichnet wird. Sie enthält genau einmal jedes in der Primärdatei vorkommende Attribut, nach dem eine invertierte Liste aufgebaut wird. Neben diesen Deskriptoren beinhaltet sie Adressverweise auf die zu jedem Deskriptor gehörenden Deskriptorwertlisten. Darin sind die verschiedenen Attributwerte des jeweiligen Deskriptors - in der Regel aufsteigend sortiert - sequenziell gespeichert. Dem einzelnen Attributwert folgt ein Feld, in dem die Anzahl der Datensätze, die diesen Wert in der Primärdatei haben, steht.

2.5 Physische Datenorganisation

153

Den Deskriptorwertlisten sind Trefferlisten zugeordnet, welche die logischen Adressen (Satznummern) der primären Datensätze beinhalten, die den zutreffenden Deskriptorwert aufweisen.550 Am Beispiel des Datenbanksystems ADABAS C der SOFTWARE AG, Darmstadt wird verdeutlicht, welche verschiedenen Deskriptortypen zum Aufbau von invertierten Listen herangezogen werden können. Falls ein normales Datenfeld, ein sogenanntes Elementarfeld invertiert wird, handelt es sich um einen Normaldeskriptor. Erfolgt die Invertierung nicht für das gesamte Feld, sondern nur über einen Teil davon, nennt man einen derartigen Deskriptor Subdeskriptor. In ADABAS C hat der Anwender weiterhin die Möglichkeit Super- und phonetische Deskriptoren anzulegen. Bei manchen Anwendungen ist es sinnvoll, einen Deskriptor anzulegen, der für das Suchen zusammengesetzter Begriffe, z.B. über mehrere Felder, Gültigkeit hat. Dazu werden jeweils einzelne Zeichen der festgelegten Felder zu einem Superdeskriptor zusammengefasst. Ein Superdeskriptor ist somit ein Matchcode, für den festzulegen ist, welche Teile aus welchen Datenfeldern diesen bilden sollen. Zur Behandlung gleichklingender Alpha-Bezeichnungen mit unterschiedlicher Sprechweise wird für das Speichern und Wiederfinden ein phonetischer Deskriptor verwendet, ohne dass der Anwender die exakte Schreibweise des Attributwertes kennen muss.557 ADABAS C (ab Version V) bietet zudem die Möglichkeit sogenannte Hyperdeskriptoren zu definieren. Ein Hyperdeskriptor ist ein benutzerdefinierter Algorithmus. Das Inverted-File-Konzept zeichnet sich durch folgende wesentliche Eigenschaften aus: 1. Die Deskriptoren- und die Deskriptorenwertliste können als mehrfacher Index mit ausgelagerten Kettenspuren angesehen werden. 2. Der Zugriffspfad (die Sekundärdaten), der dadurch realisiert wird, ist völlig getrennt von den Primärdaten.

330 331

Vgl. Software AG: ADABAS Einführung, ADA-410-000-D, Darmstadt 1983, S. 9 f. Mit Hilfe eines Phonetisierungsalgorithmus' werden die Alpha-Bezeichnungen vor der Invertierung in einen numerischen Schlüssel umgewandelt, der sodann invertiert wird. Da gleiche oder stark ähnlich klingende Alpha-Bezeichnungen in dem gleichen numerischen Schlüssel resultieren, findet man mit einer Anfrage unter Angabe irgendeiner Schreibweise alle gleich oder ähnlich klingenden Attributwerte. Vgl. Software AG: ADABAS Einführung, a.a.O., S. 12.

154

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

3. Durch die Trennung von Primär- und Sekundärdaten lassen sich Änderungen in den Zugriffsstrukturen durchführen, ohne die Sätze im Speicher umzuorganisieren. 4. Als Zeiger verwendet man im allgemeinen logische Adressen (etwa Satznummern oder Primärschlüssel), um so bei Änderungen der Speicherung auf der physischen Satzebene die invertierten Listen nicht ändern zu müssen. 5. Invertiert man eine Datei nach allen bei der Anfrage verwendeten Attributen, so kann allein durch Bearbeitung der invertierten Listen festgestellt werden, welche Sätze vom externen Speicher zu lesen sind.552 NORMAL-

SUB-

SUPER-

PHONETISCHER

DESKRIPTOR

DESKRIPTOR

DESKRIPTOR

DESKRIPTOR

(MATCHCODE) KUNDENNAME Albrecht [1] 5 Anders [1] 3 Braun [1] 13 Hinz [1] 9 Kunz [1] 10 KUNDENORT Bern [2] 7,9 Bonn [2] 3,11 Graz [1] 6 Hamm [2] 4,10

SUBNAME Alb [1] 5 And [1] 3 Bra [1] 13 Hin [1] 9 Kun [1]10

NAME ORT Albk [1] 5 Andb [1] 3 Brat [1] 13 Hinb [1] 9 Kunh [1] 10

1712 [1] 9 2035 [1] 17 3819|2] 3,21 4712 [1] 10

SUBORT Β [4] 3,7,9,11 G[1]6 Η [2] 4,10

Beispiele für Deskriptortypen

Bild 2-82: Deskriptoren in ADABAS C333

Um auf die Datensätze mit bestimmten logischen Satznummern zugreifen zu können, wird ein Index benötigt, der diese Satznummern in physische Adressen umsetzt.

332 VGL. NIEDEREICHHOLZ, J.: D a t e n b a n k s y s t e m e , a.a.O.; S. 8 5 - 9 1 . 333

Software AG: ADABAS Einführung, a.a.O., Bild 7, S. 11.

2.5 Physische Datenorganisation

155

2.5.4 Dateiorganisationsformen

Mit dem Begriff Dateiorganisationsformen werden die vielfaltigen Kombinationen von Speicherungsverfahren und Zugriffsmethoden bezeichnet. Grundsätzlich können die Dateiorganisationsformen als herstellerspezifisch angesehen werden, da bei der Speicherung einer Datei auf externen Speichern auch gerätespezifische Parameter zu berücksichtigen sind. In diesem Kapitel werden einige grundlegende herstellerunabhängige Standardformen zur Speicherung von Einzeldateien vorgestellt. Die Dateiorganisationsform wird in Abhängigkeit vom Speichermedium, den zukünftig zu erwartenden Veränderungen des Datenbestandes und der Zugriffsmethode gewählt. Auf die Darstellung der Dateiorganisationsformen im rechten Teil von Bild 2-83 wird verzichtet. 2.5.4.1 Dateiorganisationsformen ohne Sekundärdaten

Die in diesem Kapitel vorgestellten Formen der Dateiorganisation verzichten auf Suchhilfen, die nur über Hilfsdateien realisiert werden können. SAM-Dateien Die Abkürzung SAM steht für Sequential Access Method. Die Datensätze einer SAM-Datei werden also sequenziell gespeichert und sind nach dem Primärschlüssel sortiert. Einsetzbar sind sie für Anwendungen, die im Batch-Betrieb ablaufen; für den Online-Betrieb sind SAM-Dateien kaum sinnvoll einzusetzen, da aufgrund der sequenziellen Speicherung das Problem einer permanenten Verschiebung innerhalb der Datei beim Einfügen und Löschen von Datensätzen resultiert. Dieses Reorganisationsproblem kann zwar durch die zusätzliche Führung einer temporären Arbeitsdatei für neu einzufügende Datensätze abgeschwächt werden, die im Stapelbetrieb täglich mit der SAM-Datei gemischt wird. Der Nachteil der sequenziellen Suche bleibt jedoch bestehen, so dass für einen Dialogbetrieb mit häufigen Anfragen - wenn überhaupt - vom Umfang her nur sehr kleine SAM-Dateien in Frage kommen.554 DAM-Dateien DAM steht für Direct Access Method. DAM-Dateien basieren auf der direkten Adressierung, das heißt der Primärschlüssel und die logische Adresse sind identisch, bzw. sie müssen 1:1 transformiert werden.

334

Vgl. WIEDERHOLD, G.: File Organization, a.a.O., S. 118 ff.

156

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Bild 2-83: Dateiorganisationsformen - Überblick Der Zugriff auf einen Datensatz über den Primärschlüssel ist bei DAMDateien sehr schnell. Sequenzielle Suchverfahren sind hingegen einzusetzen, wenn über einen Sekundärschlüssel zugegriffen werden soll. Das Reorganisationsproblem tritt bei DAM-Dateien in der Regel nicht auf, da die logische Folge der Speicherung erhalten bleibt und ein einmal gespeicherter Datensatz seinen zugewiesenen Platz in der Datei beibehält.

2.5 Physische Datenorganisation

157

Diese Dateiorganisationsform ist für relativ statische Datenbestände, z.B. Personalstammdateien oder Kostenstellendateien, die keinen häufigen Veränderungen im einmal festgelegten Wertebereichii5 des Primärschlüssels unterliegen, sinnvoll einsetzbar. Kalkulierte Dateien Kalkulierte Dateien basieren auf der indirekten Adressierung. Da bei dieser Dateiorganisationsform der Speicherbereich für die Wahl des Hash-Codes von Bedeutung und daher von vornherein festzulegen ist, kann man in diesem Fall von einem statischen Verfahren der Dateiorganisation sprechen. Hat man bei kalkulierten Dateien das Problem der Mehrfachbelegungen durch eine geeignete Überlauforganisation im Griff, so entfallt eine häufige Reorganisation der Datei. Von Zeit zu Zeit sollte eine kalkulierte Datei jedoch trotzdem reorganisiert werden, da sich das Antwortzeitverhalten des Systems durch zu viele Überläufer verschlechtert. Das Löschen eines Datensatzes kann auf zwei Arten erfolgen: 1. Der Datensatz wird sofort physisch gelöscht. Dies kann unter Umständen mit Folgearbeiten wie Umketten von Sätzen in mehreren Ketten verbunden sein. 2. Ein zu löschender Datensatz wird zunächst nur logisch gelöscht, das heißt mit einer Löschmarke (flag) versehen. Die physische Löschung sowie die notwendige Änderung von Adressverweisen erfolgt erst im Rahmen der Reorganisation der Datei.530 2.5.4.2 Dateiorganisationsformen mit Sekundärdaten

Die folgenden Dateiorganisationsformen benutzen sekundäre Dateien als Suchhilfe. 1. ISAM-Dateien Ausgehend von der Organisation von Datenbeständen mittels SAM-Dateien kann das Problem des gezielten Einstiegs in die Datei sowie das Reorganisationsproblem beim Einfügen neuer Datensätze durch die Erweiterung der sequenziellen Primärdatei um zwei Komponenten, nämlich einen Index und einen Überlaufbereich, vermindert werden.

335

Vgl. MICHELS, W.; STEINMETZ, G.; KAISER, W.: Datenbanken, a.a.O., S. 48.

336

Vgl. NIEDEREICHHOLZ, J.: Datenbanksysteme, a.a.O., G.; KAISER, W.: Datenbanken, a.a.O., S. 48.

S. 5 9

sowie

MICHELS,

W.;

STEINMETZ,

158

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Eine derartige Dateiorganisation nennt man ISAM (Index Sequential Access Method) oder indexsequenzielle Speicherung. Der Zugriff auf einen bestimmten Datensatz erfolgt über den Index. In diesem können entweder alle Schlüssel verzeichnet sein, er kann aber als unvollständiger Index auch nur auf die Spur oder auf den Zylinder mit diesem Datensatz verweisen. Im zweiten Fall stehen die jeweils größten Schlüssel der Spuren bzw. Zylinder im Index.537 Aufbau der Indextabelle Höchste Satznummer in der Normalspur Normalspuradresse Höchste Satznummer im Überlaufbereich Spur-/Satzadresse im Überlaufbereich Bild 2-84: ISAM-Dateiorganisation:

Aufbau der Indextabelle

Häufig verwendet man einen mehrstufigen Index: Neben einem Hauptindex mit Verweisen auf die Zylinder legt man für jeden Zylinder und innerhalb des Zylinders für jede Spur Indizes an.338 Die Datensätze in einer ISAM-Datei sind fortlaufend auf- oder absteigend sortiert gespeichert. Beim Einfügen eines neuen Satzes in die Datei nach dem Urladen wird dieser im Überlaufbereich abgelegt und entsprechend dem ISAMKonzept mit dem Datenbereich verkettet, in den er ursprünglich gehört.3·39 Beim Löschen eines Satzes entsteht ebenso wie bei kalkulierten Dateien das Freispeicherproblem, welches im Rahmen der Reorganisation ähnlich einer garbage collection3''0 gelöst wird.

337

Vgl. NIEDEREICHHOLZ, J.: Datenbanksysteme, a.a.O., S. 54 ff. Vgl. HÄRDER, T.: Das Zugriffsverhalten von Relationalen Datenbanksystemen, Dannstadt 1975, S. 152 ff. 339 YGJ WEDEKIND, H.: Datenorganisation, a.a.O., S. 67 ff. 340 Vgl. WIEDERHOLD, G.: File Organization, a.a.O., S. 105. 338

2.5 Physische Datenorganisation

159 Spur 1

312

1

*

*

148

Radiowecker

210

Batterien 1,5 V

312

Digitaluhr

Spur 2 738

2

*

*

534

Kopfhörer

645

Videorecorder

738

Stereoanlage

Spur 3

Spur 4

ο CD m 7J c-n CO m 73 m ο I

Bild 2-85: ISAM-Dateiorganisation nach Urladen der Datei - Beispiel Produktdatei Zur Vermeidung einer frühzeitigen Reorganisation kann man beim Urladen der Datei alle Primärdatenblöcke bspw. nur zu 80% belegen. Die verbleibenden 20% Freispeicher werden genutzt, um nicht sofort eine Überlaufverkettung vornehmen zu müssen. Die Reorganisation von ISAM-Dateien erfolgt immer im Stapelbetrieb. Sie wird nötig, wenn der oder die Überlaufbereiche selbst fast überlaufen oder wenn durch logisches Löschen zu viele nicht mehr genutzte Plätze für Datensätze in der Datei existieren, so dass das Zugriffszeitverhalten sich drastisch verschlechtert.547

341

Vgl. MICHELS, W.; STEINMETZ, G.; KAISER, W.: Datenbanken, a.a.O., S. 50.

160

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Indextabelle nach d e m Einfügen der S ä t z e mit den Nummern 179, 2 9 1 , 3 7 9 und 5 5 5

210 1 312 3/3

555 2 738 4/1

148 179 210

Spur 1 Radiowecker Radiorecorder Batterien 1,5 V

Spur 2 377 Stereo-TV 534 Kopfhörer 555 Walkman

Spur 3 312 Digitaluhr 738 Stereoanlage 291 Taschenuhr Spur 4 645 Videorecorder

Bild 2-86:

ISAM-Dateiorganisation, Produktdatei

Situation nach Einfügen - Beispiel

2.5 Physische Datenorganisation

161

2. VSAM-Dateien Eine Weiterentwicklung der ISAM-Technik ist die ebenfalls indexsequenzielle Dateiorganisationsform VSAM aus dem Hause IBM.342 VSAM steht dabei für Virtual Storage Access Method. Die VSAM-Methode ist durch zwei Grundsätze gekennzeichnet: 1. Das Überlaufproblem wird nicht durch Kettung gelöst, sondern durch ein Splitten von Kontrollintervallen (Blöcken) verbessert. 2. Dies ermöglicht die sofortige Entfernung zu löschender Datensätze, da sie nicht mehr als Kettglieder für etwaige Überlaufsätze benötigt werden. Die dadurch entstehenden Lücken in der Datei werden zusammengeschoben und es existiert so ein kompakter Freibereich. Realisiert ist bei VSAM zum einen die sogenannte ESDS (Entry Sequenced Data Sets)-Organisationsform, mit serieller Speicherung der Sätze in den Kontrollintervallen, ohne Aufbau eines Index,544 und zum anderen die KSDS (Key Sequenced Data Sets)-Organisation. Von Bedeutung für die konventionelle Anwendung ist die KSDS-Organisation. Die Datensätze werden logisch nacheinander in den Kontrollintervallen, die darüber hinaus noch Verwaltungsinformationen beinhalten, gespeichert. Findet sich für einen neu einzufügenden Satz kein ausreichender Speicherplatz mehr im Kontrollintervall, so wird es in zwei neue gleichmäßig belegte Blöcke aufgeteilt. Dieses Blocksplitting findet während des Online-Verarbeitungsprozesses statt. Die zugehörigen Indextabellen werden dabei gleichzeitig aktualisiert.34·5 Durch die VSAM-KSDS Dateiorganisation entfallt die Notwendigkeit der periodischen Reorganisation der Datei, die als ein Nachteil von ISAM-Dateien zu nennen ist. Allerdings ist zu bemerken, dass aufgrund eines im Rahmen von Update-Operationen notwendigen Teilungsprozesses eines Kontrollintervalls VSAM-KSDS langsamer als die ISAM-Technik sein kann. Als Vorteil von VSAM ist aber die Möglichkeit des Anlegens von Sekundärindizes für beliebige Datenfelder zu sehen.

342

VSAM löste bei IBM/370-Anlagen die ISAM-Technik der IBM/360-Anlagen ab. Vgl. NIEDEREICHHOLZ, J.: Datenbanksysteme, a.a.O., S. 64. 343 Vgl. NIEDEREICHHOLZ, J.: Datenbanksysteme, a.a.O., S. 64. 344 ESDS organisierte VSAM-Dateien eignen sich besonders für die Erstellung von Log-Files. Vgl. NIEDEREICHHOLZ, J.: Datenbanksysteme, a.a.O., S. 67. 345

V g l . MICHELS, W . ; STEINMETZ, G.; KAISER, W . : D a t e n b a n k e n , a.a.O., S. 5 1 u n d NIEDER-

EICHHOLZ, J.: Datenbanksysteme, a.a.O., S. 65 f.

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

162

-vi ω 00

"Π

I ω oo

sOl

ΟΙ

5 ' CD Q. CD S CD * 5' 3" c/>

ωk ΙΟ

"Π

ω ιο

ιο

*

13 =J α. sr α> ® χ 5 0)

Ol 00

1m

ζ CO Ν m

->l ->l ο

οι ϊ οι οι ΟΙ

--J οΝ)

Ο) Ν)

ω oo

2Οι

8 00

(Ο Οι

κ

73

m CD m 7J m Ο I

Ν) ΟΙ

(Ο σ>

ο Κ) (Ο ω 2 ω ιο

ro ο Ν) ιο Ο) ιο * τ; ο 3 3ι »— CD

ω s

§

0) ω ro

Ο — ζ J . Developing a Data Dictionary System, Englewood Cliffs 1982, S. 26 f.

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

243

a) Informations- und DV-Management Der Unternehmenserfolg hängt in großem Maß von einem effektiven Management ab, welches unter anderem durch den Wert der vorhandenen Datenbestände als Unternehmensressource begründet wird.·567 Informationen aus dem Data Dictionary bilden die Grundlage für die Planung, Organisation und andere Entscheidungsprozesse.562 Das Informationsmanagement kann bspw. aus dem Inhalt des Data Dictionary detaillierte Berichte über das Zusammenwirken von Daten und Programmen sowie über die Auswirkungen von Datendefinitionsänderungen erhalten.505 Anhand einer Dokumentation der eingesetzten Hard- und Software ließe sich auch eine Kosten-Nutzen- oder Bedarfsanalyse erstellen.·554 b) Revision Ein System für die Revision eines Unternehmens muss in erster Linie effektiv, verlässlich und zeitsparend konstruiert sein. Die Möglichkeit der On-LineAbfrage in einem Data Dictionary als zentrales Medium jeglicher Unternehmensinformation stellt ein schnelles und effektives Werkzeug dar, um alle erforderlichen Unternehmensaktivitäten zu verfolgen und zu prüfen.·565 Die Revisions-Abteilung kann mittels des Data Dictionary bspw. die Datenbeschreibungen untersuchen, die in den Anwendungsprogrammen des Rechnungswesens Verwendung finden.566 c) Daten(bank)administration Die Daten(bank)administration benutzt das Data Dictionary als »... Verzeichnis der Dateien und Datenfelder des Systems mit Angaben über Herkunft und Verwendung der Daten...«567, um mit diesen Informationen Datenbanken neu zu entwerfen, diese zu kontrollieren und ggf. den Benutzeranforderungen gemäß umzugestalten.565 Ihr obliegt damit auch die Aufgabe, die Datendefinitionen und ihren Gebrauch in allen Applikationen zu kontrollieren, um die Konsistenz des Datenbestandes zu gewährleisten. Das Data Dictionary kann den Datenbankad561

Vgl. VANDUYN, J.: Developing, a.a.O., S. 26 f.

562 Vgl. HEINRICH, L.J.; BURGHOLZER, P.: I n f o r m a t i o n s m a n a g e m e n t , a.a.O., S. 306.

563 YGJ LOOMIS, Μ.; MANNINO, M.; ALLEN, F.: Fundamentals of Integrated Dictionary/Directory

Systems, in: Information & Management·. 12/1981, S. 289 (287-295). 564 565 566

Vgl. GIRNDT, D.: Data Dictionary, a.a.O., S. 140. Vgl. VANDUYN, J.: Developing, a.a.O., S. 27. Vgl. LOOMIS, M.; MANNINO, M.; ALLEN, F.: Fundamentals, a.a.O., S. 289.

567

REUSCH, P.J.A.: Informationssysteme, a.a.O., S. 170.

568

Vgl. LOOMIS, M.; MANNINO, M.; ALLEN, F.: Fundamentals, a.a.O., S. 289.

244

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

ministrator durch das detaillierte Anzeigen von durchgeführten und vorgeschlagenen Änderungsdiensten unterstützen und somit bestehende Inkonsistenzen aufdecken.509 Auch im Bereich der Datensicherheit stellt ein Dictionary - z.B. bei der Gewährung und Kontrolle von Zugriffsrechten - eine wichtige Hilfe dar. d) Systemanalyse und Systementwicklung Die Aufgaben der Systemanalyse und Systementwicklung können in allen Phasen des Entwicklungsprozesses unterstützt werden. Zu nennen sind u.a. folgende Aufgaben: -

Hilfestellung bei der Dokumentation Designhilfe Generierung von Meta-Daten Aufbau von Spezifikationsdaten Erleichterung der Testläufe Vollständigkeits- und Integritätskontrollen.

Im Rahmen der Informationsbedarfsanalyse gibt das Data Dictionary den Entwicklern einen Überblick über bereits vorhandene Daten und Programme, die sie in das neue System integrieren können. Auf diese Art und Weise werden ungewollte Redundanzen vermieden. Auch können die Ergebnisse der Datenanalyse, die eine Grundlage für den Normalisierungsprozess bilden, im Data Dictionary abgelegt werden, um im logischen Design der Anwendungen daraus Benutzersichten zu erstellen.570 Weitere Erleichterungen seitens des Data Dictionaries bestehen in der Realisierungsphase eines Anwendungssystems durch verschiedene Möglichkeiten der Dokumentation. Des weiteren kann auf der Basis des Data Dictionary eine Analyse von Systemänderungen durchgeführt werden und letztlich fungiert es bei der Aufnahme neuer Datenbestände als Kontrollinstrument577 e) Programmierung Die Programmierung verwendet das Data Dictionary zur Ableitung der Datendefinitionen für Anwendungsprogramme.572 Durch die Generierungsmöglichkeiten von Datenstrukturen, Prüfbedingungen und Testdaten, die Fehlerfreiheit gewährleisten, sowie durch die Hilfe bei 569

Vgl. VAN DUYN, J.: Developing, a.a.O., S.27 ff. Vgl. GIRNDT, D.: Data Dictionary, a.a.O., S. 141. 57/ Vgl. REUSCH, P.J.Α.: Informationssysteme, a.a.O., S. 170 und LOOMIS, Μ.; MANNINO, M.; ALLEN, F.: Fundamentals, a.a.O., S. 289. 572 Vgl. REUSCH, P.J.A.: Informationssysteme, a.a.O., S. 170. 570

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

245

der Dokumentation und Erstellung von Reports kann sich die Programmierung auf die problemorientierte Verarbeitungslogik konzentrieren. Auch der Wartungsaufwand für die erstellten Anwendungssysteme wird durch ein Data Dictionary erheblich reduziert, weil Änderungsdienste im Datendefinitionsbereich exakt abgegrenzt und automatisch ausgeführt werden können.575 f) Arbeitsvorbereitung und Maschinenbedienung Die Arbeitsvorbereitung hat die Aufgabe, Anwendungen (Jobs) vorzubereiten, zu überwachen und zu steuern. Das Data Dictionary verfügt über Informationen bzgl. der Daten, Dateien und Jobs sowie über Beziehungen zwischen Programmen und Datenstrukturen, aus denen der Operator Pläne zur Jobablaufsteuerung erstellt.·574 Im Fall eines Programmabbruchs können die im Data Dictionary dokumentierten Wiederanlaufanweisungen helfen, die Verarbeitung ordnungsgemäß zu beenden. Bei Systemumstellungen dient es dazu, die betroffenen Elemente des Informationssystems ausfindig zu machen.57·5 g) betrieblicher Datenschutzbeauftragter Für den betrieblichen Datenschutzbeauftragten fungiert das Data Dictionary als Überwachungsinstrument. Er kann damit feststellen, wer auf welche Daten welche Zugriffsmöglichkeiten besitzt und davon Gebrauch macht.570 h) Endbenutzer, wie z.B. Executives, Knowledge und Case Worker Durch die zunehmende Verlagerung der EDV in die Fachbereiche ändert sich auch die Verantwortlichkeit für die korrekte Verarbeitung der Daten. Ein Data Dictionary verschafft ihnen eine größere Sicherheit bzgl. der Nutzung der verfügbaren Daten, indem sie ihren Informationsbedarf mit geeigneten Abfragen decken, sich verschiedene Anwendungssichten der Daten zusammenstellen und neue benutzerspezifizierte Elemente definieren können. Endbenutzer besitzen allerdings keine bzw. nur eingeschränkte Rechte, die anderen Inhalte des Data Dictionary zu erweitern oder zu modifizieren.577 573 YGJ CONRAD, G . : Data Dictionary, Integrationsbasis für Datenstrukturen und Programmgene-

574

575 576

577

ratoren, in: NIEDEREICHHOLZ, J. (Hrsg.): Datenbanktechnologie: Einsatz großer, verteilter und intelligenter Datenbanken, Stuttgart 1979, S. 50 ff. (43-61). Vgl. GIRNDT, D.: Data Dictionary, a.a.O., S. 1 4 0 und V A N D U Y N , J.: Developing, a.a.O., S. 32 ff. Vgl. GIRNDT, D.: Data Dictionary, a.a.O., S. 140. Vgl. MALINOWSKI, K . : Data Dictionary - Derzeitige Möglichkeiten und Entwicklungstendenzen, in: Datascope: 32/1980, S. 45 (43-50). Vgl. LOOMIS, Μ . ; ΜΑΝΝΙΝΟ, M . ; ALLEN, F.: Fundamentals, a.a.O., S . 2 8 9 und MALINOWSKI, K . : Data Dictionary, a.a.O., S . 4 5 .

246

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Um den genannten Bedürfnissen der verschiedenen Benutzer und Benutzergruppen gerecht zu werden, muss ein Data Dictionary folgende Anforderungen erfüllen: 1. Es muss eine vollständige Darstellung aller Objekte, die das Datenmanagement fur die Datenverwaltung eines Unternehmens benötigt, beinhalten. Dahinter steht die Forderung nach Vollständigkeit und ausreichender Beschreibungsmöglichkeit hinsichtlich a) der Erfassung aller Daten- und Informationsobjekte, b) des Aufbaus aller Datenobjekte (Definitionen), c) der Speicherung aller Datenobjekte (Directory Funktion) sowie d) der logischen Beziehungen und der Abhängigkeiten zwischen den Datenobjekten und damit ihrer Herkunft und Verwendung.575 2. Die Integrität und die Redundanzfreiheit des Inhaltes eines Data Dictionaries muss gewährleistet sein.579 Die Forderung nach ausreichender Beschreibungsmöglichkeit erfordert die »Ausdehnbarkeit« des Data Dictionaries. Nach C. SEAGREN und J. EVERETT muss der Benutzer eigene Objekttypen, Eigenschaften von Objekten sowie Beziehungen zwischen Objekten definieren können.550 2.8.2.2.2 Komponenten und Funktionalität eines Data Dictionary Systems

Bei der Betrachtung eines Data Dictionary Systems (DDS) sind folgende Aspekte von Bedeutung. Es ist zu klären, -

aus welchen Komponenten ein DDS besteht und welche Inhalte diese im Einzelnen enthalten, - welche Grundfunktionen zur Verarbeitung der Inhalte benötigt werden, - welche Schnittstellen einem DDS zu welchen anderen Tools zur Verfügung stehen sollten. Ein DDS besteht aus folgenden Komponenten:

575

579 580

Vgl. REUSCH, P.J.Α.: Informationssysteme, a.a.O., S. 171 und LOOMIS, M.; MANNINO, M.; ALLEN, F.: Fundamentals, a.a.O., S. 289. Vgl. REUSCH, P.J.Α.: Informationssysteme, a.a.O., S. 171. Vgl. SEAGREN, C.; EVERETT, J.: Report gives Guidelines toward Defining a DDS, in: Computerworld: 26/1982, S. SRI 8 (SR18/SR20).

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

247

I. Meta-Datenbank Entsprechend dem Zweck des Data Dictionary, Auskunft über Daten, Prozesse und die Umgebung des betrieblichen Informationssystems zu geben, müssen die Zusammenhänge zwischen diesen Objekten in Form von Meta-Informationen dargestellt werden. Dazu wird eine gesonderte Datenbank, die Meta-Datenbank oder Metabank, eingerichtet. Die Meta-Datenbank ist auf die Systemdokumentation und -Verarbeitung ausgerichtet und enthält das eigentliche Data Dictionary. Da hier die Spezifikationsdaten der Anwendungssysteme zu finden sind,557 erteilt die Metabank im Sinne einer Systembank Auskunft über die Struktur und die Verwendung der Daten, die von den Anwendungsdatenbanken verwaltet werden. Anfänglich wurden Systeme mit vordefinierten, festen Strukturen entwickelt. Erst seit Ende der siebziger Jahre ist es möglich, die Metadaten selbst variabel zu beschreiben (Meta-Meta-Daten), um daraus die gewünschten Strukturen (Meta-Beziehungen) generieren zu können. Die gesamte Informationsstruktur eines Unternehmens sollte bekanntlich mit Hilfe eines ER-Modells beschrieben werden. Im Data Dictionary sind nun Informationen über dieses ER-Modell in der Metadatenbank gespeichert. Auf diese Art und Weise entstehen Meta-Entitäten, die, in logische Klassen eingeteilt, jeweils unterschiedliche Objekte enthalten können, von denen hier die gebräuchlichsten aufgelistet werden:552 - Daten-Entitäten: Element, Datenstruktur, Datensatz, Datei, Datenbank, Report - Prozess-Entitäten: Modul, Programm, System, Transaktion - Umgebungs-Entitäten: Benutzer, Kommunikationsleitungen, Terminals, sonstige Hardware-Komponenten - Ausweitungs-Entitäten: Benutzerdefinierte Entitäten Die Charakteristika und die logischen Zugehörigkeiten dieser Meta-Entitäten werden durch Attribute näher beschrieben. Dabei unterscheidet man üblicherweise: -

Identifikations-Attribute Hierzu zählen der Name im DDS; Synonyme, d.h., Benutzerdefinierte Stellvertreter-Namen, Alias-Namen zur eindeutigen systemorientierten Identifikation sowie verwendete Alternativnamen, der Programmierspra-

581

Vgl. REUSCH, P.J.A.: Aufbau, a.a.O., S. 7-3. Vgl. LEONG-HONG, B.W.; PLAGMANN, B.K.: Data Dictionary, a.a.O., S. 66 ff. und S. 77 ff.

582

248

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

chen-Name und eine Beschreibung hinsichtlich der Verwendung und Charakteristik der Entität. -

Repräsentationsattribute Repräsentationsattribute beziehen sich auf den Typ des Datenelements, seine Länge, die Quelle und Verwendung eines Elements, die verwendete Programmiersprache, die Programmgröße in Lines of Code, den Prozesstyp (Batch- oder Online-Programm) sowie die Anzahl und die Typen der im Programm verwendeten Parameter.

-

Beziehungsattribute Folgende Beziehungsattribute sind möglich: - Keyword: Beschreibt und identifiziert zwei oder mehrere Meta-Entitäten für eine Analyse oder einen Report. - Link: Gibt den Verbindungspfad zwischen zwei Meta-Entitäten auf der Ebene der System-Architektur an. - Usage: Beschreibt, wie eine Entität von einer anderen verwendet wird. - Calls: Bezeichnet Unter- oder Dienstprogramme, die ein Programm aufruft - Zugriffspfad: Pfad zum Auffinden von Datenstrukturen zwischen MetaEntitäten - Set: Relation zwischen zwei Datensätzen (CODASYL-Ausdruck) - Mapping: Relation zwischen einer Daten- und einer Prozess-Entität

-

Statistische Attribute Folgende statistischen Informationen sollten gespeichert werden: - Durchschnittliche Zugriffshäufigkeit auf eine Entität - Antwortzeit der Prozess-Entität - Statistik über das Datum, den Benutzer und die ausgeführten Operationen bei Zugriff auf eine Entität (Log Information) - Statistik über die Verwendung von Daten - Statistik bzgl. der Performance einer Prozess-Entität - Geschätzte Lebensdauer einer Entität, d.h. Stabilität und Häufigkeit der Änderung - Kontroll-Attribute - Autorität: Operationen, die ein Benutzer ausführen darf - Passwort: Passwortcode in Verbindung mit der Autorität eines Benutzers - Zugehörigkeit: Ausschließliche Verwendung einer Entität von einem bestimmtem Benutzer - Status: Operationaler Zustand einer Entität: Test, Produktion oder Archiv

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

249

- Version: Zugehörigkeit einer Entität zu einer bestimmten Version - Sicherheits-Level: Verwendung einer Entität wird für Benutzer mit zu geringer Autorität ausgeschlossen - Datenfluss: Herkunft und Ziel einer Entität, z.B. bestimmte Programme oder Dateien - Ausgabeformat und Plausibilitätsprüfungen: Gültige Wertebereiche und Darstellungsformen einer Entität - Physische Attribute - Speichermedium: Information über die Speicherungsform von Entitäten - Speicherbedarf: Speicherbedarf für Daten-, System- oder ProzessEntitäten - CPU: Name und Größe des Zentralprozessors, den die Prozess-Entität verlangt - Terminals: Art des Terminals, das die Prozess-Entität verlangt - Betriebssystem: Version und Level des Betriebssystems, das die ProzessEntität verlangt - Benutzerdefinierte Attribute II. Programm- und Methodenbank Die Programm- und Methodenbank des Data Dictionaries beschreibt die Verarbeitungskomponente des Meta-Informationssystems. Um die Programme mit ihren Zugriffspfaden zu beschreiben, beinhaltet diese Komponente die erforderlichen Spezifikations- und Dokumentationsroutinen der Anwendungssysteme.·55·5 Zugleich wird festgelegt, welche Daten von den einzelnen Anwendungsprogrammen verarbeitet werden und ob ggf. Einschränkungen bei der Verarbeitung bestehen. Die Programm- und Methodenbank ermöglicht, insbesondere in Verbindung mit der Metabank, eine konzentrierte Bearbeitung, bei der Redundanzen, Homonyme sowie nicht konsistente Daten vermieden werden. III. Data Dictionary-Umgebung Die dritte Komponente eines DDS enthält Informationen über die interne und die externe Umgebung des Systems. Die interne Umgebung beschreibt das gesamte Informationssystem mit seinen Elementen einschließlich des Rechnersystems sowie der Eingabe- und

583

Vgl. REUSCH, P.J.A.: Aufbau, a.a.O., S. 7-4.

250

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Ausgabemedien. Dazu gehört auch die Darstellung, welche Betriebs- und DCSysteme unterstützt werden.554 Im DDS sind den Programmen aus technischen Gründen nur logische Dateinamen zugänglich, d.h., nur über die logischen Dateinamen können die physischen Dateien und damit die Ausgabemedien wie Magnetspeicher, -bänder oder etwa Listen von den Programmen erreicht werden.555 Daher werden auch diese Elemente in der internen Darstellung der Umgebung des Data Dictionary Systems abgebildet. Neben der Aufzeichnung der internen Umgebung enthält das Data Dictionary System auch Hinweise zur externen Umgebung des Systems. Als extern werden bspw. die Zugriffslegitimationen der Benutzer des Systems angesehen. Die Darstellung der gesamten Umgebung des Data Dictionary dient zusammen mit den Beschreibungen der Zugriffspfade in der Programm- und Methodenbank dem Schutz vor unautorisiertem Zugriff. IV. Data Directory Das Data Directory als vierte Komponente eines DDS gibt Auskunft über die physische Lage der gespeicherten Dateien und über mögliche Zugriffsformen. Häufig werden im Directory nur wenige Elementtypen, wie Datenfelder, Datensätze und Datenbanksegmente, aber auch Dateien und Datenbanken beschrieben.556 Das Data Directory ermöglicht die (aktive) Spezifikation und Steuerung durch das Metasystem; ohne das Data Directory verbleibt dem Data Dictionary System die (mehr passive) Dokumentationskomponente.557 Die nachfolgend aufgeführten Funktionen werden nicht von allen DDS im gleichen Umfang angeboten: 1. Datendefinitions- und -verwaltungsfunktion Diese Funktion übernimmt die Zuordnung von Objekten, Attributen und Beziehungen innerhalb der standardmäßigen Subkategorien sowie das Ändern und Löschen von Objekten, Attributen und Beziehungen innerhalb derselben.555 2. Erweiterungsfunktion Mit Hilfe der Erweiterungsfunktion wird das Definieren von benutzereigenen Subkategorien, Objekten, Attributen und Beziehungen möglich.559 584 555 556 557 555

Vgl. Vgl. Vgl. Vgl.

REUSCH, P.J.A.: Aufbau, a.a.O., S. 7-17. GLRNDT, D.: Data Dictionary, a.a.O.,S. 129 f. GIRNDT, D.: Data Dictionary, a.a.O., S. 125 ff. REUSCH, P.J.A.: Aufbau, a.a.O., S. 7-24.

Vgl. SOKOLOVSKY, Z.: Bemerkungen, a.a.O., S. 125.

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

251

3. Datendeklarations-/-generierungsfunktion Damit lassen sich Datendeklarationen, Datenbankstrukturen und Anwenderprogrammtabellen für Quellen-Anwendungsprogramme automatisch generieren. Die Angaben dazu werden den Entity-Strukturbeschreibungen entnommen und in entsprechenden Bibliotheken oder Dateien gespeichert. Dadurch wird gewährleistet, dass Änderungen der Entity- und Relationship-Definitionen in allen Bereichen des Meta-Informationssystems durchgeführt werden.590 4. Datenauswertungs- und Berichtsfunktion Die Datenauswertungs- und Berichtsfunktion eines Data Dictionary ist generell in der Lage, beliebige, gegebenenfalls selektierte Datenbeschreibungen zu visualisieren, d.h. Entity-Kataloge auszugeben.597 Häufig werden die Auswertungsmöglichkeiten eines Data Dictionaries mit Stücklistenauflösungen und Verwendungsnachweisen verglichen, da man damit erfahren kann, in welcher Weise ein Entity einem anderen über- oder untergeordnet ist (z.B. als Eingabedatei, Call-Aufruf, Sortierfeld u.a.).592 Sowohl die Auflösung (Explosion) als auch der Verwendungsnachweis (Implosion) kann ein- oder mehrstufig erfolgen.595 Mit Hilfe der Verwendungsnachweise lassen sich bspw. diejenigen Entities ermitteln, die von der Änderung eines untergeordneten Objektes betroffen sind. Zu den Verwendungsnachweisen gehören weiterhin Security-Nachweise, z.B. Manipulationsversuche der Sicherheitsvorkehrungen, sowie Statistiken über die Häufigkeit der Verwendung von gespeicherten Informationen, Kontrolllisten usw.594 5. Versionsverwaltungsfunktion Die Versionsverwaltungsfunktion eines DDS ermöglicht es, Entity-Strukturen verschiedener Entwicklungsstadien zu verwalten. Die Versionen eines Objektes können folgende Ausprägungen besitzen:595 a) NEW

589 YGJ LOOMIS, Μ . ; ΜΑΝΝΙΝΟ, M . ; ALLEN, F.: Fundamentals, a.a.O., S . 2 9 1 . 590

391 592 593 594 595

Vgl. SOKOLOVSKY, Z.: Funktionsmächtigkeit künftiger Data-Dictionary-Systeme, in: AI: 7/1981, S. 286 f. (286-291). Vgl. SOKOLOVSKY, Z . : Funktionsmächtigkeit, a.a.O., S. 2 8 9 , S . 2 9 1 . Vgl. STÜLPNAGEL, A. von: Data Dictionary, in: HMD: 118/1984, S. 60 (59-70). Vgl. VETTER, M.: Aufbau, a.a.O., S. 356 f. Vgl. SOKOLOVSKY, Z . : Funktionsmächtigkeit, a.a.O., S. 2 8 9 . Vgl. SEAGREN, C . ; EVERETT, J.: Report gives Guidelines toward Defining a DDS, a.a.O., S. SRI 8.

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

252

Diesen Status erhalten alle Objekte, die neu in das Data Dictionary aufgenommen werden, noch nicht komplett sind und daher nur für die Datendefinitions- und -Verwaltungsfunktion von Interesse sind. b) TEST Die Objekte dieses Status sind vollständig definiert aber lediglich für den nicht-produktiven Gebrauch geeignet, d.h. sie können auf ihre Eignung getestet werden. Möglicherweise existieren auch verschiedene Testversionen eines Objektes. c) PRODUCTION Objekte mit diesem Status sind formal einwandfrei, d.h. sie sind komplett definiert, getestet und stehen dem Endbenutzer zur Verfügung. Es existiert immer nur eine Produktionsversion eines Objektes. d) ARCHIVE Alle »alten« Test- und Produktionsversionen eines Objektes werden unter diesem Status abgelegt. Falls mehrere Archiv-Versionen vorhanden sind, werden sie durch eine Level-Nummer identifiziert. 6. Nachdokumentationsfunktion Die Nachdokumentationsfunktion dient dazu, Datenbeschreibungen und weitere erforderliche Informationen aus bestehenden Anwendungsprogrammen und Datenbanken automatisch zu erstellen und in die jeweilige Data-DictionarySyntax umzusetzen.·590 7. Zugriffsverwaltungsfunktion Mittels dieser Funktion wird überprüft, ob ein Benutzer berechtigt ist, Daten des DDS zu ändern, zu lesen oder neue Daten einzufügen.597 Der Anwender wird dabei als Entity-Typ DDS-Benutzer definiert. Die Autorisierung ist pyramidenförmig aufgebaut, wobei dem Administrator als höchste Instanz des Systems die umfassendste Zugriffsberechtigung zukommt. Die Zugriffsberechtigung der Anwender für eine Hierarchieebene schließt die für die jeweils niedrigeren Ebenen ein. Mit dieser Funktion lassen sich gleichzeitig statistische Angaben über den Zugriff auf die Datenbestände sammeln, um gegebenenfalls ein notwendiges Tuning des Systems vornehmen zu können.595 596

Vgl.

SOKOLOVSKY,

Z.:

Funktionsmächtigkeit,

a.a.O.,

S. 288

sowie

MANNINO, M.; ALLEN, F.: Fundamentals, a.a.O., S. 290. 597 598

Vgl. STATE OF THE ART REPORT: Data Base, Series 9, No. 8, 1981, Vgl. SOKOLOVSKY, Z.: Funktionsmächtigkeit, a.a.O., S. 288.

S.

173.

LOOMIS,

M.;

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

253

8. Datenprüf- oder Plausibilitätspriifungsfunktion Durch die Prüfattribute der Objekte kann die Plausibilität von Daten überprüft werden. Die Prüfkriterien können als ein fester Bestandteil der Programme generiert werden, oder sie werden dem Programm bei der Ausführung interaktiv zur Verfügung gestellt. Im ersten Fall ist eine automatische Anpassung von Änderungen der Strukturbeschreibungen und Prüfbedingungen möglich, im zweiten Fall kann der Änderungsdienst entfallen. Die Anpassung wird dann automatisch mit einem Listengenerator dynamisch in einem interaktiven Prozess durchgeführt.599 Die Festlegung von Standards, insbesondere von Namenskonventionen kann Redundanzen und Dateninkonsistenzen auffangen, bevor sie in die Datenbank gelangen, und die Kommunikation zwischen den Benutzern fordern. Zudem gewährleisten Standards für alle Benutzer einen klaren eindeutigen Datenbestand und werden somit zu einer mächtigen Produktivitätstechnik.000 Zur Erfüllung seiner Aufgaben muss ein DDS auch Verbindungen zu anderen Softwarepaketen wie dem DBMS, verfügbaren Compilern, TP-Monitoren, Report-Writern oder Query Language Prozessoren (QLP) aufnehmen können. Grundsätzlich sind dabei die statische und die dynamische Verbindung zu unterscheiden: 1. Statische Verbindung Falls ein Anwendungsprogramm indirekt über die Existenz von intermediate files007 mit dem DDS verbunden wird, nennt man diese Verbindung statisch. Über einen DD-Generator, der die Funktion hat, Daten- und DB-Strukturen, Testdaten, Routinen, Module und Programme zu generieren,602 werden die Ergebnisse (= Definitionen) abgelegt. Zur Ausführungszeit nutzt das Anwendungsprogramm nicht das DDS, sondern die entsprechenden intermediate files. Bei einer Änderung der Datendefinitionen im DDS müssen dieselben Änderungen auch in den intermediate files vorgenommen werden (=> statische Verbindung).

599 600

601 602

Vgl. SOKOLOVSKY, Z.: Funktionsmächtigkeit, a.a.O., S. 289 ff. Vgl. BRATHWAITE, K.S.: Analysis, a.a.O., S. 28 f. sowie WERTZ, C.J.: The Data Dictionary Concepts and Uses, Wellesley, Massachusetts 1986, S. 274 f. Vgl. GRADWELL, D.J.: Integrating, a.a.O., S. 450. Vgl. SOKOLOVSKY, Z.: Bemerkungen, a.a.O., S. 126 f.

254

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Nachteilig wirkt sich bei statischen Verbindungen aus, dass ein Benutzer nicht nur das Konzept des DDS, sondern auch das der verbundenen Software, z.B. des Betriebssystems oder des DBMS, kennen muss.003 2. Dynamische Verbindung Bei einer dynamischen Verbindung haben Softwarepakete während ihrer Ausführungszeit direkten Zugriff auf das DDS, indem sie die standardmäßigen DDS-Funktionen über sog. Schnittstellen-Kommandos aufrufen. Da die Änderungen der DD-Definitionen bei der nächsten Ausführung eines Programms automatisch mit berücksichtigt werden, nennt man diese Verbindung dynamisch. Ein weiterer Gegensatz zur statischen Verbindung besteht darin, dass die Softwarepakete nicht nur direkt die DD-Inhalte abrufen, sondern diese auch modifizieren können. Nachteilig an dieser Verbindung ist, dass es aufgrund der dauernd geforderten Zugriffsverwaltungs- und Plausibilitätsprüfungsfunktionen zu Engpässen in der Verarbeitung kommen kann.604 2.8.2.2.3 Klassifikationsmöglichkeiten von Data Dictionaries Bisher gibt es keine allgemein anerkannten Regeln, nach denen man die diversen Ausprägungen von Data Dictionaries klassifizieren kann. Dennoch lassen sich folgende Kategorien für DDS bilden:005 - lokal - aktiv - integriert (abhängig) - zentral

global passiv freistehend (unabhängig) dezentral.

nicht zu umgehen (non-bypassable)

Der klassische Fall eines lokalen Data Dictionaries ist sein Einsatz als Datenlexikon für eine konkrete Datenbank. Diese sehr lokale Anwendung wird überwiegend zur Datenbankadministration verwendet und hat dementsprechend auch nur einen sehr beschränkten Gültigkeitsbereich. Existieren im Unternehmen mehrere unabhängige Datenbanken, so ist es leicht möglich, dass

603

Vgl. GRADWELL, D.J.: Integrating, a.a.O., S. 447.

6 0 4

V g l . LOOMIS, Μ . ; MANNINO, M . ; ALLEN, F.: F u n d a m e n t a l s , a . a . O . , S. 2 9 3 .

605 v g l . zu diesen Klassifizierungen u.a. DSOUZA, L.L.: Dictionaries, Repositories and All That Jazz, IBM Enterprise Systems Support, Dallas 1990, S. 8; NARAYAN, R.: Data Dictionary Implementation, Use and Maintenance, Englewood Cliffs 1988, S. 49 f. sowie REUSCH, P.J.A.: Aufbau, a.a.O., S. 7 - 7 ff.

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

255

auch entsprechend viele nicht integrierte DDS vorhanden sind. Standardisierungen, wie sie für eine effiziente, unternehmensweite Informationsversorgung notwendig sind, lassen sich mit mehreren lokalen DDS kaum erzielen. Ein globales Data Dictionary hingegen unterliegt keinerlei Beschränkungen bzgl. seines Gültigkeitsbereiches. Hiermit ist es möglich, ein unternehmensweites Informationsmodell abzubilden, das sowohl betriebswirtschaftliche als auch physikalische Aspekte der Datenverarbeitung berücksichtigt. Nach ihrer Funktionsmöglichkeit unterteilt man Data Dictionaries in aktive und passive Systeme. Ein passives Data Dictionary hat ausschließlich die Aufgabe, einen zentralen Datenstruktur- und -Verwendungsnachweis zu fuhren; es stellt somit ein reines Nachdokumentationssystem dar. Ein Data Dictionary wird hingegen als aktiv bezeichnet, wenn seine Metadaten für die Spezifikation von Konsistenzbedingungen, Dateien, Programmen und Benutzeranwendungen verwendet werden und es als zentrales Medium den Änderungsdienst für Datenstrukturen und Verwendungsnachweise ausführt.006 Trotz dieser wesentlichen Vorteile weisen aktive Data Dictionaries häufig Performanceprobleme auf, da eine große Anzahl an Kontroll- und Zugriffsmechanismen koordiniert werden muss und sie daher in Bezug auf ihre Organisation und Implementierung wenig flexibel sind. Werden die Spezifikationsdaten in den Meta-Datenbanken dazu verwendet, das Anwendungssystem zu steuern, so dass Update-Prozesse unmittelbar wirksam werden, bezeichnet man das Data Dictionary als voll aktiv. Es stellt dann den Funktionsumfang eines Data Directory dar. Auf diese Art und Weise entsteht bezüglich der Systemführung und Datenredundanz ein ideales Konzept, welches jedoch nicht das Ziel verfolgt, sämtliche Unternehmensdaten zu verwalten. Hinsichtlich der Verflechtung von Data Dictionary Systemen und Datenbanksystemen unterscheidet man zwischen integrierten, freistehenden und nicht zu umgehenden Systemen. Bei einem integrierten oder abhängigen Data Dictionary führt das Datenbanksystem neben der Anwendungsdatenbank auch die Meta-Datenbank, deren Spezifikationsdaten vom Dictionary eingebracht, ausgewertet und für das Anwendungssystem sofort wirksam werden. Diese Abhängigkeit ist häufig bei aktiven Data Dictionaries zu bemerken. Im Gegensatz dazu verwalten freistehende, unabhängige Data Dictionary Systeme ihre Meta-Datenbank selbst mit einem datenbankähnlichen System und sind somit bei ihrem Einsatz nicht auf spezielle universelle Datenbanksysteme angewiesen. 606

Vgl. REUSCH, PJ.Α.: Informationssysteme, a.a.O., S. 187.

256

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Erfolgt der Zugang zu einem DBMS bzw. zu anderen Tools und Anwendungsprogrammen nur über das Data Dictionary, so bezeichnet man dieses System als nicht zu umgehen. Ein solches non-bypassable Data Dictionary ist nicht in die Systeme integriert, muss jedoch mit ihnen synchronisiert sein. Ein weiteres Klassifikationsmerkmal von Data Dictionaries liegt in der Zentralisierung oder Dezentralisierung der Spezifikationsdaten. Zentralisierung bedeutet, dass die Spezifikationsdaten nur einmal im System vorhanden sind, wie es zwangsläufig bei voll aktiven Data Dictionary Systemen der Fall ist. Die Auswertung der Spezifikationsdaten erfolgt dabei zur Laufzeit. Bei dezentraler Führung liegen mehrere Ausprägungen der Spezifikationsdaten vor, die von Programmen zu unterschiedlichen Zeitpunkten genutzt werden, etwa zum Zeitpunkt der Kompilierung, der Bindung oder zur Laufzeit. Bei unabhängigen Data Dictionaries liegt häufig Dezentralisierung vor. Allerdings kann bei diesem Prinzip Datenredundanz nicht ausgeschlossen werden, da sich bei früher Bindung der Spezifikationsdaten an die Programme Änderungsdienste nur sehr schwer durchführen lassen. 2.8.2.3 Repositories

Data Dictionaries und Repositories sind nur sehr schwer voneinander zu unterscheiden. Auch in der Literatur hat der Begriff Repository noch keine einheitliche Bedeutung. Repositories sind jedoch umfangreicher als Data Dictionaries, da sie diese um Informationen, Dienste und Tools für die Software-Entwicklung ergänzen. Entsprechend der Zielsetzung, ein Werkzeug für den gesamten Bereich der Anwendungsentwicklung zu sein, ist ein Repository als eine Weiterentwicklung der globalen Data Dictionaries einzuordnen.607 Als wesentliche neue, über ein Data Dictionary hinausgehende Bestandteile sind die Case-Unterstützung in allen Phasen des Entwicklungszyklus sowie das Vorhandensein eines Repository-Informationsmodells zu nennen: Im Rahmen eines Entwicklungsprozesses muss ein Repository daher die Möglichkeit bieten, die Ergebnisse aller Projektaktivitäten zur Dokumentation und Koordination zu speichern. Somit können in jedem Projektschritt diverse Auswertungen vorgenommen werden. Das Spektrum der Auswertungsmöglichkeiten umfasst neben der Generierung von Zwischenergebnissen wie bspw. die 607 608

DSOUZA, L.L.: Dictionaries, Repositories and All That Jazz, a.a.O., S. 20 ff. Auf die Darstellung von Repository-Komponenten und -Funktionalitäten, die auch für Data Dictionaries Gültigkeit besitzen, wird hier verzichtet. Vgl. dazu Kapitel 2.8.2.2.

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

257

Normalisierung von Datensichten, auch das Darstellen von Endergebnissen (Datenbankdefinitionen) und sogar die Erstellung von Dokumentationen wie Handbücher oder Hilfe-Systeme. Das Repository-Informationsmodell enthält neben den auch in Data Dictionaries üblichen Beschreibungen der Daten bestehender IV-Systeme zusätzlich Modelle der realen Welt. Nach A. VON STÜLPNAGEL sind die dazu notwendigen Generierungs- und Analysefunktionen ein wesentlicher Bestandteil des Systems.009 Es soll von Anwendungsentwicklern und Anwendern gleichermaßen genutzt werden, um so unternehmensweite Standardisierungen einführen zu können. Bezüglich der Funktionalität sind bei einem Repsoitory zwei Klassen von Operationen zu fordern:0/0 -

Datenbank-Servicefunktionen: Hierunter werden alle Funktionen zusammengefasst, die aus einem Repository auch ein DBMS machen. - Repository-Servicefunktionen: Die Klasse umfasst alle Funktionen, die ein DBMS von einem Repository unterscheiden, wie z.B. Modellierungsfunktionen und eine Konfigurationsverwaltung. Im Rahmen der unternehmensweiten Informationsversorgung auf der Basis eines Data Warehouses kommt Repositories eine weitere wesentliche Bedeutung za.6'1 Ein Data Warehouse soll ja bekanntlich als unternehmensweiter Datenpool die Informationsversorgung autorisierter Einzelpersonen mit zuverlässigen, zeitrichtigen, genauen und verständlichen Geschäftsinformationen aus allen Unternehmensbereichen sicherstellen.672 Mitarbeiter aller Ebenen sollen durch ein Data Warehouse in die Lage versetzt werden, Informationen aus unterschiedlichsten Quellen selbstständig zu extrahieren, zu transformieren und zu analysieren.

609 vgl. STÜLPNAGEL, A. VON: Repositories - Konzepte, Architekturen, Standards, in HMD: 161/1991, S. 13 ff. (10-25). 610

611

612

Vgl. BEHME, W.: Entwurf, a.a.O., S.109 ff. sowie STÜLPNAGEL, A. VON: Repositories, a.a.O. S. 17 ff. Vgl. zum Thema Meta-Daten und Datawarehousing: MUCKSCH, H.: Das Management von Meta-Informationen im Data Warehouse, a.a.O., S. C811.06-C811.11. Vgl. MUCKSCH, H : Charakteristika, Komponenten und Organisationsformen von Data Warehouses, a.a.O., S.91 f.

258

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

Aus dieser Zielsetzung des Data Warehousing folgt u.a., dass Entscheidungskompetenz nach unten verlagert wird und dass Endbenutzer zunehmend Aufgaben wahrnehmen, die früher nur von EDV-Spezialisten bewältigt werden konnten.6/3 Endbenutzer müssen daher im Rahmen ihrer Aufgabenerfüllung nicht nur Zugang zu den Daten des Data Warehouses haben, sie benötigen darüber hinaus eine Vielzahl weiterer Informationen, um bspw. die Relevanz des gefundenen Datenmaterials für die Geschäftsprozesse zu beurteilen, und um dann die richtigen Daten in den Kontext ihrer Aufgabenstellung einordnen zu können. Das Meta-Datenbanksystem des Data Warehouses integriert und enthält entsprechende unterschiedliche DV-technische und betriebswirtschaftliche Informationen über die im Data Warehouse gespeicherten Daten. D. M C C L A N A H A N unterscheidet diesbezüglich folgende drei Meta-DatenEbenen bzw. Sichten auf Meta-Daten in einem Data Warehouse, die wiederum für unterschiedliche Benutzergruppen von Bedeutung sind:074 -

Operationale bzw. Datenquellen-bezogene Meta-Daten Operationale Meta-Daten beinhalten Informationen über die operationalen Systeme wie bspw. Namen der Originaldatenquellen, die Datenstrukturen (Feldbezeichnungen) und Dateiorganisationsformen, Informationen über den Transformationsprozess sowie die Zieldatenquelle nach erfolgter Datentransformation.675 - Data Warehouse-bezogene Meta-Daten Im Rahmen der Meta-Daten-Verwaltungsfunktion (Meta-Data) werden u.a. Meta-Daten gespeichert über:670 -

das dem Data Warehouse zugrunde liegende Datenmodell sowie eine semantische und eine DV-technische Beschreibung aller gespeicherten Daten, - die Herkunft der Daten, - Informationen über den gesamten Transformationsprozess, einschließlich der Angabe der Werteinheiten der einzelnen Datenfelder sowie der zeitli-

613 VGL. BEHME, W.; MUCKSCH, H: Informationslogistik, a.a.O., S. 11.

Die

Notwendigkeit

einer

unternehmensweiten

614

Vgl. MCCLANAHAN, D.: Making Sense of Enterprise Data, in: Databased S. 78 f. (76-79).

615

Vgl. POE, V.: Building a Data Warehouse for Decision Support, Upper Saddle River 1995, 32 f. und 170 f.

616

Vgl. MUCKSCH, H.; HOLTHUIS, J.; REISER, M.: Das Data Warehouse-Konzept, a.a.O., S. 426.

Advisor:

11/1996,

2.8 Systeme zur Dokumentation und Verwaltung von Meta-Daten

259

che Verlauf der bereits durchgeführten und geplanten Datenübernahmen aus den operationalen DV-Systemen - die Abbildung aller vorhandenen Verdichtungsstufen einschließlich des zeitlichen Ablaufes, - bestehende Auswertungen und Analysen, die als Mustervorlagen für andere Aufgabenstellungen dienen, - die Daten aus den externen Quellen, versehen mit einem entsprechenden Eintrag über Inhalt, Quelle, Datum, Form, Archivierungsort und Querverweisen aufbereite vorhandene Dokumente. - Benutzer- bzw. Geschäftssichtbezogene Meta-Daten. Die Benutzer- bzw. Geschäftssichtbezogenen bilden eine Abstraktionsschicht zwischen den in der Data Warehouse-Datenbank gespeicherten Daten und den betriebswirtschaftlichen Auswertungen in Form von Analysen und Reports. Zusätzlich zu den bereits erwähnten Meta-Daten sollten in der Meta-Datenbank eines Data Warehouses folgende Meta-Informationen verfügbar sein:077 -

-

ein Lexikon der Datenbezeichnungen zur Unterstützung einer einheitlichen Namensgebung von Datenobjekten einschließlich gebräuchlicher Abkürzungen, ein Thesaurus, der Synonyme für Datenobjekte und ihre Charakteristika enthält, ein alphabetisch geordnetes Glossar der verwendeten Bezeichnungen, Abkürzungen und Definitionen, ein Datenstrukturverzeichnis aller Data Warehouse Daten, ein Verzeichnis der Integritätsbedingungen, Cross-Referenz-Tabellen ein Data Directory, das Beschreibungen enthält, welche Organisationseinheiten über welche Datenquellen und welche unveröffentlichten Dokumente verfügen, und welche Projekte im Zusammenhang mit dem Data Warehouse stehen. Zudem sollten im Data Directory die Ansprechpartner vermerkt sein.

EDV-Anwender waren schon immer - und sind es gegenwärtig mehr denn je während des gesamten Datenverarbeitungsprozesses auf die Verfügbarkeit von Meta-Daten angewiesen Der Bedarf nach mehr und besseren Meta-Informationen entsteht auch nicht erst durch die Entwicklung oder den Einsatz eines Data Warehouses. Ohne die maschinengestützte Dokumentation der laufenden und 617

Vgl. BRACKETT, M.H.: The Data Warehouse Challenge, a.a.O., 194 ff.

260

2 Datenmanagement - Voraussetzung des Entwicklungsmanagements

geplanten Softwareentwicklungsprojekte, der verfügbaren Hardware und ihren Komponenten sowie der Benutzer der Informationstechnologien lassen sich weder die strategischen, noch die operativen Aufgaben des Informationsmanagements effizient und wirtschaftlich durchführen. Um aber alle Informationsbedarfe des Informationsmanagements und der zunehmend größeren Zahl von Endbenutzern erfüllen zu können, bedarf es eines Konzeptes für ein - nicht nur auf den IV-Bereich beschränktes - Verwaltungssystem für Meta-Daten.6/Ä Die Meta-Datenverwaltungskomponenten eines Data Warehouses bieten zumindest die Möglichkeit, diesem Ziel ein großes Stück näher zu kommen.

618

Vgl. dazu EICKER, S.: IV-Dictionary, Berlin/New York 1994.

3 Sichten der Softwareentwicklung Informationsmanagement ist eine vieldimensionale Aufgabe. Zum einen umfasst es verschiedene, zeitlich aufeinanderfolgende Aufgaben, die aufgrund der Komplexität selbst mit Hilfsmitteln noch nicht vollständig beschrieben werden können. Zum weiteren hängen diese Aufgaben auch vom Zweck ab, der mit der Aufgabenbewältigung erreicht werden soll.679 Dieser bestimmt ganz wesentlich den Blickwinkel, aus dem das Informationssystem gesehen wird. Unser anvisiertes Ziel, ein ganzheitliches Informationssystem zu entwickeln, das möglichst allen Anforderungen gerecht wird, führt zu der Forderung nach Verfolgung der verschiedenen möglichen Blickrichtungen oder Sichtweisen. Aus den verschiedenen Sichtweisen resultieren unterschiedliche Verfahrensweisen, nach denen man versucht, auf wirtschaftliche Art Informationssysteme zu erstellen. Inzwischen sind viele Wege bei der Entwicklung von Informationssystemen beschritten worden, die zum Teil mit erheblichen Mängeln behaftet sind. Da es jedoch bisher keinen geschlossenen, in sich konsistenten und sicheren Weg zu wirklich guten Informationssystemen gibt und sich aufgrund vieler verschiedener Anwendungen und Erfahrungen auch kein Standard ergeben hat, versucht man, aus den Fehlern zu lernen. Dabei konzentriert man sich immer wieder auf neue Schwerpunkte und produziert somit auch häufig neue Fehler. Diese in der Vergangenheit verfolgten Wege sollen im folgenden kurz skizziert werden, bevor auf einige wesentliche Sichten eingegangen wird. 3.1 Die historischen Sichten auf ganzheitliche Informationssysteme Zunächst setzte man die Rechner für solche Probleme ein, die man mit ihnen wirtschaftlicher lösen konnte. Dabei standen die mathematischen und technischen Probleme, die durch umfangreiche Rechenaufgaben gekennzeichnet waren, im Vordergrund. An eine Lösung des potenziellen Problems der automatischen Dateneingabe von großen Datenmengen dachte man noch nicht. Dieses war auch gut verständlich, da die Medien zur Aufnahme von großen

619 v g l . Band I, Kap. 5 sowie das nachfolgende vierte Kapitel in diesem Buch.

3 Sichten der Softwareentwicklung

262

Datenmengen noch nicht in ausreichendem Maß verfügbar waren. Dabei entstand eine Aufgabenbearbeitung, wie sie in Bild 3-1 wiedergegeben wird.620 Jede Aufgabenstellung wurde nacheinander im Stapelbetrieb bewältigt. Es handelte sich somit um eine sequenzielle Bearbeitung ausgewählter, eventuell auch betrieblicher Aufgaben, d.h., es standen die Ansätze einer funktionsorientierten Bearbeitung im Vordergrund.

II Q C 1 3=]

Qr

• C3 Input

Input ιr

ιr

Programm 1 Verarbeitung

Programm 2 Verarbeitung

Output

Output r

1r

Q r Bild 3-1: Einfache

1 II

Q

d

II

Fileverarbeitung

Die Schaffung umfassender Datenspeicher sowie schnellerer Arbeitsspeicher und schnellerer Prozessoren führte dazu, dass man die Ressourcen (optimalerweise im Parallelbetrieb) besser nutzen konnte. Dazu wurde es notwendig, dass die Daten nicht mehr für jede Aufgabe einzeln gehalten, eingegeben, verarbeitet und ausgegeben wurden, sondern im Zusammenhang für mehrere - nach Möglichkeit für alle Aufgaben - simultan angelegt und verwaltet werden sollten. Es wurden möglichst unternehmensweite Datenmodelle und Datenbankschemata entworfen, die immer weiter verfeinert wurden, um so gut wie möglich die Anforderungen aller Aufgaben bezüglich Zugriffsarten und Zugriffsgeschwindigkeiten zu erfüllen. Solche Datenmodelle sind auch heute noch eine Basis der Informationsverarbeitung. Die Möglichkeiten der in Bild 3-2 dargestellten datenorientierten Sichtweise wurden in Kap. 2 ausführlich diskutiert.

620

Vgl. ERFA-PPS mit EDV, Arbeitsgruppe Datenbanken (Hrsg.): Datenbanken, Zürich/Köln 1977, S. 5.

3.1 Die historischen Sichten auf ganzheitliche Informationssysteme

263

Input Rtxyarrml Datenbank

I ΐ

Output Input RxxjTarrm2 V« Output

Bild 3-2: DB-Verarbeitung621 Die Konzentration auf die Daten führte wieder zwangsläufig zu Einseitigkeiten, da die Betrachtung der Programme als Abbild der betrieblichen Funktionen auf der Strecke blieb. Dadurch, dass diese nun wieder mehr an Bedeutimg gewannen, rückte die funktionsorientierte Sichtweise funktionsorientierte Sicht in den Vordergrund. Unberücksichtigt blieb weiterhin die Einbeziehimg der betrieblichen Organisation, in der das Informationssystem eingesetzt wurde. Ziel dieser Betrachtungsweise, die als Organisationssicht bezeichnet wird, ist die Erfassung und Koordination aller zeitlichen und logischen Abläufe mit besonderer Berücksichtigung der von den Funktionen betroffenen Ressourcen, wobei die Notwendigkeit der Modellierung der Organisationssicht bis heute von vielen Betrieben noch nicht erkannt worden ist. Bei einer anderen Sicht geht es mehr darum, zusammengehörende ablauforganisatorische Funktionen auch zusammen zu lassen. Diese ablaufbedingten Funktionen, die i.d.R. durch eine Menge von Operationen oder Funktionen über koordinierte Inputs, eine Verarbeitung und auch durch ein System von Outputs beschrieben werden, bezeichnet man als Prozess. Auf die prozessorientierte Sicht wird in Kapitel 3.4 näher eingegangen. Eine Weiterentwicklung, die gleichzeitig sowohl die Funktions- als auch die Datensicht beinhaltet, ist die objektorientierte Sichtweise, bei der man versucht, Daten und Funktionen als Einheiten abzubilden, die logisch zusammengehören und gemeinsam als Objekte aufgefasst werden.

621

Vgl. ERFA PPS mit EDV, Arbeitsgruppe Datenbanken (Hrsg.): Datenbanken, a.a.O., S. 5.

264

3 Sichten der Softwareentwicklung

Aufbauend auf all diesen Sichten ist die ganzheitliche Sicht zu sehen, in der man bestrebt ist, eine möglichst umfassende Sicht durch die Anwendung von vielen verschiedenen Sichtweisen zu gewinnen. Mit jeder dieser Sichten wird i.d.R. zumindest eine Absicht verfolgt. So dient die Datensicht bspw. der Unterstützung der Funktionssicht und umgekehrt. Ein reines Hintereinanderschalten von Sichten ist auch nicht sinnvoll, da die Daten die Funktionen und die Funktionen wiederum die Daten beeinflussen. Die Erfüllung beider Sichten ist zudem abhängig von der Organisationssicht. Eine Zusammenfassung von Organisationssicht und Funktionssicht findet man z.T. in der Prozesssicht und eine Zusammenfassung von Funktionen und Daten in der objektorientierten Sicht. Gute Lösungen können daher nur aus dem Zusammenspiel mehrerer Sichten entstehen. Ohne Berücksichtigung des Zusammenwirkens aller aufgeführten Sichten - bspw. lediglich basierend auf einer reinen Daten- und/oder Funktionssicht - führt die Entwicklung eines Informationssystems zu unvollständigen und unbefriedigenden Lösungen. Um ein besseres Verständnis für die einzelnen Sichtweisen zu vermitteln, werden sie im Folgenden dargestellt. 3.2 Datenorientierte Softwareentwicklung

Im zweiten Kapitel wurden die Methoden des Datenmanagements bereits ausführlich behandelt, wobei insbesondere auf die - Methoden der logischen Datenorganisation, in denen die Zusammenhänge zwischen den einzelnen Datenbeständen analysiert werden, - problemorientierte Vorgehensweise bei der Entwicklung eines Datenbankschemas, - Möglichkeiten der physischen Datenspeicherung und - die Fertigstellung des endgültigen Datenbankdesigns eingegangen wurde. Mit diesen Methoden ist es möglich, jeden Betrieb bezüglich seiner Daten im Rahmen der allgemeinen Anforderungen abzubilden. Da die Datensicht in ihren Modellierungs- und Darstellungsformen bereits ausführlich behandelt wurde, wird hier auf weitere Ausführungen verzichtet.

3.3 Funktionsorientierte Softwareentwicklung

265

3.3 Funktionsorientierte Softwareentwicklung Als Funktionen bezeichnet man »kontinuierlich zu erfüllende betriebliche Aufgaben zur Erreichung eines Unternehmenszieles«022. Informationssysteme führen Aufgaben aus oder unterstützen die mit der Aufgabenbewältigung beauftragten Personen, so dass bei der Gestaltung eines Informationssystems von den zu erfüllenden Funktionen auszugehen ist. In der Vergangenheit wurden häufig, wie bereits erwähnt, den identifizierten Funktionen anschließend die zur Ausführung notwendigen Datenobjekte zugeordnet. Auf die Problematik, die dieses Vorgehen mit sich bringt, wurde bereits in Kap. 2 eingegangen. Sie resultiert im Wesentlichen daraus, dass redundante Datenbestände angelegt werden oder parallele Verarbeitung unmöglich ist. Durch diese Redundanz erhöht sich der Wartungs- und Pflegeaufwand des betrieblichen Datensystems beträchtlich, dies gilt gleichermaßen für den Speicherplatzbedarf. Zudem führen doppelt gehaltene Datenbestände leicht zu Inkonsistenzen. Das wesentliche Kennzeichen der funktionsorientierten Software-Entwicklung ist die Konzentration der Betrachtungen auf den Verarbeitungsalgorithmus. Eine Funktion (F) ist aus mathematischer Sicht eine Vorschrift, Inputdaten (I) in Outputdaten (O) umzuwandeln. Sie erfüllt die Gleichung Ο = F(I). Die Vorgehensweise Eingabe - Verarbeitung - Ausgabe bezeichnet man auch als EVA-Prinzip. Funktionen lösen über die Verarbeitung Aktionen aus, die die Zustände, die im Datenmodell beschrieben werden, in andere Zustände überführen.

622

DERIGS, U.; GRABENBAUER, G.L.: COLOWIN: eine fallorientierte Einführung in die

Softwareentwicklung, München/Wien 1993, S. 73.

266

3 Sichten der Softwareentwicklung

Da Funktionen im Unternehmen Tätigkeiten entsprechen, sollte man bei ihrer Beschreibung darauf achten, Verben zu benutzen. Sie lassen sich dadurch auf einen Blick von den Daten unterscheiden. Aufgabe der Funktionsmodellierung ist es, aus Anforderungen an das Anwendungssystem Programmfunktionen abzuleiten und diese Funktionseinheiten als Module zu entwerfen. Zur Funktionsmodellierung können Funktionen auf unterschiedlichen Verdichtungsstufen beschrieben werden. Oberste Stufe und höchste Verdichtungsstufe ist die Funktionsbündelung in Form von Geschäftsprozessen oder Vorgangsketten. Eine Vorgangskette beschreibt dabei den komplexen Ablauf eines Geschäftsprozesses von seiner Entstehung bis zu seiner Beendigung, so z.B. die Bearbeitung eines Kundenauftrages von der Kundenanfrage bis zum Versand und der Bezahlung der Ware. Jede Vorgangskette lässt sich in eine Folge einzelner Funktionen (»Annahme des Kundenauftrages«, »Überprüfen der Lagerbestände«, »Erteilen des Fertigungsauftrages«) untergliedern. Zur Identifizierung und Strukturierung von Einzelfunktionen wird üblicherweise Top-Down/Bottom-Up vorgegangen. Die zu bewältigende Gesamtaufgabe wird dazu vorerst sukzessive Top-Down in Teilfunktionen zerlegt. Im Rahmen dieses Prozesses erfolgt jeweils eine Zerlegung in mindestens zwei Teilfunktionen. Als Maximalwert wird in der Literatur die Bildung von sieben (+/-zwei) Teilfunktionen angegeben.625 Der Zerlegungsprozess ist erst dann vollständig bewältigt, wenn alle Funktionen, die durch das Informationssystem unterstützt werden sollen, in Form von Elementarfunktionen (d.h. Funktionen, die ohne weitere Zerlegung einfach programmiert werden können) abgebildet sind.0·24 Zur Kontrolle werden die entstandenen Elementarfunktionen BottomUp wieder zusammengefügt. Dadurch kann überprüft werden, ob sie die Gesamtaufgabe vollständig und überschneidungsfrei abdecken.625 Im Gegensatz dazu geht man im Rahmen einer Bottom-Up-Vorgehensweise davon aus, dass bereits Elementarfunktionen vorliegen, die dann sukzessive zu einer Gesamtaufgabe zusammengefügt werden. A.-W. SCHEER unterscheidet die folgenden Ebenen der Dekomposition:626 -

Geschäftsprozess, Vorgangskette: komplexer Ablauf, bezogen auf ein Objekt (z.B. Kundenauftrag, Produkt)

623

Vgl. SCHUMANN, Μ.; SCHÜLE, H.; SCHUMANN, U.: Entwicklung von Anwendungssystemen, Berlin u.a., S. 91.

624

Vgl. MERTENS, P. u.a.: Grundzüge der Wirtschaftsinformatik, a.a.O., S. 161.

625 Ygj SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 65 f. 626 y g j SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 64 f.

3.3 Funktionsorientierte Softwareentwicklung

267

- Funktion: Komplexe Tätigkeit, die direkt in den Prozess eingeht und weiter untergliedert werden kann. - Teilfunktion: Tätigkeit, die in übergeordnete Funktionen eingeht und weiter zerlegt werden kann. - Elementarfunktion: Tätigkeit, die nicht weiter untergliedert wird. Sie bildet die Basis für die anschließende Programmierung. Elementarfunktionen lassen sich durch verschiedene Merkmale charakterisieren:027 -

Eine Elementarfunktion liefert ein vollständiges Ergebnis (z.B. eine Kennzahl) und kann ohne Unterbrechung durchgeführt werden. - Die Operationen innerhalb einer Elementarfunktion beziehen sich immer nur auf ein einziges Datenobjekt. - Eine Elementarfunktion muss unabhängig von anderen Funktionen ausführbar sein. - Die Beschreibung der Ablauflogik einer Elementarfunktion hat auf einer DIN A4-Seite Platz. Anhand dieser Merkmale lässt sich überprüfen, ob eine Funktion bereits in ihrer Elementarform vorliegt und der Dekompositionsprozess damit beendet ist. Die strukturierte Abbildung der benötigten Funktionen bezeichnet man als Funktionenmodell. Ein Funktionenmodell soll das Gesamtsystem in seinen sachlogischen Zusammenhängen transparent machen.625 Die Funktionsstruktur wird dabei in rein statischer Natur dargestellt, die Reihenfolge, in der Funktionen abgearbeitet werden, wird nicht wiedergegeben.029 Man bildet i.d.R. Funktionsbäume oder Hierarchiediagramme, indem man die Funktionen - wie beschrieben - in Teilfunktionen zerlegt. Es bestehen jedoch keine eindeutigen Kriterien für eine Funktionsgliederung. Bild 3-4 zeigt beispielhaft ein Funktionenmodell für die Bearbeitung von Reparaturaufträgen in einer Werkstatt. Neben der Einteilung von Funktionen nach ihrer Position in der Funktionshierarchie existiert ein weiterer Ansatz, verschiedene Funktionstypen voneinander abzugrenzen. Entsprechend den Zielen, die mit der Ausführung der

027

V g l . SCHUMANN, M . ; SCHÜLE, H.; SCHUMANN, U . : E n t w i c k l u n g v o n A n w e n d u n g s s y s t e m e n ,

a.a.O., S. 90. 628

629

V g l . SCHUMANN, M . ; SCHÜLE, H.; SCHUMANN, U . : E n t w i c k l u n g v o n A n w e n d u n g s s y s t e m e n ,

a.a.O., S. 14. Vgl. SCHEER, A.-W.: Wirtschaftsinformatik: Referenzmodelle industrieller Geschäftsprozesse, a.a.O., S. 20.

3 Sichten der Softwareentwicklung

268

verschiedenen Funktionen verfolgt werden, unterscheiden U . DERIGS und W. GRABENBAUER zwischen Datenverwaltungs-, Vorgangs- und Auswertungsfunktionen.050

Bild 3-4:

Funktionenmodell631

Datenverwaltungsfunktionen realisieren elementare Anforderungen des Benutzers an die Bearbeitung einzelner Daten- oder Benutzerobjekte. Während ein Datenobjekt einem Entity der Datensicht entspricht, bezieht man sich im Rahmen der Funktionsmodellierung häufig auf Benutzerobjekte. Diese fassen Entity-Typen zusammen, die sich aus Sicht der Benutzer als ein Informationsobjekt darstellen. So lässt sich das Benutzerobjekt »Rechnung« in die Informationsobjekte »Rechnungskopf« und »Rechnungspositionen« unterteilen. Typische Datenverwaltungsfunktionen sind das Neuanlegen, Einfügen, Suchen, Löschen oder das Drucken von Daten- oder Benutzerobjekten (z.B. »Rechnung anlegen«, »Rechnung drucken«).032 Diese Operationen sind von einfacher Komplexität und werden i.d.R. von Datenbanksystemen bereits zur Verfügung gestellt. Im Rahmen der Funktionsmodellierung ist sicherzustellen, dass für jedes benötigte Datenobjekt zumindest die Funktionen »Neuanlage« und »Löschen« definiert sind.

630 631

^

Vgl. DERIGS, U.; GRABENBAUER, G.L.: COLOWIN, a.a.O., S.92-94. Modifiziert nach: SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 65. H. ÖSTERLE unterscheidet in: Append: Hinzufügen einer Entität, Read: Lesen einer Entität, Modify: Verändern einer Entität und Delete: Löschen einer Entität. Vgl. ÖSTERLE, H.: Business Engineering: Prozeß- und Systementwicklung, Band I, Entwurfstechniken, Berlin u.a. 1995, S. 291.

3.4 Prozessorientierte Software-Entwicklung

269

Vorgangsfunktionen bilden standardisierte Geschäftsvorgänge (z.B. »Kundenauftrag annehmen«, »Bestellung aufgeben«) als Ganzes ab. Vorgangsfunktionen setzen sich komplett oder teilweise aus Datenverwaltungsfunktionen zusammen. So lässt sich die Vorgangsfunktion »Kundenauftrag annehmen« in die Bausteine »Kunde suchen« (ggf. »Kunde anlegen«), »Artikel suchen« und »Auftrag anlegen« zerlegen. Beim Entwurf der Vorgangsfunktionen ist zu kennzeichnen, auf welche Datenverwaltungsfunktionen jeweils zurückgegriffen werden kann. Auswertungsfunktionen verdichten eine große, über mehrere Daten- bzw. Benutzerobjekte gestreute Menge an Inputdaten zu einer relativ geringen Menge an Outputdaten. Sie dienen der Beantwortung komplexer Fragestellungen und liefern i.d.R. Informationen für das Management. Charakteristisch für Auswertungsfunktionen ist außerdem, dass sie im Gegensatz zu Vorgangsfunktionen meist in größeren zeitlichen Abständen ausgeführt werden. Zu den Auswertungsfunktionen zählt man z.B. die Durchführung von Marktanalysen oder Lieferantenbewertungen. Wie Vorgangsfunktionen setzen sich auch Auswertungsfunktionen aus Datenverwaltungsfunktionen zusammen. In Ausnahmefallen sind sie Bestandteil von Vorgangsfunktionen; so könnte z.B. die Lieferantenbewertung als eine Teilfunktion der Funktion »Bestellung aufgeben« definiert sein. Zur Identifikation und Beschreibung von Funktionen im Funktionenmodell können u.a. das Struktogramm 655 , HIPO (Hierarchie plus Input-ProzessOutput), dem die Top-Down-Methode 03 '' mit den Dokumenten Strukturübersicht, Überblicksdiagramm und Detaildiagramm zugrunde liegt, und auch SADT (Structured Analysis and Design Technique) angewandt werden. 635 In der Vergangenheit wurde hierfür auch der Programmablaufplan verwendet, der jedoch heute aufgrund der schlechten Übersichtlichkeit nur noch bei Traditionalisten Anwendung findet. 3.4 Prozessorientierte Software-Entwicklung Die steigenden Möglichkeiten der Verteilung der Informationstechnik über den Betrieb und die Betriebsgrenzen hinaus haben die grundlegenden

633 YGI BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 358 f. 634 YGJ BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 29. 635

Vgl. Kap. 4.

270

3 Sichten der Softwareentwicklung

Restriktionen der traditionellen DV wie Ort und Zeit der Verarbeitung sowie des Ressourceneinsatzes beseitigt oder zumindest entschärft. Aus der Perspektive eines Unternehmens besteht daher die Möglichkeit, sämtliche Aspekte des Geschäftes von Grund auf zu überdenken und evtl. neu zu gestalten.Dieses ermöglicht einen Paradigmenwechsel: Während früher eine Innensicht der Abteilung eines Unternehmens vorherrschte, eröffnet die Informationstechnik jetzt das Potenzial, das Unternehmen noch stärker an von außen herangetragenen Erfordernissen auszurichten. Heute herrscht deshalb eher eine Außensicht vor. Die Prozessleistungen und die Kunden stehen im Vordergrund.037 Dieses erfordert ein abteilungsübergreifendes Denken. Man darf sich daher nicht mehr an einzelnen Aufgabenbereichen (Beschaffimg, Produktion, Absatz etc.) bzw. Produkten oder Produktgruppen orientieren, sondern muss das Unternehmen an den Kernprozessen ausgerichtet gestalten. Diese Unternehmensumgestaltung, auch Geschäfts(prozess)optimierung oder engl. Business (Process) Engineering genannt, darf sich nach H. ÖSTERLE allerdings nicht, wie Bild 3-5 verdeutlicht, allein auf die Prozesse beschränken, sondern muss auf allen Ebenen des Unternehmens ansetzen. Sie betrifft zunächst die Bereiche der Geschäftsstrategie, sodann alle übrigen Prozesse einschließlich der Ebene der Informationssysteme.Bild 3-5 verdeutlicht, dass eine isolierte Betrachtung der einzelnen Ebenen i.d.R. nur zu einer suboptimalen Lösung führt. Alle drei Ebenen müssen aufeinander abgestimmt werden. Der Schlüssel zu einer derartigen Reorganisation sind die Prozesse. Die wichtigsten Merkmale eines Prozesses nach H. ÖSTERLE sind:659 -

Ein Prozess ist eine Abfolge von zusammengehörigen Aufgaben (Funktionen). - Die Funktionen können über mehrere organisatorische Einheiten verteilt sein.

636

Vgl. ÖSTERLE, H.: Business Engineering: Prozeß- und Systementwicklung, Band I: Entwurfstechniken, Berlin u.a. 1995, S. 13. 637 Vgl. ÖSTERLE, H . : Business Engineering: Prozeß- und Systementwicklung, Band I: Entwurfstechniken, a.a.O., S. 11, LÜCKE, W.: Wertschöpfungsketten und Wertketten im Prozeßkettenmanagement, in: Zfl>·. Vol. 7, 1/1996, S. 195 (193-204) sowie ADAMS, R; KRETSCHMAR, T . : Machen Sie aus Ihren Mitarbeitern Organisationsprofis, in: Bank Magazin 2/1996, S. 62 (62-65). 638 vgl. ÖSTERLE, H.: Business Engineering: Prozeß- und Systementwicklung, Band I: Entwurfstechniken, a.a.O., S. 16. 639 ÖSTERLE, H.: Business Engineering: Prozeß- und Systementwicklung, Band I: Entwurfstechniken, a.a.O., S. 16.

3.4 Prozessorientierte Software-Entwicklung

271

-

Computergestützte Applikationen unterstützen die Ausführung der einzelnen Funktionen. - Ein Prozess produziert und konsumiert Leistungen. - Die Prozessführung setzt Ziele (Soll-Werte) für den Prozess fest, misst die Ausführung des Prozesses anhand ausgewählter Führungsgrößen und vergleicht das Ergebnis (Ist) mit den Vorgaben (Soll). Unternehmensstruktur Geschäftsfelder

Märkte

Applikationen

Geschäftsstrategie

Erfolgsfaktoren

Produkte

Prozesse

ff

η

Ίi

organisatorische Einheiten

Teilprozesse

Transaktionen

Prozeß Leistungen

Aufgaben

Entitätstypen

Η Verantwortlichkeiten

Dialogflüsse

I 1w I I

Zugriffsrechte

Informationssystem

Bildschirmmasken

Attribute

Bild 3-5: Ebenen des Business Engineering nach H. ÖSTERLE640

Ein (Geschäfts-)Prozess ist in diesem Sinne eine Abfolge zusammengehörender Funktionen im Unternehmen, die durch einen Informationsaustausch miteinander verknüpft sind.647 P. STAHLKNECHT unterscheidet Arbeitsabläufe konventioneller Art - wie bspw. die Fakturierung oder die Durchführung der Lohn-/Gehaltsabrechnung, die im Normalfall auf einen Unternehmensbereich oder eine Abteilung beschränkt sind - von Geschäftsprozessen, »die sich bereichs- bzw. abteilungsübergreifend aus einer am Wertschöpfungsprozess ausgerichteten

640

ÖSTERLE, H.: Business Engineering: Prozeß- und Systementwicklung, Band I: Entwurfstechniken, a.a.O., S. 19. 641 v g l . ESSWEIN, W.: Geschäftsprozesse und Geschäftsprozeßanalysen, in: ZILAHI-SZABÖ, M.G. (Hrsg.): Kleines Lexikon der Informatik und Wirtschaftsinformatik, München/Wien 1995, S. 218(218-220).

272

3 Sichten der Softwareentwicklung

Kette von Vorgängen zusammensetzen... «642. Beispiele für solche Geschäftsprozesse sind: - die Abwicklung einer Kundenbestellung in einem Handelsunternehmen oder - der Abschluss eines Versicherungsvertrags in einer Versicherungsgesellschaft.045 Dieser Sichtweise liegt das Verständnis der betrieblichen Wertschöpfungskette zugrunde, die das Unternehmen als Transformator von eingehenden Produktionsfaktoren in Leistungen sieht. Das Unternehmen wird als ein System von miteinander verknüpften Geschäftsprozessen verstanden, die der Realisierung der Unternehmensziele dienen. Im Gegensatz zu klassischen Vorgehensweisen, die eher eine statische, strukturorientierte Sichtweise auf das Unternehmen unterstützen, z.B. die Aggregation von Aufgaben nach funktionalen Gesichtspunkten, liegt der Geschäftsprozessmodellierung eine eher dynamische Sichtweise bezüglich möglicher Umstrukturierungen und ein ablauforientiertes Verständnis im Hinblick auf die Funktionen zugrunde.0** Dass Informationssysteme, die aus einer daten-, funktions- oder organisationsorientierten Perspektive konzipiert und implementiert sind, den Anforderungen der Prozessorientierung nicht genügen, lässt sich unschwer nachvollziehen. Die Prozessorientierung fordert Informationssysteme, die ihren Schwerpunkt nicht auf der Datenhaltung haben, einzelne betriebliche Funktionen isoliert unterstützen oder organisatorische Aspekte in den Vordergrund stellen, sondern stattdessen einen kompletten Prozess von Anfang bis Ende durchgängig und flexibel unterstützen. Es haben sich mittlerweile eine Vielzahl verschiedener Methoden des Business Process Engineering herausgebildet.645 Zwei im deutschen Sprachraum besonders verbreitete Ansätze, die die Informationssystemebene berücksichtigen, werden im folgenden kurz dargestellt. Es handelt sich hierbei um den Ansatz des Semantischen Objektmodells (SOM) von O.K. FERSTL und E.J. SINZ sowie um die Architektur integrierter Informationssysteme (ARIS) v o n A . W . SCHEER.

642

STAHLKNECHT, P.: Einfuhrung in die Wirtschaftsinfoimatik, a.a.O., S. 254. Vgl. STAHLKNECHT, P.: Einfuhrung in die Wirtschaftsinformatik, a.a.O., S. 254 f. 644 YGI ESSWEIN, W.: Geschäftsprozesse und Geschäftsprozeßanalysen, a.a.O., S. 218. 645 Eine Übersicht über den aktuellen Stand der Methoden der Geschäftsprozessmodellierung liefern HESS, T.; BRECHT, L.; ÖSTERLE, H.: Stand und Defizite der Methoden des Business Process Redesign, in: Wirtschaftsinformatk: Vol. 37, 5/1995, S. 480-486 (480-486). 643

3.4 Prozessorientierte Software-Entwicklung

273

Beim SOM-Ansatz646 werden - von den Unternehmenszielen ausgehend Prozesse abgegrenzt. Bei diesen handelt es sich entweder um Transaktionen647 oder um den Austausch von Leistungen oder Informationen zwischen betrieblichen Objekten. Sowohl für die Objekte als auch für die Transaktionen existiert ein hierarchisches Zerlegungskonzept. Als wesentliches Darstellungsmittel steht zum einen ein sogenanntes Interaktionsdiagramm zur Verfügung. Hier werden Transaktionen als gerichtete Kanten zwischen Objekten verwendet. Das andere wichtige Beschreibungsmittel sind die sog. Vorgangs/Ereignisnetze, die auf der Basis der Petri-Netz-Technik64Ä die Verhaltensaspekte der Objekte darstellen. Die Geschäftsprozesse grenzen sich gegenseitig nach den Leistungsflüssen und den diese steuernden Informationsflüssen ab. Nach abgeschlossener Modellierung wird eine Entscheidung über eine Automatisierung von Aufgabentypen und Informationsflüssen getroffen. Diese werden im sog. konzeptuellen Objektschema, einer objektorientierten Erweiterung des SERM, abgebildet.649 A.-W. S C H E E R erarbeitet im Rahmen des ARIS-Ansatzes650 ein Vorgehensmodell zur prozessorientierten Entwicklung von Informationssystemen. Die bestimmende Komponente des ARIS-Ansatzes zur Entwicklung von Informationssystemen ist die sog. ARIS-Architektur, wie sie in Bild 3-6 dargestellt ist. Das ARIS-Vorgehensmodell zur Software-Entwicklung unterteilt sich in die drei Hauptphasen oder Ebenen Fachkonzept, DV-Konzept und Implementierung. Diese drei Ebenen werden auf vier verschiedene Sichten angewendet, die 646

647

648

649

650

Zur Darstellung des SOM-Ansatzes siehe auch ESSWEIN, W.: Geschäftsprozesse und Geschäftsprozeßanalysen, a.a.O., S. 220. Unter Transaktion soll hier die mit einer Nachricht verbundene Übertragungs- oder Verarbeitungstätigkeit verstanden werden. Vgl. O.V.: Transaktion, in: ZILAHI-SZABO, M . G . (Hrsg.): Kleines Lexikon der Informatik und Wirtschaftsinformatik, München Wien 1995, S. 565 (565). Zu einer Einfuhrung in die Technik der Petri-Netze siehe ROSENSTENGEL, B.; WINAND, U . : Petri-Netze: Eine anwendungsorientierte Einführung, 2., ergänzte und verbesserte Auflage, Braunschweig 1983 sowie BAUMGARTEN, B . : Petri-Netze: Grundlagen und Anwendungen, Mannheim/Wien/Zürich 1990. Zu einer detaillierteren Darstellung des SOM-Ansatzes siehe bspw. FERSTL, O.K.; SINZ, E.J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen, in: Wirtschaftsinformatik: Vol 37, 3/1995, S. 209-220 (209-220) sowie FERSTL, O.K.; MANNMEUSEL, T.: Gestaltung industrieller Geschäftsprozesse, in: Wirtschaftsinformatik: Vol. 37, 5/1995, S. 446-458 (446-458). Zu den folgenden Ausführungen zum ARIS-Ansatz vgl. SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O. sowie SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 1-89.

274

3 Sichten der Softwareentwicklung

gleichgewichtig behandelt werden. Die Basis bilden die Funktions-, die Organisations- und die Datensicht. Eine wesentliche Eigenschaft dieser Architektur ist, dass die einzelnen Sichten nicht isoliert behandelt werden, sondern in einer vierten Sicht, der sog. Steuerungssicht, auch deren Beziehungen untereinander abgebildet werden. Die Steuerungssicht stellt somit die Verbindung zwischen den einzelnen Sichten dar.

Daten

Bild 3-6:

Steuerung

Funktion

ARIS-Architektur651

Der ARIS-Ansatz zur Software-Entwicklung, der die Gestaltung von Geschäftsprozessen unterstützt, basiert auf dem Begriff der Vorgangskette, die A.W. SCHEER gleichsetzt mit den Begriffen Prozesskette und Geschäftsprozess (Business Process).052 Ein typisches Beispiel für eine Vorgangskette ist eine geschlossene Auftragsbearbeitung von der Auftragsannahme über die Materialwirtschaft und die Produktion bis hin zum Versand und zur Bezahlung. »Element einer Vorgangskette ist der einzelne Vorgang. Ein Vorgang ist ein zeitverbrauchendes Geschehen, das durch ein Ereignis gestartet wird und durch ein Ereignis beendet wird. Start- und Ergebnisereignisse definieren damit 651

652

SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 4. sowie SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 17. Vgl. SCHEER, A.-W.: EDV-orientierte Betriebswirtschaftslehre, a.a.O., S. 34.

3.4 Prozessorientierte Software-Entwicklung

275

Beginn und Ende des Vorgangs...«053. Gegenstand der Vorgangsbearbeitung ist i.d.R. die Transformation eingesetzter Werkstoffe in Produkte oder ausgehende Werkstoffe. Parallel zum Prozess der Werkstofftransformation und eng mit diesem verbunden vollzieht sich der Prozess der Informationstransformation. Hierbei handelt es sich um »die durch den physischen Produktionsprozess verursachte Veränderung von Daten«654. Das ARIS-Modell konzentriert sich auf diesen informatorischen Transformationsprozess. Wegen der engen Verbindung beider Prozesse wird jedoch der güterorientierte Transformationsprozess implizit berücksichtigt. Als grafisches Beschreibungsmittel zur Darstellung von Geschäftsprozessen wurde im Rahmen von ARIS die sog. ereignisorientierte Prozesskette (EPK) entwickelt (vgl. Bild 3-7). Sie ist eine Kombination von Bedingungs-EreignisNetzen der Petri-Netz-Theorie mit Verknüpfungselementen, wie sie z.B. von der stochastischen Netzplan-Technik GERT055 verwendet werden. Die EPKDarstellung greift auf die bereits beschriebenen Elemente Ereignis und Funktion (Vorgang) zu, die miteinander durch logische Operatoren in Knoten verknüpft werden. Von einem Ereignis kann eine oder können mehrere Funktionen parallel ausgehen, auch kann der Abschluss mehrerer Funktionen zu einem Ereignis fuhren. Bei den logischen Operatoren wird zwischen der Verknüpfung der Eingänge und der Ausgänge von Ereignissen unterschieden. Als Operatoren werden das logische »und«, »oder« sowie »exklusiv oder« verwendet. Können mit alternativen Ausgängen Wahrscheinlichkeiten verbunden werden, so werden diese an den ausgehenden Kanten eingetragen. Für den Fall komplexerer Beziehungen können in einem Operatorknoten auch Entscheidungstabellen für Ein- und Ausgänge hinterlegt werden. Sofern nur ein Einbzw. Ausgang auftritt, entfällt der Knoten komplett. Bild 3-7 zeigt die grundsätzliche Darstellungsform der Elemente Ereignis, Funktion und Knoten sowie einige Fälle möglicher Ablaufstrukturen. Generell ist auch eine direkte Verbindung unterschiedlicher Operatoren zulässig.650

653 654 655

SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 4. SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 13. Zu GERT vgl. PRITSKER, A.A.B.; HAPP, W.W.: GERT: Graphical Evaluation and Review Technique, Part I. Fundamentals, Journal of Industrial Engineering, Vol. 17, 5/1966, S. 267274 sowie PRITSKER, A.A.B.; WHITEHOUSE, G.E.: GERT: Graphical Evaluation and Review Technique, Part II. Probabilistic and Industrial Engineering Applications, Journal of Industrial

656

Engineering,

V o l . 17, 6 / 1 9 6 6 , S. 2 9 3 - 3 0 1 .

Zusätzlich zur Ereignissteuerung kann die EPK-Darstellung um den Datenfluss ergänzt werden. Dabei werden jeweils nur die wichtigsten Attribute als Eingangs- und Ausgangsdaten der Informationsobjekte angegeben. Auf diese Erweiterung wird aber im Rahmen dieses

3 Sichten der Softwareentwicklung

276 Grundsymbole:

Operatoren: Funktion

Ereignis

Knoten

Λ

und

V

oder

V

exklusiv oder

Beispiele möglicher Ablaufstrukturen:

E1

F1 Wenn das Ereignis E1 eingetreten ist, startet die Funktion F1. Wenn die Ereignisse E1 UND E2 eingetreten sind, startet die Funktion F1.

Wenn das Ereignis E1 ODER E2 eingetreten ist, startet die Funktion F1.

Wenn die Ereignisse E1 UND E2 eingetreten sind, starten die Funktionen F1 UND F2.

Bild 3-7: Darstellungselemente

Wenn ENTWEDER das Ereignis E1 O D E R E2 eingetreten ist, startet die Funktion F1.

Wenn das Ereignis E1 ODER E2 eingetreten ist, startet ENTWEDER die Funktion F1 O D E R F2.

für EPK nach A. W. SCHEER, Teil 1

Überblicks über den ARIS-Ansatz nicht weiter eingegangen. Vgl. hierzu SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 53 f.

3.4 Prozessorientierte Software-Entwicklung

277

Mit Hilfe der EPK können beliebige Geschäftsprozesse modelliert werden. Bild 3-9 zeigt das Beispiel einer Angebotskalkulation in EPK-Darstellung. Zusätzlich zur Ereignissteuerung kann die EPK-Darstellung um den Datenfluss ergänzt w e r d e n . D a b e i werden jeweils nur die wichtigsten

057

In A n l e h n u n g an: SCHEER, A . - W . : W i r t s c h a f t s i n f o r m a t i k , a.a.O., S. 50-52.

278

3 Sichten der Softwareentwicklung

Attribute als Eingangs- und Ausgangsdaten der Informationsobjekte angegeben. Informationsobjekte können Ereignisse sowie Zustände des Informationsumfeldes sein. Bild 3-10 zeigt noch einmal das Beispiel der Angebotskalkulation, jetzt ergänzt um den Datenfluss. Diesem Diagramm kann auch die Darstellungsweise der Informationsobjekte und der Datenelemente entnommen werden.

658

659

G. KELLER spricht in diesem Zusammenhang treffend von „schlanken" und „erweiterten" EPK. Vgl. KELLER, G.: Eine einheitliche betriebswirtschaftliche Grundlage für das Business Reengineering, in: BRENNER, W.; KELLER, G. (Hrsg.): Business Reengineering mit Standardsoftware, Frankfurt(Main)/New York 1995, S. 54-61 (45-66). SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 52.

3.4 Prozessorientierte Software-Entwicklung

279

In einem weiteren Schritt kann eine Zuordnung der Funktionen und Daten auf einzelne Organisationseinheiten erfolgen. Auf eine grafische Darstellung wird an dieser Stelle jedoch verzichtet.000

Bild 3-10: Beispiel einer Angebotskalkulation in EPK-Darstellung mit Datenfluss661 Zusammenfassend lässt sich festhalten, dass die geschäftsprozessorientierten Ansätze zur Software-Entwicklung versuchen, Informationssysteme zu entwickeln, die eher dazu geeignet sind, die Bedürfnisse der heutigen Unternehmen (Kundenorientierung, Flexibilität, Konzentration auf 660

Vgl. hierzu SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 48 u. 57-60.

661

SCHEER, A.-W.: Wirtschaftsinfoimatik, a.a.O., S. 53.

3 Sichten der Softwareentwicklung

280

Kern(geschäfts)prozesse) bei der Bewältigung von Aufgabenkomplexen zu erfüllen. Dabei fassen sie einzelne betriebliche Funktionen zu Prozessketten zusammen und berücksichtigen auch Aspekte der Datenhaltung und Organisation. Im Wesentlichen wollen prozessorientierte Ansätze die Entwicklung von Informationssystemen unterstützen, die Unternehmen entlang ihrer Wertschöpfungsketten möglichst optimal unterstützen. 3.5 Organisationsorientierte Software-Entwicklung

Die Organisationssicht ist ebenfalls eine Software-Entwicklungssicht. Man beschreibt hier ein Informationssystem ausgehend von Organisationseinheiten (z.B. personelle und maschinelle Aufgabenträger) mit ihren Beziehungen und Strukturen. Zwischen dem Organisationsmanagement und dem Informationsmanagement bestehen enge Beziehungen, da - Informationssysteme zur Unterstützung von organisatorischen Abläufen eingesetzt werden und - Organisationsstrukturen sich durch den Einsatz von Informationssystemen ändern können. Die Konzeption von Informationssystemen enthält als ein Ziel, den Aufbau der Organisationsstruktur und die Ablaufstrukturen optimal zu gestalten, denn der Einsatz von Informationssystemen stellt immer eine Chance dar, Organisationsstrukturen zu überprüfen und ggf. zu verbessern. Er ermöglicht oftmals die Realisierung von organisatorischen Lösungen, die ohne den Einsatz moderner Datenverarbeitung nicht anwendbar wären.662 Heute erleben wir eine Renaissance der Organisation, insbesondere der Ablauforganisation, wie die Diskussion um das Business Process Redesign zeigt.663 Bei der Gestaltung von Informationssystemen aus Organisationssicht werden folgende Ziele verfolgt: - Der Koordinations- und Kommunikationsaufwand soll möglichst gering gehalten werden, um die Wirtschaftlichkeit des DV-Einsatzes zu gewährleisten.

662 VGL P I C O T , Α . ; REICHWALD, R . ; WIGAND, R . T . : D i e g r e n z e n l o s e U n t e r n e h m u n g . I n f o r m a t i o n ,

Organisation und Management, Wiesbaden 1996, S. 5. 663

Vgl.

ÖSTERLE, H . ;

SAXER, R ; HÜTTENHAIN,

T.:

Organisatorisches

Gestaltung von Geschäftsprozessen, in: Wirtschaftsinformatik: 477).

Monitoring

in

der

Vol. 36, 5/1994, S. 466 (465-

3.5 Organisationsorientierte Software-Entwicklung -

281

Die Zuordnung von Daten und Funktionen bzw. Prozessen zu Organisationseinheiten muss festgelegt werden. In diesem Zusammenhang stellt sich die Frage, welcher Organisationseinheit welche Funktionen und Daten zur Verfugung gestellt werden müssen. Denn »auf der IS-Ebene regelt der Organisationsentwurf Details wie Kompetenzen und Verantwortlichkeiten, Formulare etc.«664. Dies beinhaltet gleichzeitig die Definition des Zuständigkeits- und Berechtigungskonzeptes (Zugriffsmöglichkeiten, Verantwortlichkeit für Update der Daten etc.) und bildet außerdem die Grundlage für einen Entwurf der Netztopologie.065 Neben Berechtigungen und Verantwortlichkeiten der Benutzer kann weiterhin die Differenzierung nach Benutzerklassen (gelegentliche Benutzer, intensive Benutzer, Experten) von Bedeutung für die Gestaltung von Informationssystemen sein.600

Typische Organisationseinheiten sind die Träger der von einem Informationssystem zu unterstützenden Aufgaben. Organisationseinheiten werden meist entsprechend den betrieblichen Funktionsbereichen, Entscheidungshierarchien und Weisungsbefugnissen strukturiert.007 Im Rahmen dieser Strukturierung ist darauf zu achten, dass keine relevanten Organisationseinheiten übersehen werden. Als Darstellungsmöglichkeiten für die organisatorische Sicht bieten sich an: -

Organigramme, mit denen man Organisationsstrukturen anhand von Weisungsbefugnissen abbildet. Die Weisungsbefugnisse bestimmen häufig auch die Berichtswege innerhalb der Organisation. Werden in den Organigrammen funktionale Zuständigkeiten erfasst, bildet das Organigramm auch die Verteilung betrieblicher Aufgaben ab. Als Gliederungsprinzipien lassen sich z.B. das Verrichtungsprinzip und das Marktprinzip anwenden.605 Typische Ebenen eines Organigrammes sind das Werk, die Hauptabteilung, die Abteilung, die Gruppe und die einzelne Stelle (Person). - sonstige Darstellungsmöglichkeiten: - Stellenbeschreibungen, - Aufgabenstrukturbilder, - Funktionendiagramme und 664

ÖSTERLE, H.: Business Engineering: Prozeß- und Systementwicklung, Band I, a.a.O., S. 35. Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 64. 666 Vgl. SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 93. 667 Vgl. SCHEER, A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 89. 668 v g i BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 208 f. 665

3 Sichten der Softwareentwicklung

282

-

Soziogramme.

Der Entwurf von Informationssystemen war lange an der traditionellen funktionsorientierten Organisationsstruktur orientiert. Daraus ergab sich das organisatorische Problem, dass der Zusammenhang zwischen einzelnen Funktionen, u.a. durch die Verwendung gleichartiger Datenobjekte, nur schwer herzustellen war. Auch andere Möglichkeiten, z.B. die Organisation nach Gebieten, Produkten und Prozessen zu gliedern, erwiesen sich nicht unbedingt als besser. Als Basis für die Gestaltung von Informationssystemen aus organisatorischer Sicht gibt es hier keine eindeutig beste Organisationsstruktur. Es können sogar durchaus mehrere Gliederungsmöglichkeiten nebeneinander von Bedeutung sein.609 Obwohl die Entwicklung der organisatorischen Sicht eng mit der Gestaltung der Informationsverarbeitung zusammenhängt, ist nach A.W. SCHEER die Bildung von Organisationseinheiten eigentlich keine Aufgabe des Informationsmanagements sondern der Funktionsbereiche »Organisation« und/oder »Personal«, auf deren Kenntnisse und Arbeitsergebnisse zurückgegriffen werden muss.070 H. ÖSTERLE sieht die Beziehungen enger, wie sie auch für den ganzheitlichen Ansatz notwendigerweise zugrunde gelegt werden müssen: »Die Informatisierung beschränkt sich nicht mehr auf die Computerunterstützung bestehender Abläufe, sondern ermöglicht radikale Veränderungen der Organisationen. Daher soll sich der Organisationsentwurf vom IST-Zustand lösen, sämtliche Aspekte der Geschäftsstrategie überprüfen und grundlegend neue Ansätze suchen«077. Darauf aufbauend versteht H. ÖSTERLE unter Organisationsentwurf den Entwurf von Prozessen.672 Zur Organisationsmodellierung empfiehlt sich die folgende Vorgehensweise: - Aufbau von DV-gestützten Benutzeranforderungen in Form von Benutzerkatalogen ausgehend von Organigrammen, Stellenbeschreibungen etc. (Pro Anwendungsklasse und Benutzer werden Merkmale zur Klassifizierung ermittelt und festgehalten, wie z.B. die Zuständigkeit oder Verantwortlichkeit der Benutzer.) - Zuordnung der identifizierten Funktionen, Prozesse und Datenobjekte zu bestimmten Organisationseinheiten. 669

Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 26 f. 670 YGJ SCHEES A.-W.: Architektur integrierter Informationssysteme, a.a.O., S. 89. 671

ÖSTERLE, H.: Business Engineering Prozeß- und Systementwicklung, Band I: Entwurfstechniken, a.a.O., S. 36.

672

Vgl. ÖSTERLE, H.: Business Engineering Entwurfstechniken, a.a.O, S. 37 ff.

Prozeß-

und Systementwicklung,

Band I:

3.5 Organisationsorientierte Software-Entwicklung

283

Die Bedeutung der Organisationssicht für die Gestaltung von ganzheitlichen Informationssystemen wird im Rahmen einer Verknüpfung mit den verschiedenen anderen Sichten besonders deutlich. - Verknüpfung von Prozessen und Funktionen mit Organisationseinheiten Hier erfolgt eine Zuordnung von identifizierten Prozessen oder Teilfunktionen zu Organisationseinheiten des Organigrammes, z.B. mit einer Differenzierung in »verantwortlich«, »aktiv beteiligt« oder »mit einbezogen«.073 Dies kann in Form einer -

Organisations-Funktions-Matrix bzw. Organisations-Prozess-Matrix

erfolgen. Zur Optimierung von Arbeitsabläufen werden häufig auch Rasterdiagramme angewandt, bei denen in den Zeilen einzelne Arbeitsschritte, also Tätigkeiten bzw. Funktionen und in den Spalten die beteiligten Organisationseinheiten (Stellen bzw. Arbeitsplätze) aufgeführt sind.674 - Verknüpfung von Daten mit Organisationseinheiten Die Verknüpfung der Organisation mit den Datenobjekten kann in einer Daten-Organisations-Matrix erfolgen, wobei den Organisationseinheiten Prädikate wie »allgemein zuständig«, »berechtigt«, »verantwortlich für update«, oder spezielle Berechtigungen für das Anlegen, Löschen, Ändern oder Lesen von Datenobjekten zugeordnet werden. Bild 3-11 zeigt eine solche Organisations-Daten-Matrix. Ausgegangen wird wiederum von einer Reparaturwerkstatt, deren Organisationseinheiten in Form eines Organigrammes abgebildet sind. Die Matrix legt die Zugriffsberechtigungen der Organisationseinheiten in Bezug auf die in den Zeilen dargestellten Datenobjekte fest. Die Organisationssicht stellt insofern eine Sicht dar, die nur als Teilsicht in Verbindung mit anderen Sichten Bedeutung haben kann.

673 674

Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 48 und S. 110. Vgl. STAHLKNECHT, P . : Einführung in die Wirtschaftsinformatik, a.a.O., L.J.: Systemplanung 1,4. Auflage, München/Wien 1994, S. 6.

S. 2 6 6 ; HEINRICH,

3 Sichten der Softwareentwicklung

284

Untemehmensführnng

K

Organisationsxeinheit

Reparaturstelle

Auftragsannahme

ι

1

Lager

Daten- N. Objekt \

Fakturierung

Controlling

1 Werkstatt

Kunde

C, D, U, R

R

R

U, R

R

Auftrag

C, D, U, R

R

R

U, R

R

Material

R

C, D, U, R

U, R

R

R

Lagerbestand

R

C, D, U, R

R

R

R

Maschine

R

R

C, D, U, R

R

R

Rechnung

R

R

R

C, D, U, R

R

Create (C), Delete (D), Update (U), Read (R)

Bild 3-11:

Organisations-Daten-Matrix

3.6 Objektorientierte Softwareentwicklung Bei der funktionsorientierten Softwareentwicklung wird zur Erstellung eines Programmes neben dem Funktionsalgorithmus genaue Kenntnis der Datenstrukturen der benötigten Daten gefordert. Sind später Änderungen durchzuführen, z.B. in den Datenstrukturen, so ist schwer überschaubar, welche Teile der Programme davon betroffen sind. Solche Probleme sollen durch die objektorientierte Softwareentwicklung vermieden werden. Objektorientierung bedeutet, dass man Dinge die zusammengehören auch zusammen beschreibt. Und wenn Zustände mit den Zustandsveränderungsmaßnahmen zusammen gesehen werden sollen, gibt es keinen Grund, die Zustände im Datenmodell und die Zustandsveränderungsmaßnahmen im Funktionsmodell abzubilden. Hierfür bietet es sich an, eine zusammenfassende Einheit, das Objekt, zu entwickeln, bei dem die Trennung von Daten und Funktionen aufgehoben wird. Als Beispiel für ein Objekt lässt sich ein Lager anführen. Dem Objekt »Lagerraum« liegt eine bestimmte Datenstruktur (z.B. Lagerkapazität, Lagerbestand) zugrunde. Weiterhin enthält das Objekt Methoden (z.B. Ware

3.6 Objektorientierte Softwareentwicklung

285

einliefern, Ware ausliefern), die auf der oben beschriebenen Datenstruktur arbeiten. Um für die objektorientierte Vorgehensweise Verständnis zu erzeugen, sollen im folgenden zunächst einige begriffliche Grundlagen gelegt werden, bevor auf Modellierungstechniken eingegangen wird. Dabei wird es erforderlich sein, zunächst die bei dieser Modellierungstechnik verwendeten Modelle und die Zusammenhänge zwischen den Modellen zu verdeutlichen, bevor der Prozess der Softwareerstellung mit der Modellverfeinerung, der Analyse und dem Design beschrieben wird. 3.6.1 Begriffliche Grundlagen Bei der Objektorientierung gibt es gewisse Analogien zur traditionellen Programmierung, wenn man sich z.B. einerseits die Objekte und andererseits die Entities anschaut. Um hier Verwechslungen zu vermeiden, sollen als erstes die notwendigen Begriffe erläutert werden. Objekt:675 Ein Objekt ist eine in sich abgeschlossene Einheit, die durch Daten beschrieben ist und Funktionen enthält, die es zur Verarbeitung der Daten benötigt.670 Die Daten bestimmen den Status oder den Zustand, die Methoden das Verhalten des Objekts, z.B. auf einen äußeren Einfluss. Die Kommunikation zwischen den Objekten erfolgt über den Austausch von Nachrichten. Wenn ein Objekt eine Nachricht erhält, führt es die gleichnamige Methode077 aus, welche den Status eines Objektes verändern kann. Die Vorgehensweise ist also analog zur traditionellen Programmierung, bei der Statusveränderungen über Funktionsaufrufe realisiert werden. Beispiel: Kauf eines Artikels vom Lager Objekt: Kunde Daten:

675

676

677

Kunden-Nr. Name

In Anlehnung an VETTER, M . : Objektmodellierung: eine Einfuhrung in die objektorientierte Analyse und das objektorientierte Design, Stuttgart 1995, S. 12 f. Es ist auch denkbar, dass ein Objekt nur Funktionen enthält. Der umgekehrte Fall, dass ein Objekt nur eine Datenstruktur definiert, ist nicht möglich, da immer mindestens die Zugriffsfunktionen auf die Datenstruktur des Objektes definiert sein müssen. Die Begriffe Methode und Funktion werden im Bereich der Objektorientierung synonym verwendet.

3 Sichten der Softwareentwicklung

286

Funktionen:

Objekt: Lager Daten:

Funktionen:

Ware kaufen Ware reklamieren Ware zurückgeben

Lagerkapazität Lagerbestand Ware einliefern Ware ausliefern

Ein Kunde kauft einen Artikel; es wird vom Objekt »Kunde« die Methode »Ware kaufen« ausgeführt. Dazu ist es notwendig, dass die Ware aus dem Lager ausgeliefert wird. Folglich schickt das Objekt »Kunde« dem Objekt »Lager« die Nachricht »Ware ausliefern«. Daraufhin wird vom Objekt »Lager« die entsprechende Methode ausgeführt. Da man nicht in jedem Objekt alle Daten und Funktionen fuhren will, wurde die Möglichkeit geschaffen, sog. Vererbungseffekte zu nutzen. Danach werden beim Übergang vom funktionsorientierten zum objektorientierten Ansatz die Daten mit ihren Beziehungen und die Funktionen, die über Aufrufe auf die Daten zurückgreifen, ersetzt durch die Objekte. Diese enthalten die Daten und Funktionen und können Daten, Funktionen und Beziehungen erben und Nachrichten austauschen. Auf die Verkapselung, einem besonderen Merkmal der Objektorientierung soll besonders eingegangen werden, da dieses ein Prinzip ist, das den objektorientierten Ansatz besonders kennzeichnet. Es ist jedoch auch als eines der generellen Prinzipien zu sehen. Die Objektkapselung bedeutet, dass ein Objekt mit seinen Daten und Funktionen nur so weit nach außen beschrieben wird, wie es notwendig ist. Details z.B. über Algorithmen bleiben Objektgeheimnis, um den Nutzer von zu vielen Details zu entlasten. Der Nutzer soll sich an der Eingabe- und Ausgabebeschreibung und der Leistungsbeschreibung der Schnittstellen nach außen orientieren. Auf diese Art erhält man Bausteine, bei denen eher die Datenintegrität gewährleistet und die Wartung der Daten und Funktionen durchgeführt werden kann, da stets nur das Objekt und nicht die kompletten Sichten (Datensicht, Funktionssicht) geändert werden müssen. Eine Veränderung der internen Funktionen eines Objektes hat zudem keine Auswirkungen auf das Verhalten des Objektes nach außen.

3.6 Objektorientierte Softwareentwicklung

287

Nach BALZERTÖ7Ä ist ein Objekt durch folgende Merkmale gekennzeichnet: -

-

-

-

Ein Objekt ist ein individuelles Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt. Jedes Objekt ist eindeutig identifizierbar. Das Identifikationsmerkmal wird bei der Generierung automatisch vergeben. Ein Objekt besitzt individuelle Eigenschaften, die sich in Daten (Variablen, Attribute) sowie Verhalten (Methoden) gliedern lassen. Die Kommunikation zwischen Objekten erfolgt ausschließlich durch das Senden von Nachrichten. Das Verhalten eines Objekts wird durch seine Methoden bestimmt. Erhält ein Objekt eine Nachricht, so wählt es eine geeignete Methode aus, welche ein Ergebnis ermittelt und dieses bei Bedarf an das Sender-Objekt zurückschickt. Ein Objekt kann mehrere Zustände einnehmen und in jedem Zustand anders reagieren. Der Zustand eines Objekts wird mittels Daten (Variablen, Attribute) festgehalten. Ein Objekt verkapselt sowohl seine Daten (Variablen, Attribute) als auch seine Methoden und verkehrt mit der Außenwelt über eine wohldefinierte Schnittstelle. Ein Objekt ist vergleichbar mit einer Entität im Entitäten-Beziehungsmodell (ERM).

Aufbauend auf dem Objekt besteht das Bestreben der Objektorientierung darin, Eigenschaften möglichst früh zusammenzufassen und zu klassifizieren. Das fuhrt zu den Begriffen Klasse, Generalisierung - Spezialisierung, Aggregation, Vererbung und Polymorphismus, die nacheinander erläutert werden. Klasse:679 Eine Klasse besteht aus einer Menge von Objekten mit denselben Schnittstellen, derselben Struktur und demselben Verhalten. Gehören Objekte derselben Klasse an, so müssen die Gemeinsamkeiten nicht in jedem Objekt, sondern nur einmal in der Klassenbeschreibung definiert werden.050 Eine Klasse ist somit eine Art Muster, nach dem Objekte gleicher Art entwickelt werden

678

In Anlehnung an BALZERT, H.: Objektorientierte Software-Entwicklung, Beitrag zur Fachkonferenz Objektorientierung, Institute for International Research, Köln 1993, zitiert und übernommen von VETTER, M . : Objektmodellierung, a.a.O., S. 3 0 . 679 Vgl. POMBERGER,G.;BLASCHEK,G.: Software-Engineering, München/Wien 1993, S. 187. 680 vgl. hierzu auch die Ausführungen zu den abstrakten Datentypen, Kap. 5.1.1.3.

288

3 Sichten der Softwareentwicklung

können. Generell gehört aber ein Objekt genau zu einer Klasse.657 Objekte werden häufig auch als Instanz einer Klasse bezeichnet. B e z i e h u n g : Z w i s c h e n Klassen können Beziehungen/Assoziationen aufgebaut werden, die als Kanten dargestellt werden. Dabei wird unterschieden zwischen: -

einfachen Beziehungen, die permanent zwischen den einzelnen Objekten der Klassen bestehen (Beispiel: Mann - Ehe - Frau), - konditionalen Beziehungen, die vorliegen, wenn jederzeit ein Objekt der Klasse Α mit einem oder keinem Objekt der Klasse Β in Beziehung steht (Beispiel: Kunde - Beratung - Verkäufer), - komplexen Beziehungen, wenn ein Objekt der Klasse Α jederzeit mit mindestens einem Objekt der Klasse Β in Beziehung steht (Beispiel: Lehrer Unterricht - Schüler), - komplexen konditionellen Beziehungen, wenn jedes Objekt der Klasse Α mit beliebig vielen Objekten der Klasse Β in Beziehung steht (Beispiel: Spender - spenden - Almosenempfänger). Jede dieser Beziehungen ist wieder durch Attribute beschrieben, deren Ergebnisausprägungen als Ereignisklasse bezeichnet werden. Vererbung:633 Das Prinzip der Vererbung dient dazu, Gemeinsamkeiten von verschiedenen Klassen zu erfassen und zu beschreiben. Dazu bildet man mit den Klassen eine hierarchische Klassenstruktur, in der jede Klasse die Attribute und Methoden der darüberliegenden Klasse erbt. Eine darüberliegende Klasse heißt Superklasse und eine darunterliegende Subklasse. Entsprechend den üblichen Hierarchiebäumen kann eine Superklasse Funktionen und Daten an mehrere Klassen vererben, wobei die Subklassen i.d.R. über weitere Daten und Methoden verfugen. Je nachdem, ob man Top-down oder Bottom-up vorgeht, liegt eine Generalisierung oder Spezialisierung vor. Dadurch, dass in den Superklassen die Daten für die Subklassen zur Verfügung stehen, tritt mit dem Vererbungsprinzip eine erhebliche Daten- und Funktionsreduktion ein. Das fuhrt allerdings auch dazu, dass die Superklasse in einigen Fällen nur noch Datenstrukturen und Funktionen bereitstellt. Von dieser Klassenbeschreibung können aber keine sinnvollen Objekte abgeleitet werden, da die Informationen dafür nicht ausreichen. Solche Klassen bezeichnet man als abstrakte Klassen.

681

Vgl. VETTER, M.: Objektmodellierung, a.a.O., S. 61. 682 Yg] hjerzu VETTER, M.: Objektmodellierung, a.a.O., S 61. 683 Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 339.

3.6 Objektorientierte Softwareentwicklung

289

Klassen, aus deren Beschreibung Objekte abgeleitet werden können, nennt man konkrete

Klassen.684

Bei der Vererbung können folgende Fälle auftreten: 1. Fall: Eine Superklasse umfasst Subklassen, die keine Überschneidung haben (Beispiel Superklasse: Mitarbeiter, Subklassen: Männer, Frauen). 2. Fall: Eine Superklasse umfasst Subklassen, jedoch sind diese nicht überschneidungsfrei (Beispiel Superklasse: Mitarbeiter, Subklasse: über Lehre ausgebildete Mitarbeiter, Akademiker, Schnittmenge: doppelt ausgebildete Mitarbeiter). 3. Fall: In eine Superklasse fallen überschneidungsfreie Subklassen, doch ist sie nicht vollständig überdeckt. Beispiel Superklasse: Mitarbeiter, Subklassen: Schlosser, Schweißer. Zusätzlich gibt es noch weitere Mitarbeiter, wie z.B. Pförtner. 4. Fall: In eine Superklasse fallen Subklassen, die nicht überschneidungsfrei sind und die diese Superklasse nicht vollständig überdecken (Beispiel Superklasse: Mitarbeiter, Subklassen: Sprachkenntnisse englisch, französisch). 1. Fall:

3 . Fall:

f \

v,*

·

J

· ^ ^ *

.

λ

)

4-Fall:

2 . Fall: ( V

··

V

f· ---* *

·

· / ^ Γ Γ λ λ v / v V *)

(

ν

ν

·

·

*

^ ^

^

)

Bild 3-12: Fälle der Vererbung

In allen diesen Fällen können z.B. alle Funktionen der Mitarbeiterverwaltung ausgeführt werden, d.h., sie werden an die Objekte der Subklassen vererbt, wohingegen die Namen i.d.R. in den Objekten der Klassen enthalten sind. Bei überschneidungsfreien vollständig abdeckenden Subklassen können dagegen auch die Personaldaten in der Superklasse verfügbar gemacht werden.

684 YGI BRENTMANN, B.; BURKHARD, R.: Objektorientierte Systeme, Grundlagen - Werkzeuge Einsatz, München/Wien 1992, S. 332 sowie VETTER, M.: Objektmodellierung, a.a.O., S. 34.

3 Sichten der Softwareentwicklung

290

Die Generalisierung - Spezialisierung ist eine Form der Vererbung, da die Superklasse eine Generalisierung der Subklasse ist. Bei dieser Art von Beziehung fragt man: »Ist für eine (oder mehrere) Klassen eine generelle oder allgemeinere Klasse denkbar?« oder »Sind für eine Klasse Spezialisierungen denkbar, so dass man die Klasse besser nach innen weiter untergliedert?«^ Die Beziehung zwischen über- und untergeordneter Klasse ist vom Typ: is a.

^^ /

Hunde

Tiere Katzen

Lebewesen ^

Pflanzen

Bild 3-13: Beispiel Spezialisierung - Generalisierung

Neben der Klassenbildung oder Klassifikation im Rahmen der Spezialisierung wird zur Komplexitätsreduktion auch die Aggregation angewandt. Aggregation: Unter Aggregation versteht man die Zusammensetzung des ganzen aus Teilen. Die Beziehung zwischen dem Zusammengesetzten und den einzelnen Teilen ist vom Typ: consist of.

685 y g i VETTER, M.: Objektmodellierung, a.a.O., S. 51.

3.6 Objektorientierte Softwareentwicklung

291

Ein weiteres wichtiges Unterscheidungsmerkmal für die GeneralisierungSpezialisierung und die Aggregation ist, dass es sich bei der Generalisierung um eine Beziehung zwischen Klassen und bei der Aggregation um eine Beziehung zwischen Instanzen handelt. Übertragen auf das obige Beispiel bedeutet dies, dass die Menge aller Tiere eine echte Untermenge zur Menge aller Lebewesen sind. Aber zu einem ganz bestimmten Buch gehört genau ein Kapitel 1, Kapitel 2 usw. Neben diesen Begriffen wird im Rahmen der Objektorientierung noch der des Polymorphismus verwendet. Polymorphismus sorgt dafür, dass unterschiedlichen Klassen angehörende Objekte aufgrund einer Nachricht verschieden reagieren können und reagieren, z.B. Fußballspieler beim Schlusspfiff. So würde die Nachricht »Schlusspfiff« an ein Objekt der Klasse »Gewinner« die Aktionen »jubeln« und »gegenseitig innarmen« auslösen, während das Senden derselben Nachricht an ein Objekt der Klasse »Verlierer« die Aktionen »traurig sein« und »alles auf den Schiedsrichter schieben« bewirken würde. Auf diesen Grundlagen aufbauend soll erläutert werden, wie man objektorientierte Programmsysteme erstellt. In diesem Rahmen soll im Folgenden die Unified Modelling Technique (UML) vorgestellt werden. 3.6.2 Unified Modelling Technique (UML) In den vorangegangen Abschnitten wurden Sichten der Softwareentwicklung vorgestellt und so auch die Notwendigkeit der Verknüpfung hervorgehoben. Die Unified Modelling Language (UML) stellt eine (standardisierte) Sprache für die Modellierung von Software und anderen Systemen dar.686 Bereits mit den vorangegangenen Ausführungen wurde deutlich, dass die vielen unterschiedlichen Modellierungsmethoden auch als „Methodenkrieg" zu betrachten waren. Im September 1997 wurde UML von der Object Management Group (OMG) als wichtigstes Standardisierungsgremium für objektorientierte Systementwicklung akzeptiert und seitdem konsequent weiterentwickelt.0*7 Seit 2005 existiert UML in der Version 2.O.688

686 Ygj jjj TZ) μ u a : UML@Work - objektorientierte Modellierung mit UML 2,3., aktualisierte und Überarb. Aufl., Heidelberg 2005, S. 2 ff. sowie OESTEREICH, B . : Objektorientierte Softwareentwicklung, München/Wienl998, S. 21. 687 688

Vgl. OESTEREICH, B . : Objektorientierte Softwareentwicklung, a.a.O., S. Vgl. Hrrz, M. u.a.: UML, a.a.O., S. 5.

20.

3 Sichten der Softwareentwicklung

292

Es existieren zahlreiche Lehrbücher und Anwendungsbeispiele zur UMLModellierung. In diesem Abschnitt sollen lediglich ein kurzer Überblick gegeben und die wesentlichen Prinzipien der UML vorgestellt werden. Für einen tiefer gehenden Einblick in die Unified Modelling Language sei auf die angegebene Literatur verwiesen. Die objektorientierte Softwareentwicklung, wie sie im vorangegangenen Abschnitt vorgestellt wurde, unterstützt eine ganzheitliche Herangehensweise. Statt einer Trennung von Daten und Operationen wird nun mit Einheiten aus diesen gearbeitet.689 OESTEREICH beschreibt die Wirklichkeit in der Systemtheorie als ein Netzwerk. „Die einzelnen Sachverhalte und Phänomene werden nicht mehr auf ihre Einzelteile reduziert, sondern als integriertes Ganzes betrachtet, bei dem die einzelnen Komponenten miteinander verbunden sind und Abhängigkeiten zwischen ihnen bestehen (ganzheitliches Denken)."090 Mit Hilfe der vorgestellten Methoden und Sichtentrennung lassen sich Anforderungen an die Beschreibung und Realisierung komplexer Software nicht mehr beherrschen. Objektorientierung bietet zudem bessere Abstraktionsmöglichkeiten. 3.6.2.1 Grundprinzipien der Unified Modelling Language Mit dem Ansatz der Objektorientierung697 wurde ursprünglich das Ziel verfolgt, „die semantische Lücke092 zwischen der (fachlichen) Anwendungswelt und der (technischen) Realisierungswelt zu schließen."693 Die bereits in diesem Kapitel vorgestellten Sichten der Softwareentwicklung und deren unterschiedlichen Ansätze weisen jeweils spezifische Eigenschaften mit Vor- und Nachteilen auf. Dabei wurde bisher immer wieder der ,3ruch" zwischen einzelnen Sichten deutlich. Vor diesem Hintergrund ist die UML als ein Zwischenstand in einem langsam wachsenden Wissensgebiet zu sehen694, dessen Beitrag vor allem „in der Konsolidierung dieses Wissensgebiets, seiner Integration und Standardisierung und der Auswahl eines Kanons an Modellierungskonzepten" besteht.695

689

Vgl. OESTEREICH, B.: Objektorientierte Softwareentwicklung, a.a.O., S. 26.

690

OESTEREICH, B.: Objektorientierte Softwareentwicklung, a.a.O., S. 26. 691 Ygj Abschnitt "Objektorientierte Softwareentwicklung". 692 In der Literatur ist auch der Ausdruck semantic gap gebräuchlich. 693 STÖRRLE, H., UML 2 fur Studenten, München 2005, S. 44. 694

V g l . STÖRRLE, H . , U M L 2 , a.a.O., S. 2 3 .

695

STÖRRLE, H . , U M L 2, a.a.O., S. 2 3 .

3.6 Objektorientierte Softwareentwicklung

293

Die Unified Modelling Language verfolgt den Ansatz, den Sichtenbruch zu umgehen. Dieser Ansatz soll im Folgenden vorgestellt werden. Zunächst werden hierzu die Grundprinzipien der UML vorgestellt, die im Wesentlichen auf der Darstellung von RUMBAUGH, JACOBSON und BOOCH696 beruhen, die grundlegend zur Entwicklung der UML beigetragen haben.697 UML stellt eine Integration existierender Modellierungsmethoden dar und dient der Unterstützung des gesamten Entwicklungsprozesses. In allen Stufen der Entwicklung können die gleichen Sprachkonzepte und die gleiche Notation verwendet werden.095 Mit der UML wird weder ein bestimmtes Vorgehensmodell definiert, noch wird sich auf ein bestimmtes Vorgehensmodell festgelegt. Es ist möglich, die Wahl des Vorgehensmodells von der Wahl der Modellierungsmethode zu entkoppeln und so mehr Flexibilität zu begünstigen. 699 Weitere Zielsetzungen im Rahmen der Entwicklung von UML waren die „Unabhängigkeit von Entwicklungswerkzeugen und -plattformen sowie Programmiersprachen, die Einsetzbarkeit für verschiedenste Anwendungsbereiche"700 und auch die generische Basis der Sprachkonzepte.707 3.6.2.2 Diagrammarten in UML 2.0

Insgesamt unterscheidet UML in der Version 2.0 zwischen 13 verschiedenen Diagrammarten, die im Folgenden kurz vorzustellen sind.702 Diese lassen sich nach JECKLE U.A.703 in drei unterschiedliche Typen unterscheiden: 1. Strukturdiagramme dienen zur Modellierung der statischen Struktur eines Systems. In UML stehen hierfür sechs verschiedene Diagrammarten zur Verfügung: a) Klassendiagramme b) Paketdiagramme c) Objektdiagramme 696 VGL RUMBAUGH, J.; JACOBSON, I.; BOOCH, G., The Unified Modeling Language reference manual, Boston u.a. 2004. 697 095 699

Vgl. Ηιτζ, M. u.a., UML, a.a.O., S. 7. Vgl. Ηιτζ, M. u.a., UML, a.a.O., S. 7. Vgl. Ηιτζ, Μ. u.a., UML, a.a.O., S. 7.

700

Ηιτζ, M. u.a.: UML, a.a.O., S. 7. 701 Vgl. Ηιτζ, M. u.a.:, UML, a.a.O., S. 7. 702 YGJ PAGE, B.; KREUTZER, W.: The Java Simulation Handbook - simulating discrete event systems with UML and Java, Aachen 2005, Aachen 2005, S. 62 f. 703

Vgl. JECKLE, M. U.A.: UML 2.0 glasklar - Unified Modeling Language, München/Wien 2004, S. 1 ff.

3 Sichten der Softwareentwicklung

294 d) Komponentenstrukturdiagramme e) Komponentendiagramme f) Verteilungsdiagramme

2. Verhaltensdiagramme werden zur Darstellung des dynamischen Verhaltens von Objekten oder Komponenten bei verschiedenen Detaillierungsgraden genutzt. Zu den Verhaltensdiagrammen gehören a) Anwendungsfalldiagramme b) Aktivitätsdiagramme c) Zustandsdiagramme d) sowie verschiedene Arten von Interaktionsdiagrammen: 3. Interaktionsdiagramme sind spezielle Verhaltensdiagramme, die sich auf die Interaktion zwischen zwei oder mehr Objekten konzentrieren. Interaktionsdiagramme lassen sich in vier Diagrammarten unterscheiden: a) Sequenzdiagramme b) Kommunikationsdiagramme c) Zeitdiagramme d) Interaktionsübersichtsdiagramme Die folgenden Ausführungen sind im Wesentlichen an den Darstelltingen in HlTZ U.A. und ERLER/ RICKEN angelehnt, da hier eine sehr gute übersichtliche Beschreibung gegeben wird. Mit Hilfe von Klassendiagrammen wird zunächst eine statische Perspektive beschrieben und damit die Struktur eines Systems modelliert. Dabei werden Klassen, wie in der nachfolgenden Abbildung veranschaulicht, dargestellt als dreifach unterteilte Rechtecke, die von oben nach unten sowohl den Klassennamen, die Zustandsattribute als auch die Verhaltensweisen enthalten. Derartige Klassen zeigen die zeitlich unabhängige Struktur von Systemelementen auf, wobei die in einem solchen System enthaltenen Beziehungen zwischen den Exemplaren bestimmter Klassen durch einfache Verbindungslinien dargestellt werden. Vererbungsbeziehungen werden demgegenüber als Pfeil modelliert, in dem ein entsprechender Pfeil von der erbenden auf die vererbende Klasse zeigt. In dem nachfolgend dargestellten Beispiel eines Klassendiagrammes stellt die Klasse KONTO die vererbende Klasse, die Klassen SPARKONTO und GIROKONTO die erbenden Klassen dar.704

704

Vgl. ERLER, T.; RICKEN, M.: UML 2 gepackt, Bonn 2005, S. 31.

3.6 Objektorientierte Softwareentwicklung

295

Bild 3-15: Beispiel eines Klassendiagrammes in UML-Notation705 In komplexen Problemstellungen können Klassendiagramme sehr schnell zu kompliziert wirken. Aus diesem Grund bietet sich eine Strukturierung in Form von Paketen an, wie sie auch in modernen Programmiersprachen genutzt werden.700 Paketdiagramme dienen somit zur weiteren Gruppierung der Bestandteile eines Systems. Paketdiagramme helfen so die Komplexität der Darstellung zu reduzieren.707 Die dargestellte Struktur im Klassendiagramm besitzt zu jedem Zeitpunkt der Existenz eines Objektsystems eine konkrete Ausprägung, somit stellt ein Objekt eine Instanz einer Klasse dar.708 Im Rahmen der UML-Notation werden mögliche konkrete Ausprägungen mit Hilfe eines Objektdiagrammes repräsentiert. Die nachfolgende Abbildung 3-16 zeigt für das eingeführte Kontenbeispiel exemplarisch sechs spezifische Ausprägungen der Klassen SPARKONTO, GIROKONTO und KUNDE, wobei jedes Objekt eindeutig durch die Darstellung als Rechteck identifizierbar ist:709

705

ERLER, T.; RICKEN, Μ . : U M L 2 , a . a . O . , S . 3 1 .

706

In Java werden diese Pakete bspw. als Packages, in C# als Assemblies bezeichnet. Vgl. Ηιτζ, M. u.a.: UML, a.a.O., S. 8 und S. 120 f. 708 Ygj Abschnitt 3.6 „Objektorientierte Softwareentwicklung". 707

709

V g l . ERLER, T.; RICKEN, M . : U M L 2 , a . a . O . , S. 3 2 .

3 Sichten der Softwareentwicklung

296 : SDarkonto

bonität = gut name = Erler Inhaber

: Girokonto

Inhaber

kontonr = 4711 kontostand = 357 dispolimit = 2000

: Kunde

Inhaber

kontonr = 6219 kontostand = 600 zinssatz = 2,1%

k1 : Kunde bonität = gut name = Ricken

I n h a b e r ^ ^ ^ k 2 : Kunde

: Girokonto kontonr = 5318 kontostand = 12000 dispolimit = 1300

bonität = schlecht name = Meier

Bild 3-16: Beispiel eines Objektdiagrammes in UML-Notation Die aus dem Klassendiagramm bekannten Beziehungen zwischen den einzelnen Objekten werden im Objektdiagramm ebenfalls durch den Einsatz von Verbindungslinien hergestellt. Dabei wird der zeitpunktabhängige Zustand der einzelnen Objekte durch deren Attribute beschrieben respektive fixiert.770 Während also der Zustandsraum aus der zeitlich invarianten Klassenstruktur unveränderlich bleibt, können sich die konkreten Zustände eines Objektes durch unterschiedliche Wertzuweisungen ändern. So ist es in Bezug auf den gewählten Anwendungsfall möglich, dass der Zinssatz des Sparkonto-Objekts 6219 zu einem vor- oder nachgelagerten Zeitpunkt von 2,1% auf 2,4% erhöht wird.™ Mit dem Einsatz von UML 2.0 entspricht der Begriff „Komponente" im Wesentlichen dem in der Literatur zur komponentenbasierten Softwareentwicklung verwendeten Begriff. Eine Komponente stellt einen modularen Teil eines Systems, der zur Abstraktion und Kapselung einer (beliebig komplexen) Struktur dient und wohldefinierte Schnittstellen zur Verfügung stellt.772 In dem Komponentendiagramm werden Komponenten und ihre Abhängigkeiten dargestellt. Erst seit UML 2.0 wird das Kompositionsstrukturdiagramm eingesetzt und dient zur hierarchischen Dekomposition verschiedener Systembestandteile und hilft so bei der detaillierten Beschreibung der internen Struktur von Klassen 710

V g l . ERLER, T.; RICKEN, M . : U M L 2, a.a.O., S. 3 3 .

711

V g l . ERLER, T.; RICKEN, M.: U M L 2 , a.a.O., S. 3 3 .

712

Vgl. Ηιτζ, M. u.a.: UML, a.a.O., S. 124 f.

3.6 Objektorientierte Softwareentwicklung

297

oder Komponenten.775 Für die Beschreibung der Struktur eines Systems stehen zuletzt Verteilungsdiagramme zur Verfügung. Diese Verteilungsdiagramme zeigen, welche Komponenten und Objekte auf verschiedenen Knoten (Prozessen, Computern) laufen und zeigen zudem deren Kommunikationsbeziehungen auf.714 Neben den Strukturdiagrammen sollen im Folgenden auch die aufgelisteten Verhaltensdiagramme und deren Interaktionsdiagramme kurz vorgestellt werden, die sich nun um die dynamischen Aspekte kümmern werden. Die bisher im Rahmen der Skizzierung von Strukturdiagrammen dargestellte statische strukturorientierte Perspektive wird im Rahmen der Modellierung von Systemen durch dynamische Elemente ergänzt, wobei Systemabläufe in dynamischen Teilmodellen verdeutlicht werden. Im Folgenden werden mögliche dynamische Sichten im Zuge der Anwendung von UML in den Fokus der Betrachtung gestellt. Obwohl das Anwendungsfalldiagramm zu den Verhaltensdiagrammen gegliedert wird, stellt es einen Sonderfall aus Struktur- und Verhaltensdiagrammen dar.775 Anwendungsfalldiagramme umfassen die identifizierten Anwendungsfalle, das System und deren Akteure, die mit dem System interagieren. In einem Anwendungsfall wird ein bestimmtes, von dem System zu erwartenden Verhalten beschrieben. Es wird aber von den Details des Systemverhaltens abstrahiert und lediglich die Funktionalität des Systems aus Benutzersicht dargestellt.776 In Aktivitätsdiagrammen findet eine weitere Konkretisierung derjenigen Anforderungen statt, die in den Anwendungsfalldiagrammen beschrieben wurden. Es beginnt hier somit auch die Ausgestaltung der Möglichkeiten, wie das System diese Anforderungen erfüllen soll.777 Aktivitätsdiagramme basieren dabei auf den klassischen Kontroll- und Datenflusskonzepten. Aktionen werden ausgeführt, wenn andere Aktionen beendet und die erforderlichen Inputdaten gegeben sind.775 Das Zustandsdiagramm wird bei der Modellierung eingesetzt, um zugelassene Zustände und Zustandsübergänge eines Objektes von seiner Entstehung 713

Vgl. HITZ, M. u.a.: UML, a.a.O., S. 152 f.

714

Vgl. OESTEREICH, B.: Objektorientierte Softwareentwicklung, a.a.O., S. 323. Seit UML 2.0 wird das Anwendungsfalldiagramm den Verhaltensdiagrammen subsumiert.

715 716

Vgl. HITZ, M. u.a.: UML, a.a.O., S. 9 und S. 173 ff.

777

Vgl. Vgl.

718

Objektorientierte Softwareentwicklung, a.a.O., S. u.a.: U M L , a.a.O., S. 10.

OESTEREICH, B . : HITZ, M .

157.

298

3 Sichten der Softwareentwicklung

(schwarzer Punkt) bis zu seiner Vernichtung (schwarz umrandeter schwarzer Punkt) zu definieren. Die hierbei verwendeten Kästchen stellen dementsprechend Zustände dar, die mit spezifischen Aktionen verbunden sein können. Die Verbindungspfeile repräsentieren Zustandsübergänge, die durch bestimmte Ereignisse ausgelöst werden.779

auszahlenQ {kontostand >= betrag} einrichten()

Ψ

Λ

einrichtenO

Kontostand positiv

7\ auszahlen() {kontostand < betrag}

einzahlenQ {-kontostand betrag}

Bild 3-17: Beispiel eines Zustandsdiagrammes720 Weiterhin stehen zur Modellierung des Verhaltens verschiedene Interaktionsdiagramme zur Verfugung. Das Sequenzdiagramm bietet hierbei eine weitere dynamische Perspektive und fokussiert mögliche Interaktionen zwischen den relevanten Objekten des Anwendungsbereiches. Die folgende Abbildung 3-18 stellt die Interaktion zwischen den einzelnen Objekten in einem Sequenzdiagramm dar. Die gestrichelten senkrechten Linien repräsentieren die drei an der Interaktion beteiligten Objekte der Klasse KUNDE, GIROKONTO und SPARKONTO. Die Verbindungspfeile deuten dabei eine Interaktion zwischen den Objekten an, wobei das die Interaktion auslösende Objekt den Ursprung des Pfeiles darstellt.727

719

V g l . ERLER, T . ; RICKEN, M . : U M L 2 , a . a . O . , S. 3 3 f.

720

ERLER, T . ; RICKEN, M . : U M L 2 , a . a . O . , S. 3 4 .

721

V g l . ERLER, T.; RICKEN, M . : U M L 2 , a . a . O . , S. 3 4 .

3.6 Objektorientierte Softwareentwicklung

299

Bild 3-18: Beispiel eines Sequenzdiagrammes722 Analog zum Sequenzdiagramm werden mit Hilfe von Kommunikationsdiagrammen Interaktionen zwischen Objekten in bestimmten Rollen beschrieben. Hier stehen jedoch die strukturellen Beziehungen und nicht die zeitliche Reihenfolge im Vordergrund.723 Zeitdiagramme sind für die Modellierung von zeitkritischem Verhalten, wie es in Echtzeitsystemen erforderlich ist, geeignet. Es werden z.B. explizit zeitabhängige Zustandsänderungen berücksichtigt.7^ Interaktionsübersichtsdiagramme stellen den Kontrollfluss zwischen verschiedenen Interaktionsläufen dar. So ist ein Instrument gegeben, die Interaktionsdiagramme wiederum in eine logische Reihenfolge zu bringen.725 Mit der UML wird ein Instrument an die Hand gegeben, welches zu diesem Zeitpunkt, wie angesprochen, das Ergebnis eines langen Entwicklungsprozesses darstellt. Es wird deutlich, dass das Zusammenspiel der unterschiedlichen Darstellungsformen hilft, ein System zu strukturieren und mit seinem Verhalten

722

V g l . ERLER, T.; RICKEN, M . : U M L 2 , a . a . O . , S. 3 5 .

723

Vgl. Ηιτζ, M. u.a.: UML, a.a.O., S. 10. Vgl. Ηιτζ, M. u.a.: UML, a.a.O., S. 293. Vgl. Ηιτζ, M. u.a.: UML, a.a.O., S. 297.

724 725

300

3 Sichten der Softwareentwicklung

systematisch und verständlich zu beschreiben. Damit wird das wesentliche Ziel im Rahmen der Modellierung erreicht. 3.7 Herleitung der ganzheitlichen Softwareentwicklung

Bei den bisherigen Sichten bestand eine klare Reihenfolge bezüglich der einzelnen Software-Entwicklungsphasen, da meist auch eine klare Zielrichtung vorgegeben war. Dabei wurde, da man sich bemühte, aus vergangenen Fehlern zu lernen, die Menge an Voraussetzungen immer größer. So entstand die datenorientierte Sicht aus der Forderung, redundante Informationen zu vermeiden. Mit Hilfe der funktionsorientierten Sicht wurde versucht, für die DV-Aufgaben angemessene Positionen für die Daten zu finden oder gar die Datendarstellung durch die zu erfüllenden Funktionen zu beeinflussen. Da dabei die Beachtung der Aufbau- und Ablaufstrukturen und der Ressourcen zu kurz kommen kann, wurde dieser Aspekt im Rahmen der organisationsorientierten Sicht aufgenommen. Die prozessorientierten Systeme versuchten, die zunehmende Vernetzung der Büroarbeitsplätze und sonstiger DV-gestützter Arbeitsplätze durch arbeitsplatz- und eventuell auch abteilungsübergreifende Bearbeitung von Vorgängen oder Funktionen in Form von Vorgangsketten zu unterstützen. D.h., durch Zusammenfassen von Funktionen unter Berücksichtigung der Organisations- und der Datensicht entstand die umfassendere prozessorientierte Sicht.726 Der ARIS-Ansatz von SCHEER versucht, Abstimmungsprobleme der unterschiedlichen Sichten zu vermeiden, indem er sich um eine weitestgehend ganzheitliche727 Sicht bemüht, da er gleich vier Sichten vereinigt: die Daten-, die Funktions- die Steuer- und die Organisationssicht. Dabei berücksichtigt er zwischen der Realität und der DV-Lösung drei Beschreibungsebenen, auf die er jeweils alle vier Sichten anwendet. Auf eine etwas andere Art und Weise geht man bei der objektorientierten Sicht vor, bei der das Informationssystem aus einer Menge an Objekten besteht, in denen die Funktionen und Daten in klar abgegrenzten Einheiten stecken. Es wird der Versuch unternommen, von verschiedenen Seiten ausgehend eine möglichst umfassende Lösung zu liefern. Alle Ansätze seit dem funktionsorientierten Ansatz verfolgen die Absicht, nicht einseitige Abbildungen zu erzeugen, sondern eine Vielzahl an 726 727

Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 422 f. Vgl. SCHEER, A.-W.: Wirtschaftsinformatik, a.a.O., S. 10.

3.7 Herleitung der ganzheitlichen Softwareentwicklung

301

wechselseitigen Beziehungen zu berücksichtigen. Die Qualität wird durch die Gründlichkeit der Beachtung von Prinzipien und Konzepten bei der Verfolgung verschiedener Sichten geprägt. Mit der UML wird ein weiterer wichtiger Schritt in Richtung der ganzheitlichen Herangehensweise unternommen. Im Rahmen unseres Ansatzes sollen deshalb an dieser Stelle die wesentlichen Grundgedanken des ganzheitlichen Ansatzes noch einmal zusammengefasst werden: - Die Basis des Entscheidungsansatzes sorgt dafür, dass man versucht, alle Systembeziehungen zu quantifizieren. - Die Basis des konstruktiven Systemansatzes führt zu einer klaren Abgrenzung dessen, was erreicht werden soll und was nicht notwendig ist. - Auch führt die Anwendung des konstruktiven Systemansatzes dazu, dass alle Funktionen erkannt und die notwendigen Daten gestaltet werden. - Über den synthetischen Systemansatz wird erkannt, welche Funktionen und Daten zusammengehören, wodurch die prozessorientierte und ebenfalls die objektorientierte Sicht unterstützt werden. - Insbesondere dadurch, dass man in der ersten Phase mit Hilfe unseres Rahmenkonzeptes zunächst Top-Down vorgeht, wird immer vom unternehmensübergreifenden System ausgegangen und nicht von integrierten Teillösungen. Diese werden erst nachgeordnet berücksichtigt.728 - Die inkrementelle und partizipative Erstellung soll für die Integration aller Beteiligten und insbesondere der potenziellen Anwender sorgen. - Es erfolgt keine eindeutige Festlegung auf spezielle Sichten. Jedoch wird die Verfolgung möglichst vieler Sichten angestrebt. - Das Konzept ist programmiersprachenunabhängig. - Das Ergebnis soll ein unternehmensübergreifendes, nach klaren Prinzipien und klaren Prioritäten gegliedertes, wirtschaftliches und wartungsfreundliches Informationssystem sein. - Die einzelnen Schritte werden von Problemstellung zu Problemstellung unterschiedliche Ausprägungen unter den verschiedenen Sichten haben, so dass hier jedes Unternehmen für jede der notwendigen Sichten unterschiedliche Gewichte und Lösungen (in Abhängigkeit von den Tools) wählen kann. - Das System lässt sich sowohl bei Neuentwicklungen als auch bei nachträglichen Änderungen durch das Setzen anderer Schwerpunkte anwenden. In beiden Fällen gehen wir vom Gesamtsystem aus, haben aber bei Änderungen i.d.R. nur einzelne Sichten und einzelne Ebenen innerhalb So wird hier wie bei OSTERLE die Neugestaltung des gesamten Systems und nicht nur die Reorganisation vorgenommen. Vgl. ÖSTERLE, H.: Business Engineering, a.a.O., S. 2.

302

3 Sichten der Softwareentwicklung

des Rahmenkonzeptes zu modifizieren. Nicht berührte Bereiche können übergangen werden. Wir sind also der Meinung, dass sich unser Ansatz durchaus von den anderen unterscheidet, dass aber zunehmend durch immer mehr Ansätze das ganzheitliche Ziel verfolgt wird. Dieses wird in der Realität aufgrund der Schnelllebigkeit aller Informationssysteme meist wohl mehr eine Vision bleiben. Jedoch wird diese Vision viel Stückwerk vermeiden helfen.

4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Die Softwareentwicklung ist eine relativ junge Wissenschaft, so dass die meisten Softwareentwickler deshalb auf Erfahrung und nicht auf gesichertes Wissen setzen. Dieses Erfahrungswissen wird i.d.R. als einzuhaltende Prinzipien, zu befolgende Regeln oder Methoden bezeichnet. Sie haben nur so lange Gültigkeit, bis bessere Prinzipien und Methoden gefunden werden. Die derzeit gültigen und meistverwendeten Regeln und empfohlenen Vorgehensweisen, die sich als sinnvoll erwiesen haben, werden in diesem Kapitel aufgeführt. 4.1 Prinzipien der Softwareentwicklung

Prinzipien729 lassen sich aus der Erfahrung sowie Erkenntnis ableiten und werden durch sie bestätigt oder widerlegt.730 Die Prinzipien des Softwareengineerings gehören zu grundlegenden Vorgehensweisen dieser Disziplin und bilden kein abgeschlossenes und konsistentes Lehrgebäude.731 Bis heute handelt es sich mehr oder weniger um eine Sammlung von Einzelprinzipien aus den verschiedenen Teilen des Softwareengineerings, die teilweise zu modifizieren bzw. zu erweitern sind. Im Folgenden soll deshalb nicht der Versuch unternommen werden, eine xmlfassende Darstellung aller Softwareentwicklungs-Prinzipien wiederzugeben. Vielmehr soll eine exemplarische Darstellung wichtiger Prinzipien genügen. Dabei werden zunächst allgemeine Prinzipien und aufbauend stärker phasenbezogene Prinzipien erörtert. 4.1.1 Allgemeine Prinzipien

Die allgemeinen Prinzipien beschreiben Anforderungen, die für alle Sichten und alle Ebenen (Phasen) Bedeutung haben.

729 730

Vgl. RUF, W.: Ein Software-Entwicklungs-System, a.a.O., S. 58 ff.

Vgl. BALZERT, H.: Allgemeine Prinzipien, a.a.O., S. 2. 731 Vgl SCHULZ, Α.: Entwicklungsstand der anwendungsorientierten Softwaretechnologie, in: MAURER, H. (Hrsg.): Überblicke Informationsverarbeitung 1985, Mannheim/Wien/Zürich 1985, S. 194(191-220).

304 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 4.1.1.1 Prinzip der Datenunabhängigkeit Nach diesem Prinzip wird verlangt, Daten möglichst so anzulegen, dass sie für viele Anwendungen und nicht nur für eine spezielle verwendet werden können. Da auf dieses Prinzip ausführlich in Kap. 2.6.1 eingegangen wurde, kann hier darauf verzichtet werden.732 4.1.1.2 Prinzip der Standardisierung Durch eine Standardisierung wird die Vereinheitlichung von Aufgaben, Vorgehensweisen und Funktionsbereichen angestrebt. Mit dem Prinzip der Standardisierung lassen sich alle Bereiche der Softwareentwicklung beeinflussen. Mehrere Autoren sehen in der Standardisierung das zentrale bzw. fundamentale Problem der Softwareerstellung.733 4.1.1.2.1 Ziele der Standardisierung Beispiele aus dem Hardwarebereich haben gezeigt, dass eine erhebliche Reduktion der Konstruktions- und Entwicklungskosten durch Bausteindenkweise und Vereinheitlichungen erzielt werden können.734 Auch bei der Softwareentwicklung sind Standardisierungen möglich. Sie werden aufgrund der Anwendungsvielfalt in einzelnen Unternehmen oder Unternehmensteilen - obwohl es erforderlich wäre - jedoch nur verhältnismäßig selten herausgearbeitet. Mit dem Prinzip der Standardisierung sollen folgende Ziele erreicht werden:735 - einheitliche Begriffsdefinitionen (ζ. B. DIN 44300), - eine Reduktion der Planungs- und Entwicklungskosten, - größere Unabhängigkeit der Anwender von Hard- und Softwareherstellern, - Vereinheitlichung des Softwareentwurfsprozesses, - Vereinheitlichung des Programmier- und Dokumentationsstils, - bessere Verständlichkeit aller Softwareprodukte, - Erleichterung der Austauschbarkeit von Softwarekomponenten, 732 vgl. zur Datenunabhängigkeit Kapitel 2.6.1. 733

Vgl. SCHUMANN, J.; GERISCH, M.: Software-Entwurf, a.a.O., S. 171 und BLAGAY, S.: Neue

Standards braucht die DV-Welt, in: COMPUTERWOCHE: 13. Jg., Nr. 25 vom 18.07.1986, S. 2 0 . 734 Vgl. FERSTL, O.K.; SINZ, E.J.: Software-Konzepte der Wirtschaftsinformatik, Berlin/New York 1984, S. 3. 735 VGL BALZERT, H.: Moderne Software-Entwicklungssysteme und -Werkzeuge, Mannheim/ Wien/Zürich 1985, S. 6.

4.1 Prinzipien der Softwareentwicklung

305

- besser planbare Software. Beispiel: Durch Vereinheitlichungen beim Softwareentwicklungsprozess wird versucht, diesen besser planbar und gleichzeitig effektiver zu gestalten. Dazu wird in dem IEEE-Standard 729 versucht, die Phasen des Softwarelebenszyklus zu standardisieren. 4.1.1.2.2 Möglichkeiten einer Standardisierung Das Prinzip der Standardisierung lässt sich auf unterschiedlichen Wegen erreichen. Bild 4-1 zeigt die verschiedenen Möglichkeiten oder Formen zur Standardisierung, unterschieden nach ihrem Verbindlichkeitsgrad. Dabei werden mehrere nachfolgend zu erläuternde Möglichkeiten unterschieden. hoch Normen Standardisierungsvorschriften Anbieter

Nachfrager

U Verbindlichkeitsgrad

Firmenstandards Selbstdisziplin der Softwareentwickler

Bild 4-1: Verbindlichkeitsgrad bei der Standardisierung

A. Einhaltung von Normen a) internationale Normen Auf internationaler Ebene werden Normen u.a. aufgestellt von: -

ISO (International Standard Organization) CCITT (Comite Consultatif International Telegraphique et Telephonique) ECMA (European Computer Manufacturer Association) IEC (International Electrotechnical Commission)

306 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung b) nationale Normen In der Bundesrepublik Deutschland beschäftigt sich das Deutsche Institut für Normung e.V. (DIN) mit der Aufstellung und Veröffentlichung von Normen.730 Ebenfalls auf nationaler Ebene ist in den USA das ANSI (American National Standards Institute) und das IEEE (Institution of Electrical and Electronic Engineers) tätig. Beide Institute haben auf dem Gebiet des Softwareengineerings jedoch auch internationale Bedeutung. c) Quasinormen Es dauert oft recht lange, bis Normen verabschiedet werden. In den Normungsgremien ist dazu ein teilweise jahrelanger Abstimmungsprozess notwendig.737 Voraussetzung für die Aufstellung von Normen ist ein Bereich mit einer gewissen Konsistenz. Dies ist jedoch im Bereiche der Entwicklung ganzheitlicher Informationssysteme aufgrund des raschen informationstechnischen Fortschritts nur teilweise gegeben. Einen weiteren Grund für das Fehlen von Normen bzw. für die mangelnde Durchsetzung von Normen sieht H.H. SCHULZE in dem ungleichgewichtigen DV-Markt. Die überragende Stellung eines Marktführers erlaubt die Durchsetzung von Firmenstandards als Quasinormen für Mitbewerber.738 Einen Überblick über die Vielzahl von nationalen und internationalen Normen findet man bei J. TOBERGTE und U. VOGES.739

Gut bewährt haben sich Normen ζ. B. in Bereichen der Programmiersprachen.740 Hier wird von den Herstellern versucht, die verabschiedeten Normen möglichst genau und vollständig einzuhalten. In den letzten Jahren wurden sogar Prüfstellen, ζ. B. bei der GMD eingerichtet, die Produkte auf Normenkonformität prüfen.741

736

Wichtige Normen zur Informationsverarbeitung findet man unter DIN 44300,44301, 66001. Vgl. GROENKE, L.: Der Normenausschuß Informationsverarbeitungssysteme (NI) und seine Aufgaben. Verbindlichkeit und Durchsetzbarkeit von Normen, in: AI: 6/1985, S. 245 (244-254). 738 YGJ SCHULZE, H.H.: Datenverarbeitung in kleinen und mittleren Unternehmen - Planung, Einführung und Einsatz von DV-Systemen, München/Wien 1983, S. 200 f. 739 Vgl. TOBERGTE, J.: Überblick über Normen, a.a.O., S. 453, sowie VOGES, U.: Normungsaktivitäten auf dem Gebiet des Software Engineering, in: Automatisierungstechnische Praxis: 737

V o l . 2 9 , 4 / 1 9 8 7 , S. 183 ff. ( 1 8 3 - 1 9 7 ) . 740

741

Vgl. DIN 66028 Programmiersprache COBOL; diese Norm entspricht COBOL-ANSI-X3.23 und ISO-Norm 1989. Vgl. o.V.: GMD prüft COBOL- und FORTRAN-Compiler der Nixdorf Computer AG, in: Der GMD-Spiegel: 2/1985, S. 39 sowie WEGNER, E.: Normkonformitätsprüfung und Zertifikation, in: AMK Berlin (Hrsg.): Compas '84, Berlin 1984, S. 481 f. (479^88).

4.1 Prinzipien der Softwareentwicklung

307

Will man nachweisen, dass ein Softwaresystem bestimmte Normen erfüllt und möchte man hierfür ein Zertifikat erwerben, so ist hierfür der Zertifizierungsprozess in Kap. 4.3.4.2 beschrieben. B. Einhaltung von Standardisierungsvorschriften von Anbieter- oder Nachfragervereinigungen Große Projekte erfordern oft die Zusammenarbeit vieler Anbieter. Durch Standardisierungsvorschriften soll eine Basis für die Integration und Kompatibilität unterschiedlicher Teilsysteme geschaffen werden. Auf der Nachfragerseite wird vor allem durch die öffentliche Verwaltung und durch deren Spitzenverbände versucht, Standards durchzusetzen. Einen weiteren Erfolg versprechenden Weg für die Durchsetzung von Standards bieten die Anwendervereinigungen (User-Groups) oder auch überstaatliche Stellen (ζ. B. die Europäische Gemeinschaft).742 C. Einhaltung von »Industriestandards« Bei den so genannten »Industriestandards« wird versucht, die Vorgaben eines Marktführers einzuhalten oder möglichst »originalgetreu« zu kopieren. Ein typisches Beispiel hierfür findet sich im PC-Bereich bei der Verwendung von PC-DOS bzw. MS-DOS als Standardbetriebssystem. Eine weitere Möglichkeit zur Schaffung von Industriestandards besteht in der Kooperation mehrerer Unternehmen. Ein Beispiel hierfür stellt die EISAEntwicklung (EISA = erweiterter Industriestandard beim AT-Bus) dar. Die EISA-Entwicklungen wurden von mehreren Unternehmen (Compaq, A&T, HP, NEC, Olivetti, Tandy, Wyse und Zenith) vorangetrieben.745 D. Einhaltung von unternehmensspezifischen Standards (Firmenstandards) Firmenstandards legen die in einem Unternehmen gültigen Standards nach eigenen Überlegungen und Erkenntnissen fest. Die meisten Firmenstandards dürfte es im Bereich der Programmierung744 geben. Es gibt bereits Werkzeuge, 742 743 744

Vgl. HANSEN, H . R . : Wirtschafeinformatik I, a.a.O., S. 570 f. Vgl. o.V.: EISA contra Mikrokanal, in: Personal Computer. 1/1989, S. 98 (98 f.). Bei Bertelsmann werden mit Hilfe von Codierrichtlinien Sprachrestriktionen, Strukturelemente, Namenskonventionen etc. festgelegt. Vgl. WALLMÜLLER, E.; ZINCKE, G . : Die Ersetzbarkeit von Software-Engineering Methoden in der Praxis gezeigt am Beispiel des Bertelsmann-Modells, in: AI: 11/1985, S. 480 (478-483).

308 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

die prüfen, inwieweit die Firmenstandards bei der Entwicklung eingehalten werden.745 E. Selbstdisziplin der Softwareentwickler In Bereichen, in denen es keine Standards gibt oder eventuell vorhandene Standards ungeeignet erscheinen, kann eine einheitliche Vorgehensweise eines Entwicklers zur Standardisierung beitragen. 4.1.1.3 Prinzip der Abstraktion

Die hohe Komplexität betrieblicher Informationssysteme ist in der Vielzahl von Aufgaben, Daten und Beziehungen begründet.746 Die Abstraktion stellt nach K. GEWALD u.a. sogar die einzige Möglichkeit dar, den Komplexitätsgrad zu reduzieren, das heißt komplexe Systeme überschaubar zu machen.747 Durch Zusammenfassen von Gegenständen wird ein neuer, »abstrakter« Gegenstand mit gleichen Eigenschaften gebildet.745 Abstraktion lässt sich daher verstehen als »... das explizite Herausstellen der Gemeinsamkeiten von Gegenständen.«749 Man betrachtet, ausgehend von bestimmten Fragestellungen, nur die dafür relevanten Tatbestände. Alle für eine Fragestellung unwesentlichen Eigenschaften werden also weggelassen und nur die wesentlichen bewusst herausgestellt. Beim Softwareentwurf unterscheidet man zwei Abstraktionsarten: 1. Datenabstraktion, die sich auf die zu betrachtenden Datenobjekte bezieht750 und 2. funktionale Abstraktion, die mit Hilfe von Operatoren erfolgt.

745

746

Vgl. SNEED, H.M.: Software-Qualitätssicherung für kommerzielle Anwendungssysteme, Köln 1988, S. 100. Vgl. ebenso o.V.: »COBCHECK« ein neues Software-Tool zur Unterstützung der COBOL-Programmentwicklung, in: Rochade Report: Vol. 4, 1/1987 S. 2 (2-7). Vgl. ÖSTERLE, H.: Entwurf betrieblicher Informationssysteme, München u.a. 1981, S. 58.

747

Vgl. GEWALD, K.; HAAKE, G.; PFADLER, W.: Software Engineering, a.a.O., S. 63.

745

Vgl. INHETVEEN, R.; LUFT, A.L.: Abstraktion, Idealisierung und Modellierung bei der Spezifikation, Konstruktion und Verifikation von Software-Systemen, in: AI: 12/1983, S. 541 (541-546). WEDEKIND, H.: Betriebsinformatik oder die Lehre von der Abstraktion, Arbeitsteilung und Arbeitslosigkeit, in: BALLWIESER, W.; BERGER, K.-H. (Hrsg.): Information und Wirtschaftlichkeit, Wiesbaden 1985, S. 150 (145-169). Vgl. dazu Kapitel 2.4.2.3

749

750

4.1 Prinzipien der Softwareentwicklung

309

Bei der funktionalen Abstraktion erfolgt eine Aufteilung des Problems in die verschiedenen zu bewältigenden Aufgaben (Funktionen). Beide bauen auf dem Konzept der abstrakten Maschine auf. 4.1.1.3.1 Konzept der abstrakten Maschine Den Ausgangspunkt für das Konzept der abstrakten Maschine bilden die Pole Basismaschine auf der einen und Benutzermaschine auf der anderen Seite. Unter einer Basismaschine der untersten Ebene oder einer realen Maschine soll hier eine EDV-Anlage - also ein Computer in seiner physischen Ausprägung - verstanden werden, so wie er vom Hersteller zur Verfügung gestellt wird. Durch Programme in Maschinensprache (Firmware), die man als niedrigste Abstraktionsstufe betrachten kann, lässt sich der Funktionsumfang der Basismaschine nutzen. Programme eignen sich allgemein dazu, einem Benutzer eine Basismaschine verfügbar zu machen (Bild 4-2). Da die Benutzermaschinen nicht »real« vorhanden sind, sondern erst durch die verwendeten Programme entstehen, spricht man auch von »virtuellen« Maschinen.757 So wird mit Hilfe des Textverarbeitungsprogramms aus dem anwendungsneutralen Computer eine Textbearbeitungsmaschine als Benutzermaschine erzeugt.

B e / \ / nutzer-\ / maschine \

Ί Ν Γ /

/ / /

Funktionen

Programm

'

I U I

\ \

Basismaschine (oder weitere Benutzermaschine)

Bild 4-2: Beziehung zwischen Benutzermaschine

Funktionen \ \

und Basismaschine

Die freie Programmierbarkeit von Rechnern erlaubt es, unterschiedliche Benutzermaschinen auf einer Basismaschine zu implementieren.

751

Vgl. SCHNUPP, P.; FLOYD, C.: Software, Berlin u.a. 1979, S. 16 ff.

310 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Für einen Programmierer stellt ζ. B. der Sprachumfang des Compilers eine Benutzermaschine dar. Mehrere Compiler eines Rechners können als weitere Benutzermaschinen der gleichen Basismaschine angesehen werden. Das Programm »Compiler« übernimmt in diesem Beispiel die Transformation zwischen Benutzer- und Basismaschine. Es stellt die Schnittstelle zwischen benachbarten Abstraktionsebenen her. Programme dienen allgemein als »Brücke« zwischen Benutzer- und Basismaschine. Die Funktionen einer Benutzermaschine müssen durch eine oder mehrere Funktion(en) der Basismaschine realisiert werden. Sie weisen damit einen höheren Abstraktionsgrad als die Funktionen der Basismaschine auf. Grundlage für eine Funktionsentwicklung bildet eine abstrakte Basismaschine. Die Entwicklung selbst entspricht der Konstruktion einer abstrakten Benutzermaschine.7·52 Virtuelle Maschinen lassen sich in mehreren Stufen hierarchisch anordnen.753 Anstelle von Stufen wird auch von (Software-) Schichten oder Abstraktionsebenen gesprochen. Im vorangestellten Beispiel könnte eine weitere übergeordnete Schicht durch einen Programmgenerator realisiert werden. Der Compiler stellt in diesem Fall die Basismaschine für den Programmgenerator dar. Gleichzeitig ist der Compiler Benutzermaschine für die darunterliegende Ebene (Betriebssystem). Geht man davon aus, dass Programme einer Abstraktionsebene ein Ergebnis meist in Form einer Datei erzeugen, so stellt diese Datei die Schnittstelle zwischen den Programmen zweier Abstraktionsebenen dar. Es ist möglich, die hierarchische Strukturierung von Benutzer- und Basismaschinen auch innerhalb der Programme fortzusetzen. Dabei werden innerhalb eines Programms wiederum verschiedene Schichten (Abstraktionsebenen) definiert. Diese unterscheiden sich durch ihre Problem-Hardwarenähe, das heißt durch ihr Abstraktionsniveau voneinander.754 Auch innerhalb des Programms stellen Daten wieder die Schnittstelle zwischen zwei Abstraktionsebenen her. Zusammenfassend lässt sich sagen, dass bei diesem Konzept vor allem die Prinzipien der Hierarchisierung, Abstraktion und Strukturierung zur Anwendung kommen. Das Konzept der abstrakten Maschine eignet sich gut zur Aufteilung eines Systems in Subsysteme mit einer streng hierarchischen Benutzer-Struktur.755 Durch die Softwareschichten wird der Benutzer immer weiter 752 753 754 755

Vgl. SCHUMANN, J.; GERISCH, Μ.: Software-Entwurf, a.a.O., S . 1 3 7 . Vgl. FERSTL, O.K.; SINZ, E.J.: Software-Konzepte, a.a.O., S. 1 4 4 ff. Vgl. TRUÖL, K . ; VIEBEG, U . : Strukturierter Programmentwurf, a.a.O., S. 19. Module unterer Ebenen werden dabei nur von Modulen höherer Ebenen benutzt.

4.1 Prinzipien der Softwareentwicklung

311

von der Hardware und deren Detailproblemen abgeschirmt. Diese Schichten erlauben es, die Kluft zwischen den anwendungsorientierten Problemen des Endbenutzers und einer universellen Hardware zu schließen.756 4.1.1.3.2 Konzept der Datenabstraktion Da das Konzept der Datenabstraktion etwas komplexer ist, soll es weiter untergliedert werden. Zuerst werden die Grundlagen und die Ziele der Datenabstraktion beschrieben. Anschließend wird die Datenabstraktion mit Hilfe von Operatoren dargestellt. Zur Spezifikation von abstrakten Datentypen gibt es mehrere Möglichkeiten, die anschließend dargestellt werden. Eine wertende Betrachtung der Vor- und Nachteile dieses Konzeptes bildet dann den Abschluss dieses Kapitels.757 4.1.1.3.2.1 Ausgangspunkte und Ziele der Datenabstraktion Die Beherrschbarkeit von großen Softwaresystemen wird durch deren Komplexität erschwert. Diese ergibt sich nicht nur durch algorithmische Konstrukte, sondern auch durch komplizierte Datenstrukturen. Bei der Datenabstraktion möchte man die Daten von ihrer »Umwelt« trennen, damit ihre Repräsentation (Speicherung) unabhängig und leicht änderbar wird. Die Daten sollen vor unerlaubtem Zugriff geschützt und der Gültigkeitsbereich von Variablen klar abgegrenzt werden.755 Beispiele für kompliziertere Datenstrukturen:759 - Kellerspeicherung - Warteschlangen - Dateien - Bäume - Netze Eine von mehreren Möglichkeiten zur Datenabstraktion besteht darin, ein einziges Modul zu konstruieren, das die komplizierte Datenstruktur verwaltet. Voraussetzung für ein derartiges Modul ist, dass es alle erforderlichen Funktionen zur Manipulation der Datenstruktur beinhaltet. Alle anderen Module, 756

Vgl. SCHUMANN, J.; GERISCH, M.: Software-Entwurf, a.a.O., S. 137 ff.

757

Vgl. RUF, W.: Ein Software-Entwicklungs-System, a.a.O., S. 82 ff.

758

Vgl. RECHENBERG, P.: Daten- und Programm-Kontrollstrukturen, in: RECHENBERG, P.; SCHAUER, Η.; SCHOITSCH,E. (Hrsg.): Software-Engineering, Wien/München 1983, S. 31.

759 YGJ K U R B E L K.: Software Engineering im Produktionsbereich, a.a.O., S. 1 6 4 ff.

312 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

welche die Datenstruktur bearbeiten, dürfen dies nur unter Zuhilfenahme des einen Moduls, das die Datenstruktur verwaltet, tun. In Bild 4-3 wird der generelle Aufbau eines solchen Moduls dargestellt. Die lokalen Daten und die zu verwaltende Datenstruktur bilden das so genannte Modulgedächtnis. Die Datenabstraktion lässt grundsätzlich eine Blackbox-Betrachtung zu. Die Verwaltung der Datenstruktur ist die Aufgabe dieser Black-box. Durch die Blackbox-Betrachtung ist eine realisierungsunabhängige Beschreibung von Datenstrukturen möglich. Bei der Entwicklung ganzheitlicher Systeme lässt sich die Datenabstraktion als eine Methode zur Bildung von Modulen und zur Spezifikation ihrer Schnittstellen nutzen. Gerade der vollständigen und eindeutigen Spezifikation von Schnittstellen kommt in modularen Softwaresystemen große Bedeutung zu. Die Schnittstellen enthalten dafür sämtliche vorher festgelegten Annahmen, die Module über das Verhalten anderer Module machen.700 Υ / / / / ϊ = externe Funktionen zur Manipulation der Datenstruktur

I

Modul Schnittstelle

Bild 4-3:

Genereller Modulaufbau zur Bearbeitung einer abstrakten Datenstruktur761

Komplexe Informationssysteme lassen sich nicht als Ganzes, sondern nur durch die Integration von Teilsystemen entwickeln. Eine allgemein anerkannte 760

Vgl. PARNAS, D.L.: A Technique for Software Module Specification with Examples, in: CACM:

V o l . 15, 5 / 1 9 7 2 , S. 3 3 0 ff. ( 3 3 0 - 3 3 6 ) .

761 YGJ KURBEL, Κ.: Software Engineering im Produktionsbereich, a.a.O., S. 168.

4.1 Prinzipien der Softwareentwicklung

313

Vorgehensweise besteht darin, sich in mehreren Schritten (Hierarchiestufen) der Problemlösung zu nähern. Vereinfachend wirkt es sich aus, wenn es möglich ist, eine Hierarchiestufe komplett zu bearbeiten, ohne dass die darunterliegenden Stufen genau spezifiziert werden müssen. Dies bedeutet, dass bei der Festlegung von groben Funktionen (Anforderungen) noch keine Realisierungsdetails betrachtet werden sollen. Durch das Konzept der Datenabstraktion wird diese Top-Down-Vorgehensweise wirkungsvoll unterstützt. Es kann in engem Zusammenhang mit dem Konzept der abstrakten Maschine gesehen werden. Im Konzept der Datenabstraktion werden folgende Prinzipien besonders berücksichtigt: das Prinzip der Modularisierung, das Prinzip der Abstraktion, der vollständigen Schnittstellenspezifikation und das Geheimnisprinzip. 4.1.1.3.2.2 Datenabstraktion mit Hilfe von Operatoren (abstrakte Datentypen)

Unter dem Begriff Datenobjekt lassen sich hier (ähnlich wie bei dem EntityRelationship Modell (ERM) zur Datenmodellierung) auch ganz allgemein Gegenstände wie ζ. B. Bildschirmterminal oder Tabelle subsumieren. Diese Datenobjekte können dann mit Operationen (ζ. B. Lesen, Schreiben, Formatieren etc.) bearbeitet werden. Folgende Merkmale der Datenabstraktion mit Hilfe von Operatoren sind zu nennen: 1. Den Mittelpunkt bildet ein Datenobjekt, das mit Hilfe einer Datenstruktur abgebildet und von einem einzigen Modul bearbeitet wird. Ein Modul enthält nur solche Datenstrukturen, die von der Problemstellung her in engem Zusammenhang zueinander stehen. 2. Der Funktionsumfang eines Moduls wird definiert durch die Festlegung aller damit ausführbaren Operationen auf das Datenobjekt. Dadurch lässt sich das äußere Verhalten des Datenobjektes in Abhängigkeit von Operationen (Funktionen) beschreiben.702 Die Summe aller Operationen bildet zusammen mit ihren Namen und Parametern die Schnittstelle des Moduls. 3. Der Benutzer eines Moduls braucht bei der Verwendung nicht zu wissen, wie die einzelnen Funktionen und Datenobjekte letztlich realisiert wurden. 4. Konsequenterweise darf der Benutzer auf das Datenobjekt nur unter Verwendung der festgelegten Operationen zugreifen. Ein Zugriff erfolgt aus-

162

Vgl. SCHUMANN, J.; GERISCH, M . : S o f t w a r e - E n t w u r f , a.a.O., S. 127.

314 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung schließlich über die genau festgelegte Schnittstelle. Keinesfalls darf das Datenobjekt direkt manipuliert werden. Ein Modul, das den oben beschriebenen Bedingungen genügt, bezeichnet man auch als einen »abstrakten Datentyp«. (ADT). E. DENERT definiert einen ADT als »... eine Klasse von Objekten, die durch die Operationen, die mit diesen Objekten ausführbar sind, vollständig charakterisiert ist.«763 Eine weitere Definition wird von H. ÖSTERLE verwendet: »Man beschreibt den (die) Datentyp(en) und die darauf anzuwendenden Funktionen in einer geschlossenen Darstellung und nennt sie einen Abstrakten Datentyp {ADT)«.764 Abstrakte Datentypen werden auch häufig als Datenkapseln bezeichnet. Da ein abstrakter Datentyp meist nicht nur ein einzelnes Datenelement beinhaltet, wird auch von abstrakten Datenstrukturen gesprochen.705 Abstrakte Datentypen dürfen nicht mit elementaren Datentypen verwechselt werden. Unter einem (elementaren) Datentyp versteht man »... die Menge von Werten, die eine Variable, ein Ausdruck oder eine Funktion annehmen kann bzw. zu der eine Konstante gehört.«766 In den verbreiteten Programmiersprachen werden keine abstrakten Datentypen, sondern vordefinierte (elementare) Datentypen verwendet. (Beispiele hierfür sind die Datentypen »integer«, »real«, »character« oder »boolean«.767) Elementare Datentypen können zu größeren Einheiten zusammengefasst werden. Es entstehen dann neue Datentypen wie »Array«, »Record«, »sequentielle Datei« etc. Es entstehen aus der Sicht des Programmierers zusammengesetzte Datenstrukturen.768 Als Beispiel für einen ADT kann man sich eine Tabelle vorstellen, mit deren Hilfe ein Lager dargestellt werden soll. Eine Tabelle besteht aus Tabellenelementen, die wiederum den Behältern eines Lagers entsprechen. Folgende Schritte können bei der Definition eines ADTs unterschieden werden: 1. elementare Datentypen (Sorten), die im ADT verwendet werden.769

763 764

765

766

767 768 769

DENERT, E.: Software-Modularisierung, in: Informatik Spektrum: 4/1979, S. 205 (204-218). ÖSTERLE, H.: Entwurf betrieblicher Informationssysteme, a.a.O., S. 174. Vgl. KURBEL, K . : Programmierstil in Pascal, Cobol, Fortran, Basic, PL/1, Berlin u.a. 1985, S. 25 f. KURBEL, K . : Programmierstil, a.a.O., S. 39. Vgl. WIRTH, N.: Systematisches Programmieren, 3. Auflage, Stuttgart 1978, S. 49 ff. Vgl. KURBEL, K . : Programmierstil, a.a.O., S. 22. Vgl. ÖSTERLE, H . : Entwurf betrieblicher Informationssysteme, a.a.O., S . 1 7 5 ff.

4.1 Prinzipien der Softwareentwicklung

315

2. Festlegen der Funktionen Hier werden die im ADT zu realisierenden Funktionen aufgeführt. - Anlegen der Tabelle (Initialisierung) - Löschen einzelner Elemente (Behälterinhalt) - Hinzufügen einzelner Elemente (Behälterinhalt) - Ändern von Elementen (Behälterinhalt) - Lesen von Elementen (Behälterinhalt) 3. Beschreibung der Wirkungsweisen der Funktionen durch die unterschiedlichen Spezifikationsarten. Auf diese wird nachfolgend in Kapitel 4.1.1.3.2.3 eingegangen. In diesem Beispiel wären der strukturierte Datentyp Tabelle sowie eventuell weiter benötigte elementare Datentypen (Sorten) ζ. B. für Returncodes770 festzulegen. Die endgültige Festlegung und Realisierung der Speicherrepräsentation des Lagers kann dem Benutzer des ADTs verborgen bleiben, das heißt er muss nicht wissen, ob das Lager innerhalb des ADT tatsächlich durch eine Hauptspeichertabelle oder ζ. B. durch eine Datei abgebildet wird. Funktionen lassen sich durch ihren Namen, ihre Parameter und ihre Wirkungsweise definieren. 4.1.1.3.2.3 Möglichkeiten zur Spezifikation von abstrakten Datentypen Bei der Spezifikation steht die Frage, was ein Modul leisten soll, im Mittelpunkt. Es werden die Funktionen, die das Modul seiner »Umwelt« zur Verfügung stellt und seine Schnittstellen nach außen festgelegt.777 Das Ziel ist es, das äußere Verhalten eines Moduls möglichst eindeutig und vollständig zu bestimmen, dabei jedoch nicht Details der Implementierung vorwegzunehmen. Zur Systematik reicht die bloße Aufzählung der Operationen noch nicht aus. Eine Spezifikation kann bspw. erfolgen durch - axiomatische Spezifikation, - operationelle Spezifikation oder - verbale Spezifikation.

770

771

Ein Retumcode ist ein Übergabeparameter, der dem aufrufenden Modul Aufschluß darüber gibt, ob ein aufgerufenes Modul ordnungsgemäß beendet werden konnte. Vgl. DENERT, E.; HESSE, W.: Projektmodell und Projektbibliothek: Grundlagen zuverlässiger Software-Entwicklung und Dokumentation, in: Informatik Spektrum: 4/1980, S. 218 (215-228).

316 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Im ersten Fall wird das Verhalten der ADTs durch ein System von Gesetzen (Axiomen) beschrieben. Vorteilhaft ist diese Methode dadurch, dass Angaben zur Verwendung angegeben werden müssen. Vollständigkeit und Widerspruchsfreiheit der ADTs können aufgrund der Gesetze (Axiome) mit Hilfe formaler Verfahren überprüft werden. Ein eindeutiger Nachteil dieser Spezifikation liegt darin, dass die Aufstellung und Interpretation von Axiomen sehr aufwendig ist. Umfangreiche betriebliche Informationssysteme können derzeit nicht axiomatisch spezifiziert werden,772 weshalb hier auf die weitere Darstellung verzichtet wird. Bei der operationellen Spezifikation werden die Effekte der Operationen in einer algorithmischen Notation umschrieben.773 Mit Hilfe dieser Spezifikation soll ζ. B. durch eine Pseudoprogrammiersprache nur die Bedeutung der Operationen festgelegt werden. Die konkrete Realisierung des Datenobjektes und die endgültige Realisierung der Operationen ist Aufgabe der Implementierung, die sich nicht an die operationelle Spezifikation halten muss. Als Nachteil erweist sich bei der operationeilen Spezifikation, dass sie stets zu Überspezifikationen tendiert und man teilweise dazu gezwungen wird, Details der Implementierung im Vorfeld festzulegen. Ihr Vorteil besteht sicherlich darin, dass die Definition in einer dem Programmierer geläufigen Form erfolgt. Sie ist i.d.R. leichter verständlich als die axiomatische Spezifikation und eignet sich auch zur Spezifikation großer Systeme.774 Bei der verbalen Spezifikation versucht man, die Vorteile des Konzeptes der ADTs ohne den hohen Spezifikationsaufwand der axiomatischen und operationeilen Spezifikation zu nutzen.775 Dazu werden die vom ADT benutzten strukturierten und elementaren Datentypen, die Operationen und die Effekte der Operationen in verbaler Form beschrieben. Nachteile der verbalen Spezifikation liegen in der Verwendung der natürlichen Sprache. Die natürliche Sprache erlaubt es nicht, Sachverhalte unmissverständlich zu beschreiben. Dies liegt daran, dass Worte stets einer

772

773 774 775

Vgl FERSTL, O.K.; SINZ, E.J.: Software-Konzepte, a.a.O., S. 159. Diese Ansicht wird auch von ÖSTERLE, H . : Entwurf betrieblicher Informationssysteme, a.a.O., S. 227, von DENERT, E.: Software-Modularisierung, a.a.O., S. 206 ff. sowie von KIMM, R.; KOCH, W.; SIMONSMEIER, W . ; TONTSCH, F.: Einführung in Software Engineering, Berlin/New York 1995, S. 150 u. S. 169 vertreten. Vgl. DENERT, E.: Software-Modularisierung, a.a.O., S. 206. Vgl. FERSTL, O.K.; SINZ, E.J.: Software-Konzepte, a.a.O., S. 160. Vgl. ÖSTERLE, H.: Entwurf betrieblicher Informationssysteme, a.a.O., S. 179.

4.1 Prinzipien der Softwareentwicklung

317

Interpretation bedürfen und diese von Person zu Person, von Ort zu Ort und von Zeit zu Zeit stark schwanken können.776 4.1.1.3.2.4 Vor- und Nachteile des Konzeptes der abstrakten Datentypen - Der größte Vorteil dieses Konzeptes liegt nach H. ÖSTERLE darin, dass der Entwerfer sich über alle Anwendungen Klarheit verschaffen muss und dass die Schnittstellen der Datentypen offen gelegt werden.777 - Im Idealfall kann man eine klare Trennung von Anwendung (was) und Implementierung (wie) erreichen. Hierdurch wird auch der Top-downAnsatz zum Entwerfen von Systemen wirkungsvoll unterstützt.778 Die Details der Implementierung müssen somit nicht schon in frühen Phasen festgelegt werden. - Die Nutzung des ADTs erfordert keine Kenntnisse der Implementierung. - Es wird eine Modularisierungshilfe gegeben. - Fehler lassen sich gut lokalisieren und beheben. Dadurch steigt auch die Softwarezuverlässigkeit, weil ein Datenobjekt nur von einem Modul mit Hilfe der vorgesehenen Operatoren manipuliert wird. Die Modulschnittstellen werden einfacher und sicherer.779 - Denkt man daran, dass Datenstrukturen auch einer Änderung unterworfen sind, so erreicht man durch ADTs eine gewisse Datenunabhängigkeit, weil sich eine Änderung der Datenstruktur nicht auf andere Module auswirkt. Datenschutzaspekte, die sich auf die Vermeidung von fehlerhaften Daten sowie auf den unbeabsichtigten Missbrauch von Daten beziehen, werden ebenfalls berücksichtigt.780 - ADTs lassen sich auch mit den herkömmlichen Programmiersprachen realisieren. Die in einer Programmiersprache bereits vorhandenen elementaren Datentypen (ζ. B. Integer, Real,...) können durch anwendungseigene Datentypen erweitert werden.

776

Vgl. KLAEREN, H.A.: Algebraische Spezifikation, Berlin/Heidelberg/New York 1983, S. 6. Vgl. ÖSTERLE, H.: Entwurf betrieblicher Informationssysteme, a.a.O., S. 180. 778 Vgl. RECHENBERG, P.: Daten- und Programm-Kontrollstrukturen, a.a.O., S. 57. 779 Vgl. ZOLLER, P.: Abstrakte Datentypen, in: AI: 10/1981, S. 429 (429-431). 780 Ygj LUFT, A.L.: Rationaler Sprachgebrauch und orthosprachliche Standardisierung als Grundlage des Software Engineering, in: Informatik Spektum: 4/1982, S. 217 (209-223). 777

318 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

Die weiteren Vorteile liegen in der Erhöhung der Portabilität, der Unterstützung des Information Hiding und der Gliederung eines großen Datenbestandes. Nach der Darstellung der Vorteile sollen auch die Nachteile herausgearbeitet werden: - Nachteilig erweist sich beim ADT-Konzept, dass die Anforderungen an das Abstraktionsvermögen beim Entwickler sehr hoch sind. - Durch die höhere Strukturierung wechselt der Kontrollfluss zwischen den einzelnen Modulen sehr häufig. - Die zeitaufwendigen Modulaufrufe haben zur Folge, dass das Laufzeitverhalten der Programme negativ beeinflusst wird. Dies bestätigen auch die empirischen Untersuchungen von A. SCHULZ und K. KURBEL.757

- Durch die vielen allgemein gehaltenen Module muss auch mit einem Anstieg der Programmgröße gerechnet werden. Bisher standen die abstrakten Prinzipien und Konzepte im Vordergrund. Diese sollen nach dem Exkurs über die ADT wieder aufgenommen und damit die Prinzipien und Methoden in größere Anwendungsnähe gebracht werden. 4.1.1.4 Prinzip der Hierarchisierung Bei dem Prinzip der Hierarchisierung soll die Komplexität der Beziehungen zwischen den Teilen eines Systems beherrschbar gemacht werden. Durch dieses Prinzip wird das Gesamtproblem sukzessive durch die Einführung von Hierarchiestufen in übersichtlichere Teilprobleme zerlegt. Allgemein spricht man von einem hierarchischen System, wenn: »... die Teile des Systems den Knoten und die Beziehungen zwischen den Teilen den Kanten eines gerichteten Graphen ohne Zyklen entsprechen.«752 Daraus folgt, dass jeder Knoten, außer dem ersten, dem Ausgangsknoten, mindestens einen übergeordneten Vorgängerknoten hat. Von KIMM u.a. werden drei unterschiedliche Hierarchie-Strukturen (Bild 4-4) unterschieden:753

781 Ygj Schulz, Α.: Der Einiluß von Strukturierungsmethoden der Anwendungsprogrammierung auf die Durchlaufzeit von Programmen, in: BRAUER, W. (Hrsg.): Gl - 11. Jahrestagung, IFB-Nr. 50, Berlin/Heidelberg/New York 1981, S. 164 (160-169). KURBEL hat Laufzeitvergleiche durchgeführt zwischen Modulen, die nach dem ADT-Konzept entworfen werden, und Modulen, die keine Modularisierung aufweisen. Dabei verlangsamte sich die Laufzeit teilweise um mehr als ein Drittel bei den nach dem ADT-Konzept entworfenen Modulen. Vgl. KURBEL, K.: Datenstrakturen und Modularisierung, in: Informatik Spektrum: 3/1984, S. 135 (127-137). 782

GEWALD, K.; HAAKE, G.; PFADLER, W.: Software Engineering, a.a.O., S. 60.

4.1 Prinzipien der Softwareentwicklung

319

1. »einfache Hierarchie«. Der Verweis kann über mehrere Stufen erfolgen. 2. »strenge Hierarchie«. Diese kommt dadurch zustande, dass jeder Knoten nur auf Knoten der nächst niedrigeren Stufe hinweist. 3. »baumartig strenge Hierarchie«. Hier hat jeder Knoten maximal einen Vorgänger. Die baumartig hierarchischen Strukturen scheinen das menschliche Verständnis besonders gut zu unterstützen.754

einfache

strenge

baumartig strenge

Hierarchie

Hierarchie

Hierarchie

Bild 4-4: Hierarchische Strukturen Mit der Hierarchisierung wird eine Rangordnung zwischen den einzelnen Knoten hergestellt. Dabei haben die Knoten einer Hierarchiestufe die gleiche Rangordnung. 4.1.1.5 Prinzip der Modularisierung (inkl. Objekte) Mit Modularisierung bezeichnet man die Aufteilung eines zu entwickelnden Gesamtsystems in Module.755 Diese sollen überschaubar, in sich abgeschlossen und aufeinander abgestimmt sein. Damit lassen sich also umfangreiche Problemstellungen in kleine, überschaubare Teile zerlegen, wodurch sich eine Reduktion der Komplexität des zu entwickelnden Informationssystems erzielen lässt. Das Prinzip der Modularisierung sollte grundsätzlich in allen Phasen der Systementwicklung Beachtung finden (Modularisierung im weiteren Sinne), 783 YG|

KIMM, R.; KOCH, W . ;

SIMONSMEIER, W . ; TONTSCH, F.: Einführung

Engineering, a.a.O., S. 114 f. 784

V g l . GEWALD, K.; HAAKE, G.; PFADLER, W.: Software Engineering, a.a.O., S. 72.

785

Vgl. KURBEL, K.: Software Engineering im Produktionsbereich, a.a.O., S. 146.

in

Software

320 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung insbesondere jedoch in den Phasen der Systemkonstruktion und -Implementierung (Modularisierung im engeren Sinne).786 Bei der Entwicklung ganzheitlicher Informationssysteme kommt gerade der Modularisierung eine besondere Bedeutung zu. Ganzheitliche Informationssysteme lassen sich nur sukzessiv durch die Kombination einzelner Programme entwickeln. Die einzelnen Programme müssen selbst einen Modularisierungsprozess durchlaufen. So schreibt ζ. Β. P. RECHENBERG: »Alle Probleme der Programmierung großer Systeme sind Abkömmlinge des einen zentralen Problems: Wie zerlegt man eine große Programmieraufgabe am günstigsten in kleine Teile?«.757 J. SCHUMANN und M. GERISCH sind der Ansicht: »Jede Softwareentwicklung im Großen steht und fallt damit, inwieweit es gelingt, das Modularisierungsprinzip in geeigneter Weise durchzusetzen.«7^ In der Literatur gibt es eine Vielzahl von Definitionen für den Begriff des Moduls. Im Folgenden soll in Anlehnung an K. KURBEL unter einem Modul ganz allgemein ein Baustein in einem Softwaresystem verstanden werden.759 Dieser Baustein liefert für eine vorgegebene Menge von (Übergabe-) Parametern eine vorgegebene Menge von Ausgabewerten nach fest definierten Regeln. Damit aus den Übergabewerten die Ausgabewerte erzeugt werden, bedarf es noch eines Auslösers (Modulaufruf). Bei der Modularisierung lassen sich vier Schritte unterscheiden: 1. 2. 3. 4.

Zerlegung einer komplexen Aufgabe in Teilprobleme Lösung der Einzelprobleme Synthese der Einzellösungen zur Gesamtlösung Überprüfung der Gesamtlösung (Sofern keine zufrieden stellende Lösung erzielt wurde, muss wieder mit Schritt 1 begonnen werden.)

Die Aufteilung eines Gesamtsystems in Module kann sich zum einen an allgemeinen Kriterien und zum anderen an schnittstellenbezogenen Kriterien orientieren. Die allgemeinen Kriterien stellen gewissermaßen »Faustregeln« dar. Schnittstellenbezogene Kriterien betreffen dagegen die Art und Weise, wie Beziehungen zwischen zwei Modulen realisiert werden. Bei beiden Arten von Kriterien handelt es sich um allgemeine gedankliche Hilfsmittel. Diese sind zunächst unabhängig von der verwendeten Program-

786 VGL BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 44. 787 RECHENBERG, P.: Daten- und Programm-Kontrollstrukturen, a.a.O., S. 32. 788

SCHUMANN, J.; GERISCH, M.: Software-Entwurf, a.a.O., S. 109 f.

789 YGI KURBEL, K.: Programmentwicklung, 3., überarbeitete Auflage, Wiesbaden 1985, S. 42.

4.1 Prinzipien der Softwareentwicklung

321

miersprache. Zunächst wird mit den erwähnten allgemeinen Kriterien begonnen, bevor auf die schnittstellenbezogenen Kriterien eingegangen wird. A. Allgemeine Kriterien der Modularisierung a) Zweckfestlegung Dieses erste Kriterium legt fest, für welche Aufgaben und damit für welche Zwecke ein Modul innerhalb eines Gesamtsystems verantwortlich ist. Dokumentiert wird dies in kurzer, prägnanter Form eventuell in natürlicher Sprache. Mit der Zweckfestlegung will man die »lokale Verständlichkeit« und »das Schaffen kleiner überschaubarer Einheiten« unterstützen. Die Zweckfestlegung bildet die Grundlage für die nachfolgende Modulbeschreibung.790 b) Prinzip der Abgeschlossenheit Innerhalb des Prinzips der Modularisierung soll das Prinzip der Abgeschlossenheit erkennen lassen, dass es sich bei dem gebildeten Modul um eine Entwurfsentscheidung handelt. Das heißt, das Modul bildet eine abgeschlossene logische Einheit (Entwurfseinheit), die für sich verständlich ist. c) Erfahrungs- und Richtwerte für die Modularisierung - Ein Modul sollte nicht zu groß werden (Modulgröße) Oft wird die Modulgröße in Anzahl Programmzeilen gemessen.791 Bei diesem relativ subjektiven Kriterium hat die verwendete Programmiersprache großen Einfluss. In der Literatur findet man sehr abweichende Vorstellungen über die Modulgröße. So sehen bspw. P. SCHNUPP und C. 792 FLOYD 3 0 0 - 1 0 0 0 Anweisungen als wünschenswert an, dagegen geht 795 E. WALLMÜLLER von 4 0 - 5 0 Verarbeitungsanweisungen aus. - Schwer zu programmierende oder sehr änderungsanfallige Teile sollten in ein Modul ausgelagert werden.794 790 791

Vgl. HRUSCHKA, P.: Prinzipien der Modularisierung, in: HMD: 130/1986, S. 69 (67-75). E. DENERT schlägt vor, die Modulgröße an der Bearbeitungskapazität einer einzelnen Person zu orientieren. Vgl. DENERT, E.: Sofitware-Modularisierung, a.a.O., S . 207. J. SCHUMANN und M. GERISCH empfehlen 1-2 Druckseiten Quellcode als obere Grenze bei höheren Programmiersprachen. Vgl. SCHUMANN, J.; GERISCH, M.: Software-Entwurf, a.a.O., S. 107. D.B. MORREY und J. PUGH nennen eine »übliche« Größe von einer Seite (40-50 Zeilen), wobei aber aus psychologischen Gründen ein Modul aus höchstens 7 Zeilen bestehen sollte. Vgl. MORREY, D.B.; PUGH, J.: Software Engineering, Englewood Cliffs 1987, S. 28.

792

Vgl. SCHNUPP, P.; FLOYD, C.: Software, a.a.O., S. 170.

795

Vgl. WALLMÜLLER, E.: Softwareengineering in der Anwendungsprogrammierung, Dissertation, Wien 1984, S. 63. Vgl. GEWALD, K.; HAAKE, G . ; PFADLER, W.: Software Engineering, a.a.O., S. 77.

794

322 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Dies gilt ζ. B. für den Aufbau von Bildschirmmasken. Bei Standardsofitware wird von unterschiedlichen Kunden immer wieder ein unterschiedlicher Maskenaufbau mit individuellen Variablennamen gewünscht. Sofern man sich nicht dazu entschließt, ein universelles Hilfsmittel (Maskengenerator) zu verwenden, sollte wenigstens der Maskenaufbau durch ein eigenständiges Modul gewährleistet werden. - Ein Modul sollte selbständig kompilierbar sein. Damit wird die Testbarkeit wesentlich erhöht. - Portabilitätsgesichtspunkte sollten beachtet werden, ζ. B. die Realisierung der Datei- bzw. Datenbankzugriffe über isolierte Module. - Programmteile, die Ausnahmesituationen bearbeiten, sollen ebenfalls in separaten Modulen abgehandelt werden, ζ. B. Behandlung von allgemeinen Fehlersituationen durch abgegrenzte Module. Weitere Beispiele für Ausnahmesituationen sind: - Wiederanlauf routinen -Info-Routinen -Hilfe-System B. Schnittstellenorientierte Kriterien der Modularisierung Die schnittstellenorientierten Kriterien werden danach unterteilt, - wie durch die Gestaltung der Modul-Schnittstellen relativ unabhängige Module entstehen (a), - wie es möglich ist, Module zu bilden, die eine hohe innere Festigkeit aufweisen (b) und - wie die Modulkopplungsmechanismen aus Sicht der Programmiersprache gestaltet werden können (c). a) Prinzip der Unabhängigkeit Das Ziel ist es, die einzelnen Module so zu konzipieren, dass sie unabhängig von ihrer Programmumgebung sind. Dies wird dann erreicht, wenn die (Übergabe-) Parameter in den Schnittstellen möglichst einfach sind (aa) und möglichst wenig »Annahmen« über das Modulverhalten im Inneren (ab) beinhalten. aa) (Übergabe-) Parameter von Schnittstellen Für das aufgerufene Modul stellen die veränderlichen Eingangs- und Steuerungsdaten die (Übergabe-) Parameter dar. Die Anzahl der Parameter sollte klein gehalten werden. Dadurch entsteht die Forderung an die Modul-Schnittstelle, dass in ihr nicht ein Maximum, sondern nur ein Minimum an Informa-

4.1 Prinzipien der Softwareentwicklung

323

tionen enthalten sein sollte.795 Am besten wird diese Forderung erfüllt, wenn zwischen den Modulen überhaupt kein Datentransfer stattfindet. Beispiel: Mehrere Anwendungsmodule werden einem Benutzer über ein Auswahlmenü angeboten. Nach Beendigung eines Moduls soll wieder in das Auswahlmenü verzweigt werden. In diesem Fall kann es genügen, dass die einzelnen Module ohne Übergabeparameter aufgerufen werden. Diese Maximalforderung lässt sich jedoch in den wenigsten Fällen einhalten. Die Parameter, die zu übergeben sind, kann man unterteilen in:796 -

Basisdatentypen (einfache Daten, ζ. B. vom Typ integer, real) Datenstrukturen (ζ. B. Record, Datei) Durch die Zusammenfassung mehrerer Basisdatentypen erfolgt hier eine Datenstrukturkopplung. Beispiel: Ein Modul liest einen Datensatz aus einer Datei und übergibt ihn in entsprechend aufbereiteter Form an das aufrufende Modul. Nachteilig erweist sich bei der Berücksichtigung von Übergabedatenstrukturen, dass Änderungen in der Datenstruktur Auswirkungen auf mehrere Module haben können. - Kontrollelemente (Steuerungskopplung) Bei der Steuerungskopplung enthält die Schnittstelle die Funktions- bzw. Fehlercodes. Diese werden im aufgerufenen Modul zur internen Ablaufsteuerung benutzt. Beispiel: Über ein Modul können 2 Funktionen realisiert werden. Die Funktionsauswahl wird vom aufrufenden Modul über einen Funktionscode gesteuert, der Bestandteil der Schnittstelle ist. - externe Datenelemente Eine Verbindung zweier Module über externe Datenelemente liegt vor, wenn sich beide auf dasselbe extern definierte Datenelement (ζ. B. eine globale Variable) beziehen. - nicht lokale Daten (Common-Bereiche) Mehrere Module operieren hier mit mehreren gemeinsamen Variablen. Jedes Modul kann in diesem gemeinsam nutzbaren Common-Bereich Änderungen vornehmen. (Als Beispiele seien hier die »COMMON«-Anweisung in FORTRAN und die »EXTERNAL«-Anweisung in PL/1 angeführt.) Nachteilig 795

V g l . SCHAUER, H.: M e t h o d e n d e s S o f t w a r e - E n g i n e e r i n g , in: RECHENBERG, P.; SCHAUER, H . ;

SCHOITSCH, E. (Hrsg.): Software-Engineering, Wien/München 1983, S. 21 (9-28). sowie PARNAS, D.L.: On the Criteria To Be Used in Decomposing Systems into Moduls, in: CACM: V o l . 1 5 , 1 2 / 1 9 7 2 , S. 1 0 5 6 ( 1 0 5 3 - 1 0 5 8 ) . 7 9 6

V g l . GEWALD, K . ; HAAKE, G . ; PFADLER, W . : S o f t w a r e E n g i n e e r i n g , a . a . O . , S . 7 4 FF.

324 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung erweisen sich bei derartigen gemeinsam nutzbaren, nicht lokalen Datenbereichen die schlechte Verständlichkeit, Fehleranfalligkeit durch Nebeneffekte oder auch ein erhöhter Wartungsaufwand. Trotz dieser Nachteile kann es in großen Systemen bspw. dann sinnvoll sein, Common-Bereiche zu definieren, wenn man eine gemeinsame Datenbasis als Mittelpunkt verschiedener Module bilden will. 797 ab) »Annahmen«, die Module übereinander machen Parameter können auch Annahmen beinhalten, wie Verarbeitungsabläufe in anderen Modulen zu erfolgen haben. Je mehr Annahmen getroffen werden, desto schwieriger wird es, voneinander wirklich unabhängige Module zu entwickeln. Außer den in einer exakten Schnittstellendefinition enthaltenen Informationen sollten Module keine Informationen über Verarbeitungsschritte oder Variablenzustände in anderen Modulen benötigen. Dieser Gedanke wird im folgenden nochmals (beim Geheimnisprinzip) aufgegriffen. b) innere Festigkeit (Kohäsion) Die innere Festigkeit eines Moduls soll maximiert werden. Diese bezieht sich auf die Stärke der Zusammenhänge zwischen den Elementen innerhalb eines Moduls. Bei der inneren Festigkeit können wieder mehrere Abstufungen unterschieden werden. Die engste und beste Form stellt die »funktionale Festigkeit« dar. Sie ist gegeben, wenn in einem Modul nur eine einzige Funktion realisiert wird (ζ. B. Modul zur Ermittlung der Quadratwurzel).795 Die loseste und schlechteste Bindungsform innerhalb eines Moduls liegt bei der »zufalligen Festigkeit« vor. Bei einem Modul mit zufalliger Festigkeit wird willkürlich festgelegt, welche Funktionen darin realisiert werden. Ein solches Modul kann entstehen, wenn ζ. B. aus Speicherplatzgründen ein großes Modul in mehrere kleine zerlegt wird. 799 Bei der Konzeption von Modulen lassen sich nicht immer alle Maximalforderungen erreichen. Die Dominanz anderer Prinzipien oder Praktikabilitätsaspekte, wie Laufzeitverhalten, verfugbarer Hauptspeicher, Wartungsaspekte usw., können eine andere Modularisierung erfordern. c) Modulkopplungsmechanismen Der Modulkopplungsmechanismus bezieht sich darauf, wie ein Modul von einem anderen Modul aus aktiviert werden kann. Dabei werden die gemeinsam benutzten Datenelemente benannt, und der Start der Verarbeitung wird akti797

Vgl. RECHENBERG, P.: Daten- und Programm-Kontrollstrukturen, a.a.O., S. 39 f. 798 YGJ KURBEL, K.: Software Engineering im Produktionsbereich, a.a.O., S. 147 ff. 799 y g j HRUSCHKA, P.: Prinzipien der Modularisierung, a.a.O., S. 73.

4.1 Prinzipien der Softwareentwicklung

325

viert/ 00 Die Aktivierung erfolgt in den gebräuchlichsten Sprachen mit Hilfe des CALL-Befehls. Ein CALL-Befehl ruft ein bestimmtes Modul auf und überträgt die an das Modul zu übergebenden Parameter. Beispiel: COBOL: CALL

"SUB-PROG"

USING

A B C .

FORTRAN oder PL/1: CALL

SUB-PROG

(A,B,C)

Hinweis: Der GOSUB-Befehl in BASIC oder der PERFORM-Befehl in COBOL stellen keinen Modulaktivierungsbefehl dar. Hierbei wird lediglich an eine bestimmte Programmstelle innerhalb eines Moduls verzweigt und nach Ablaufeines Programmteils zurück verzweigt. 4.1.1.6 Weitere Grundsätze Neben den beschriebenen allgemeinen Prinzipien sollten bei der Entwicklung von Softwaresystemen weitere Grundsätze Anwendung finden: -

-

Grundsatz der Lokalität: Konzentration auf die Problembereiche des Istsystems, übersichtliche Gestaltung der Dokumentation durch Zusammenfassung der relevanten Information an einem Ort/ 07 Grundsatz der integrierten Dokumentation: Vollständige und entwicklungsbegleitende Dokumentation aller Phasen und Phasenergebnisse mit den Anforderungen adressaten-, aufgaben-, inhalts-, form-, sprach-, didaktik-, Zeitpunkt-, umfangsgerecht.502

Nach den allgemeinen, in jeder Phase anwendbaren Prinzipien wird im folgenden auf solche für spezielle Phasen eingegangen. 4.1.2 Prinzipien zur Problem- und Systemspezifikation Bei der Problem- und Systemspezifikation sollen die vorhandenen Probleme des bestehenden Systems im Rahmen einer Istanalyse herausgearbeitet werden und die Rahmenbedingungen für ein eventuell neu zu gestaltendes oder für ein zu

800

Vgl. LIFFICK, B.W.: The Software Developer's Sourcebook, Massachusetts 1985, S. 30. Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 4 und S. 67 f. 802 v g i BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 49-51. 801

326 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung ergänzendes System festgelegt werden/ 05 Als für diese Phasen besonders bedeutsame Prinzipien werden nacheinander das Prinzip der Vollständigkeit, das Prinzip der Intersubjektivität, das Prinzip der Integrierbarkeit und das Prinzip der vollständigen Schnittstellendefinition erläutert. 4.1.2.1 Prinzip der Vollständigkeit Mit dem Prinzip der Vollständigkeit soll erreicht werden, dass mit der durchzuführenden Istanalyse alle für die Systemerweiterung wesentlichen Tatbestände ermittelt werden. Dies geschieht aufgrund der Systemabgrenzung, mit der ein Subsystem (Realitätsausschnitt) herausgebildet wird/ 04 Es müssen vor allem die Schnittstellen zu allen angrenzenden Systemen genau ermittelt werden. Das Prinzip der Vollständigkeit hat nicht zum Ziel, dass alle Funktionen, Objekte und Abläufe des bestehenden Systems bis ins letzte Detail dargestellt werden. Man will lediglich eine der Aufgabenstellung angepasste Erhebung sicherstellen und garantiert sehen, dass nicht wesentliche Einflussgrößen übersehen werden. Beispiel: Das bestehende manuelle Lagersystem soll analysiert und eventuell durch ein DV-gestütztes Lagersystem ersetzt werden. Dazu müssen alle wesentlichen Funktionen (Einlagerung, Auslagerung, Inventur usw.) und alle Abläufe (Aufspaltung ζ. B. des Einlagerungsvorgangs in die zeitlich nacheinander ablaufenden Teilschritte) vollständig ermittelt werden. Nicht zum Erhebungsbereich gehört bei dieser Aufgabenstellung die Ermittlung der physischen Kennzahlen des Regalsystems (ζ. B. Traglast, Behältergrößen, Deckenbelastung). Das Prinzip der Vollständigkeit steht damit dem allgemeinen Wirtschaftlichkeitsprinzip nicht entgegen; vielmehr wird dieses durch die ganzheitliche Betrachtungsweise langfristig sogar unterstützt. 4.1.2.2 Prinzip der Intersubjektivität Bei der Problemspezifikation sollen vorhandene Probleme erkannt und dokumentiert werden. Dies kann bei den zuständigen Verantwortlichen zu (berech803

804

Vgl. BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 265 ff. Vgl. WEDEKIND, H.: Systemanalyse, 2., durchgesehene Auflage, München/Wien 1976, S. 36.

4.1 Prinzipien der Softwareentwicklung

327

tigten) Aversionen und Akzeptanzproblemen führen, wenn die Problemursachen von Fehlern nicht zweifelsfrei nachgewiesen werden. Das Prinzip der Intersubjektivität fordert, dass sowohl der Ablauf der Problemspezifikation/Istanalyse als auch die gewonnenen Erkenntnisse intersubjektiv nachprüfbar sein müssen. Man will damit vermeiden, dass nur Ergebnisse dokumentiert werden. Auch die Zwischenschritte und das zugrunde gelegte Ausgangsmaterial sollen in vollständiger und aufbereiteter Form dokumentiert werden. Bei konsequenter Anwendung müsste im Idealfall ein neutraler Fachmann dann zu den gleichen Ergebnissen kommen. Ein wichtiges Hilfsmittel zum Erreichen und Kontrollieren einer Intersubjektivität liegt in diesem Zusammenhang in der Ermittlung von Kennzahlen und deren Vergleich.505 Kennzahlen haben den Vorteil, dass sie -

eindeutig definiert sind, Vergleiche erlauben, frei von »Emotionen« sind und bei gleichem Ausgangsmaterial gleiche Ergebnisse erbringen und damit intersubjektiv nachprüfbar sind.

Typische Kennzahlen sind: . . . ...... Arbeitsproduktivität =

Produktionsmenge — Zeitaufwand

„ .„ . . Stillstandsgrad

=

Stillstandszeit Sollproduktionszeit

. Ausschussquote

=

Ausschußmenge s — Erzeugungsmenge

4.1.2.3 Prinzip der Integrierbarkeit Die Ergebnisse der Problemspezifikation sind nicht nur für die direkt nachfolgende Phase - die Systemspezifikation - von Interesse. Auch alle anderen Phasen partizipieren von diesen Ergebnissen. Dabei ist insbesondere Bezug auf angrenzende Systeme zu nehmen, denn bei der Systemimplementierung wird ζ. B. auf die Dokumentation der Schnittstellen zu den angrenzenden Systemen

805

Vgl. LOCKEMANN, P.C. u.a.: Systemanalyse, Berlin u.a. 1983, S. 29 und S. 79.

328 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

zurückgegriffen. Das Prinzip der Integrierbarkeit fordert, dass der Informationsbedarf der nachfolgenden Phasen mitberücksichtigt wird. Beispiel: Bei der Problemspezifikaton wird beschrieben, wie welche Ergebnisse unter Mitwirkung welcher Systeme erzielt werden. Diese Dokumentation kann damit bei der Systemverifikation zur Prüfung des neuen ganzheitlichen Systems verwendet werden. 4.1.2.4 Prinzip der vollständigen Schnittstellenspezifikation Softwaremodule kommunizieren über eine festgelegte Schnittstelle miteinander. Nur Leistungen eines Moduls, die über die Schnittstelle den aufrufenden Modulen zur Verfügung gestellt werden, sind nutzbar.506 Bei der Entwicklung eines Moduls dienen die durch die Schnittstellendefinition festgelegten Leistungen (Outputs) den Entwicklern als Vorgabe. Unvollständige oder fehlerhafte Vorgaben führen somit zwangsläufig zu fehlerhaften Ergebnissen. Weiterhin ermöglicht eine vollständig beschriebene Schnittstelle, dass die einzelnen Module unabhängig voneinander entwickelt werden können.Ä07 Nach Fertigstellung eines Moduls muss sodann geprüft werden, ob die realisierte Schnittstelle allen Vorgaben entspricht. Aus diesen Gründen ist eine vollständige Schnittstellendefinition für jedes Modul ein »prinzipielles« Anliegen. Eine vollständige Schnittstellenspezifikation setzt die Einhaltung folgender Punkte voraus: - Verständlichkeit der Schnittstellendefinition - vollständige Beschreibung aller Funktionen und Daten der Schnittstelle - Schnittstellenzustand beim Modulaufruf - Schnittstellenzustand bei der Ergebnisübertragung - Festlegung der Erweiterungsmöglichkeiten der Schnittstelle 4.1.3 Prinzipien zur Systemkonstruktion und -Implementierung Als Prinzipien mit Schwerpunkt in den Phasen der Systemkonstruktion und -Implementierung werden im folgenden dargestellt: -

das Prinzip des Information Hiding das Prinzip der Strukturierung

806

Vgl. BALZERT, H . : Die Entwicklung von Software-Systemen, a.a.O., S. 2 4 9 . Vgl. DIBMANN, S.; ZURWEHN, V.: Software-Praktikum - Ein praxisorientiertes Vorgehen zur Software-Erstellung, Stuttgart 1988, S. 37.

807

4.1 Prinzipien der Softwareentwicklung -

329

das Prinzip der linearen Kontrollstrukturen das Prinzip der vollständigen Schnittstellenspezifikation

4.1.3.1 Prinzip des Information Hiding (Geheimnisprinzip) und der Kapselung Das Prinzip des Information Hiding geht auf D.L. PAHNAS zurück. Entwurfsentscheidungen jeglicher Art sollten möglichst nur lokalen Charakter haben, das heißt diese sind auf ein Modul beschränkt, so dass dieses abgeschlossen und fur sich selbst lebensfähig ist.808 D.L. PARNAS möchte dadurch gleichzeitig erreichen, dass der Benutzer eines solchen Bausteines nur Kenntnisse über die Modul-Schnittstellen, aber keine Kenntnisse über die konkrete Implementierung des Moduls und der verwendeten Datenstrukturen haben muss.Ä0P Diese strikte Abgrenzung hat den Vorteil, dass ein Modul die für einen Benutzer unwesentlichen Entwurfsentscheidungen in seinem Inneren als sein »Modulgeheimnis« wie eine »Black box« verbirgt. Somit wird der Austausch von Bausteinen vereinfacht. Typische »Modulgeheimnisse« sind: s;o -

innere Datenstrukturen mit den darauf arbeitenden Zugriffsfunktionen und Hardwareeigenschaften.

Es soll aber auch hervorgehoben werden, dass sich auf höheren Hierarchieebenen mit dem »Geheimnisprinzip« auch Entscheidungsprozesse oder Strategien verbergen lassen. Bild 4-5 zeigt ein Beispiel für das Verbergen von Implementierungsentscheidungen in einem Modul, das die Zugriffs- und Manipulationsprozeduren fur eine bestimmte Datenstruktur verbirgt. In Teil a) greifen mehrere Module auf eine gemeinsame Datenstruktur (Tabelle) zu. Ein grundsätzlich anderer Aufbau ergibt sich in Teil b), indem unter Beachtung des Geheimnisprinzips auf eine gemeinsame Datenstruktur (Tabelle) über ein weiteres Modul zugegriffen wird. a) Modulstruktur ohne Beachtung des Geheimnisprinzips b) Modulstruktur unter Beachtung des Geheimnisprinzips Die Anwendung dieses Prinzips wirkt sich besonders vorteilhaft aus auf: 808

Wartungs-, Änderungs- und Testfreundlichkeit Portabilität

Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 46. 809 y g l PARNAS, D.L.: On the Criteria, a.a.O., S. 1056. 810 Vgl. HRUSCHKA, P.: Prinzipien der Modularisierung, a.a.O., S. 70.

330 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

- Softwarezuverlässigkeit - Datenkonsistenz - Verteilungsmöglichkeiten von Aufgaben bei der Softwareentwicklung Die Einhaltung dieses Prinzips wird besonders stark durch das Konzept der Datenabstraktion unterstützt.

Datenstruktur (z.B. Tabelle)

a) Modulstruktur ohne Betrachtung des Geheimnisprinzips

b) Modulstruktur unter Beachtung des Geheimnisprinzips

Bild 4-5: Modulstruktur und das Geheimnisprinzip%

811

Vgl. SCHNUPP, P.; FLOYD, C.: Software, a.a.O., S. 187 f.

11

4.1 Prinzipien der Softwareentwicklung

331

4.1.3.2 Prinzip der Strukturierung

Die Strukturierung eines Produktes bezieht sich auf ein erkennbares Organisationsmuster der voneinander abhängigen Produktteile.Si2 Durch die Strukturierung wird versucht, eine klare Gliederung herzustellen, die dazu beiträgt, komplexe Vorgänge beherrschbar zu machen/ 75 Zur Strukturierung benötigt man Kriterien, die eine einheitliche Gliederung ermöglichen. Als Kriterien eignen sich unter anderem Gesichtspunkte, die sich aus der Hierarchisierung, Abstraktion und Modularisierung ergeben. Eine Strukturierung lässt sich auch durch die Anwendung von Strategien (Bottom-up-/Top-down-Strategie) und den Einsatz von Methoden, Verfahren und Werkzeugen erleichtern. Durch die Anwendung von Werkzeugen wie Programm-Generatoren kann sogar eine bestimmte Struktur vorgegeben werden. 4.1.3.3 Prinzip der linearen Kontrollstrukturen

Dieses Prinzip muss von einer »strukturierten Vorgehensweise« unterschieden werden. Es wird auch als Prinzip der strukturierten Programmierung (im engeren Sinne) bezeichnet. Dem Prinzip der linearen Kontrollstrukturen liegt ein Strukturtheorem zugrunde, das besagt, dass sich jedes Programm mit einem Ein- und Ausgang aus den drei Grundstrukturen - Sequenz (Reihung) - Auswahl (Entscheidung) und - Wiederholung (Schleife) zusammensetzen lässt/ 74 Programme, die nach diesem Prinzip entworfen werden, weisen lineare Kontrollstrukturen (= Steueranweisungen) auf. Es ist grundsätzlich möglich, ein Programm mit nur diesen drei Grundelementen zu entwerfen. Der Begriff »Structured Programming« geht auf E.W. DlJKSTRA zurück. Von ihm wurde beobachtet, dass die Qualität eines Programms umgekehrt proportional zur Anzahl verwendeter GOTO-Anweisungen ist/ 7 5 Auf GOTO812 813

814

815

Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 13. Vgl. BENDER, H . ; REMMELE, W . ; SCHNEIDER, M . : Entwurf von Software, in: Computer Magazin: 9/1984, S. 50 (50-52). Vgl. KIRSCH, W.; BÖRSIG, C.; ENGLERT, G.: Standardisierte Anwendungssoftware in der

Praxis, Berlin 1979, S. 138 f. Vgl. DIJKSTRA, E . W . : Go To Statement Considered Harmful, in: CACM: Vol.ll, 3/1968, S. 147 f. (147 f.).

332 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Anweisungen kann vollkommen verzichtet werden. Eine GOTO-freie Programmierung kann andererseits aber zu Nachteilen - ζ. B. bei der Effizienz führen. 576 4.1.4 Prinzipien zur Systemverifikation, -einführung und -Wartung Nachfolgend werden Prinzipien für die »späten« Phasen des Entwicklungsprozesses beschrieben, deren Ablauf und Inhalt noch wenig strukturiert und verallgemeinert sind. Diese Sammlung von Einzelprinzipien lässt sich deshalb durchaus noch erweitern. Hier werden die Prinzipien der externen Qualitätssicherung, der frühzeitigen Verifikation und der sukzessiven Systemeinführung beschrieben. 4.1.4.1 Prinzip der externen Qualitätssicherung Dem Prinzip der externen Qualitätssicherung liegt die Annahme zugrunde, dass eine wirkungsvolle Qualitätssicherung nicht durch die Entwickler selbst, sondern nur durch eine externe Instanz sinnvoll möglich ist. 577 Diese neutrale Stelle sollte die Qualität von Softwareprojekten und von Softwaresystemen beurteilen. Die Qualitätssicherung erfolgt anhand von vorzugebenden und überprüfbaren Kriterien. Im Beispiel von Bild 4-6 wird eine Prüfung der Projektqualität an den Kriterien Termineinhaltung, Kosten und sonstigen Faktoren (ζ. B. Zufriedenheit der Projektmitglieder, Fluktuation, Produktideen, Methodeneinsatz) durchgeführt. Die Überwachung der Produktqualität lässt sich, wie in Kapitel 4.3 noch dargestellt wird, ebenfalls anhand von Qualitätskriterien beurteilen. Zur externen Qualitätssicherung können verschiedene Maßnahmen aus unterschiedlichen Entwicklungsbereichen ergriffen werden. Die in Bild 4-7 erwähnten organisatorischen Maßnahmen betreffen das Organisationsschema der Entwicklung (ζ. B. Phasenschema). Die konstruktiven Maßnahmen betreffen die verwendete Aufbaustruktur eines ganzheitlichen Informationssystems bzw. Teilbereiche daraus. Mit analytischen Maßnahmen will man nachträglich Informationssysteme oder Teilbereiche daraus auf einzelne Qualitätsmerkmale prüfen. 816 817

Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 22. Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 450.

4.1 Prinzipien der Softwareentwicklung

333

Qualitätssicherung

Produktqualität

Projektqualität

L

Termine

siehe Kapitel 4.3

Kosten sonstige Kriterien

Bild 4-6: Externe Qualitätssicherung

Maßnahmen zur Qualitätssicherung organisatorische Maßnahmen

konstruktive Maßnahmen

phasenbezogen

analytische Maßnahmen

phasenübergreifend

Bild 4-7: Maßnahmen zur Qualitätssicherung

4.1.4.2 Prinzip der frühzeitigen Verifikation H.M. SNEED berichtet, dass ein Code-Fehler ca. fünfmal soviel kostet, wenn er nach der Systemintegration und nicht gleich in der Codierungsphase behoben wird. Wenn derselbe Fehler nach der Systemfreigabe entdeckt wird, kostet die Fehlerbehebung bereits das lOfache. Liegt der Fehler nicht in der Codierphase, sondern schon früher, so wird die Fehlerbehebung nochmals wesentlich teurer. 818

Vgl. SNEED, Η. M.: Software-Qualitätssicherung, a.a.O., S. 46 ff.

334 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Sofern ein Softwaresystem erst nach Fertigstellung verifiziert wird, ist im Fehlerfall ein hoher Korrekturaufwand zu erwarten. Generell gilt also: Je später ein Fehler festgestellt wird, desto höher sind die Korrekturaufwendungen. Dies wird auch durch empirische Tests von B.W. BOEHM nachgewiesen.579 Mit dem Prinzip der frühzeitigen Verifikation soll erreicht werden, dass in allen Entwicklungsphasen zusätzlich eine Verifikation erfolgen sollte, um so früh wie möglich Fehler zu finden.520 4.1.4.3 Prinzip der sukzessiven Systemeinführung Große Systeme können in ihrer Gesamtheit nicht in nur einem einzigen Schritt eingeführt werden. Eine schrittweise Einführung bietet sich aus mehreren Gründen an: -

Die Möglichkeiten und Fähigkeiten der späteren Nutzer lassen sich besser berücksichtigen. - Erforderliche Ausbildungsmaßnahmen können nach und nach ergriffen werden. - Das Ausfallrisiko großer Bereiche wird verkleinert. - Erfahrungen aus der Einführung kleiner Teilbereiche können für die weitere Entwicklung und Einführung genutzt werden. Nachteilig erweist sich bei diesem Prinzip, dass während der Systemeinführung teilweise das bestehende und das neue System nebeneinander gepflegt werden muss. Dies führt zwar einerseits zu einer Doppelbelastung der Mitarbeiter, andererseits gewährleistet es jedoch eine gute Kontrollmöglichkeit der Ergebnisse des neuen Systems. Nachdem bisher die Prinzipien der Softwareentwicklung im Vordergrund standen, wird im Folgenden auf die Konzepte eingegangen. 4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung Die begriffliche Unterscheidung zwischen Strategien, Methoden, Techniken und Verfahren ist mitunter schwierig. In der Literatur findet man bei vielen Autoren unterschiedliche Begriffsdefinitionen und Zuordnungen.

819 820

821

Vgl. BOEHM, B.W.: Wirtschaftliche Software-Produktion, Wiesbaden 1986, S. 34 f. In der Phase der Systemverifikation soll das entwickelte System in seiner Gesamtheit einer Verifikation unterzogen werden. Bezüglich unserer Begriffsauffassung verweisen wir auf Kapitel 1.2

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

335

Zusammenfassend lassen sich Strategien, Methoden, Techniken und Verfahren als »gedankliche Hilfsmittel« der Softwareentwicklung verstehen. Sofern wir Unterschiede bewusst betonen wollen, werden wir explizit darauf hinweisen. Durch den Begriff der »gedanklichen Hilfsmittel« nehmen wir eine Abgrenzung gegenüber den »DV-unterstützten Hilfsmitteln«, den Tools vor. Es gibt eine Vielzahl von gedanklichen Hilfsmitteln, die im Rahmen des Softwareengineerings Anwendung finden. Keines hat sich in einer Weise durchgesetzt, dass man es als »Standard« bezeichnen könnte.522 Deshalb werden exemplarisch einige besonders verbreitete gedankliche Hilfsmittel vorgestellt. Bevor jedoch darauf eingegangen wird, diskutieren wir am Beispiel von Methoden ihre generellen Möglichkeiten und Grenzen sowie die Anforderungen aufgrund einer phasenorientierten Entwicklung.523 4.2.1 Möglichkeiten und Grenzen von Methoden Prinzipiell ist der Methodeneinsatz für alle Aufgabengebiete des Softwareengineerings geeignet. Durch seine Anwendung soll auf die Entwicklungsziele - Softwarequalität, - Entwicklungskosten, - Entwicklungsdauer und - Anwendbarkeit durch die Nutzer eingewirkt werden. Tendenziell gilt: Je mehr Methoden zum Einsatz kommen, desto höher ist das Niveau des Entwicklungsteams. Der Methodeneinsatz wirkt sich nicht nur auf die reinen Entwicklungsphasen, sondern auch auf die Wartungsphase aus. Dabei sind die zu verwendenden Methoden generell für Projekte beliebiger Größe verwendbar. Es scheint jedoch so, dass große Projekte erst durch den Methodeneinsatz beherrschbar werden. Durch den Methodeneinsatz sind Produktivitätssteigerungen von bis zu 50% möglich.52'' Die Frage nach dem Nutzen einer Methode lässt sich nicht generell beantworten, da jeder Anwender ein individuelles Zielsystem hat. Zur Beurteilung der Vorteilhaftigkeit einzelner Methoden schlagen S. DWORATSCHEK 822

823

824

Vgl. WIRTZ, K.W.: Methoden und Werkzeuge für den Softwareentwurf, in: KURBEL, K . ; STRUNZ, H. (Hrsg.): Handbuch Wirtschaftsinformatik, Stuttgart 1990, S. 327 (325-343). Was hier am Beispiel der Methoden erörtert wird, kann prinzipiell auch auf alle anderen dargestellten gedanklichen Hilfsmittel übertragen werden. Vgl. BOEHM, B.W.: Wirtschaftliche Software-Produktion, a.a.O., S. 568.

336 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung und H.-J. HÖKER ein auf der Nutzwertanalyse basierendes Auswahlverfahren vor. 825 In vielen Tagungsbänden wird von einem erfolgreichen Methodeneinsatz berichtet. Jedoch darf dies nicht über die Dunkelziffer der missglückten Methodeneinführungen hinwegtäuschen.^ 6 Wie bei anderen organisatorischen Innovationen sind auch beim Methodeneinsatz Grenzen zu beachten. Durch eine Methode wird ein neuer Arbeitsablauf erforderlich, der eventuell auch noch neue Aufgaben beinhaltet. Dadurch werden die bestehenden organisatorischen Abläufe der Systementwicklung ersetzt oder modifiziert. Softwareentwicklungsmethoden beziehen sich nur auf einzelne Aufgaben im Softwareentwicklungsprozess. Sie haben demzufolge vorgegebene Einsatzschwerpunkte. Manche Methoden lassen sich klar einzelnen Phasen zuordnen (ζ. B. Testmethoden). Andere sind dagegen als projektbegleitend anzusehen (ζ. B. Dokumentationsmethoden). Eine Methode enthält Regeln. Je detaillierter die Regeln sind, desto aufwendiger wird tendenziell der Lernaufwand, der zum Beherrschen einer Methode erforderlich ist. Damit nimmt die gleichzeitige Einsetzbarkeit bei einer heterogenen Gruppe betroffener Anwender und Softwareentwickler ab. Eine Methode sollte immer nur bestimmte Regeln beinhalten und damit auch immer nur auf bestimmte Prinzipien und Qualitätseigenschaften einwirken. Zur Zeit gibt es keine Methode, die nur annähernd das gesamte Aufgabenspektrum der Softwareentwicklung abdecken würde. Viele der heute eingesetzten Methoden basieren nur auf teilweise theoretisch fundierten Erkenntnissen. Die anderen entstammen einer Sammlung bewährter Regeln. 527 Eine Methode muss, damit ein erfolgreicher Methodeneinsatz ermöglicht wird, von den Betroffenen akzeptiert werden. Akzeptanz fordernd wirken sich aus:

825

826

827

Vgl. DWORATSCHEK, S.; HÖCKER, H.-J.: Möglichkeiten einer Bewertung softwaretechnischer Methoden, in: AI: 5/1985, S. 183-190 (183-190). Ein Methodenvergleich wird auch von A. SCHULZ vorgenommen: Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 189 ff. Vgl. ÖSTERLE, H.: Die Auswirkungen von Methoden und Werkzeugen auf die Wirtschaftlichkeit, in: CW-CSE (Hrsg.): Effizientes Software-Management, München 1983, S. 43 ff. Vgl. ÖSTERLE, H.: Die Auswirkungen von Methoden und Werkzeugen auf die Wirtschaftlichkeit, in: CW-CSE (Hrsg.): Effizientes Software-Management, München 1983, S. 43 ff. (41-66).

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung -

-

337

Einführung einer Methode in Form eines Projektes, bei dem die einzelnen Einführungsschritte genau abgestimmt und die Verantwortlichkeiten geklärt sind.5·25 frühzeitige Information über einen geplanten Methodeneinsatz bei den Betroffenen Möglichkeit zum Mitentscheiden gemeinsame Festlegung einer Einführungs- und Nutzungsstrategie Schulungsmaßnahmen

»Der kommerzialisierte Umgang mit Methoden unterstellt, man könne Methoden festschreiben, in Dokumenten verpacken, kaufen oder verkaufen, und nach einer geeigneten Schulung ein wohldefiniertes Ergebnis bei ihrem Einsatz erreichen.«529 C. FLOYD bezeichnet dies als Illusion. Sie führt weiter aus, dass jede Methode Interpretationsspielräume lässt und es »prinzipielle Grenzen (bei) der formalen Festschreibbarkeit sinnvollen menschlichen Handelns« 530 gebe. »Letztlich gibt es keine Methoden, sondern Menschen als Träger von Methoden. Jeder von uns entwickelt laufend seine eigene Methode weiter...«831 Damit können Methoden (mehr oder weniger leicht) entsprechend den eigenen Ideen und Zielen abgewandelt werden. Schwieriger wird die individuelle Anpassung bei den mehr formalisierten Techniken und Verfahren. Trotz der bisher geringen Resonanz in der Praxis auf den Methodeneinsatz und die großen Probleme bei der Methodenbeurteilung sollte bei der kommerziellen Entwicklung von ganzheitlichen Informationssystemen nicht auf den Methodeneinsatz verzichtet werden. Es gilt: »Eine Methode ist besser als keine Methode.«53·2 Doch sollte zunächst geprüft werden, welche Anforderungen diese Methoden erfüllen sollen.

" « V g l . GOMOLZIG, H.: Auswahl und Einfuhrung von Methoden und Tools für den Softwareentwurf; in: HMD: 110/1983, S. 19 (17-22). 829 Vgl. FLOYD, C.: Eine Untersuchung von Software-Entwicklungsmethoden, in: MORGENBROD, H.; SAMMER, W. (Hrsg.): Programmierumgebungen und Compiler. Berichte des German Chapter of the ACM 18, Stuttgart 1984, S. 271 (248-274). 830 Vgl. FLOYD, C.: Eine Untersuchung von Software-Entwicklungsmethoden, a.a.O., S. 271. 831 vgl. FLOYD, C.: Eine Untersuchung von Software-Entwicklungsmethoden, a.a.O., S. 272. 832 SCHULZ, Α.: Software-Entwurf, a.a.O., S. 192.

338 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 4.2.2 Anforderungen an Methoden der Softwareentwicklung Auch die an die Methoden der Softwareentwicklung zu stellenden Anforderungen sind so umfangreich, dass es sinnvoll ist, sie in phasenunabhängige und phasenabhängige Anforderungen zu unterteilen. 4.2.2.1 Allgemeine phasenunabhängige Anforderungen Durch den Methodeneinsatz soll den Softwareentwicklern eine weitere Hilfestellung gegeben werden, wie die allgemein formulierten Prinzipien bei einer konkreten Aufgabenstellung berücksichtigt werden können. Die Methodenanforderungen lassen sich aus den generellen Entwicklungszielen Qualität, Kosten, Termin und Anwendbarkeit durch die Nutzer ableiten. Nachfolgend werden die phasenunabhängigen Methodenanforderungen aufgeteilt in: a) allgemeine Anforderungen b) Anforderungen bezüglich der Vorgehensweise a) Zu den allgemeinen Anforderungen zählen:533 - Durch den Methodeneinsatz strebt man einen rationelleren Softwareentwicklungsprozess an. Der Aufwand, der durch die Anwendung einer Methode entsteht, muss an einer anderen Stelle im Entwicklungsprozess zumindest in gleicher Höhe wieder kompensiert werden. - Die Effektivität der Softwareentwicklung soll gleichzeitig positiv beeinflusst werden. - Der Methodeneinsatz muss zu einer Qualitätsverbesserung (Portabilität, Zuverlässigkeit, Wartungsfreundlichkeit usw.Ä5O führen. - Eine Methode sollte leicht erlernbar und leicht anwendbar sein. - Ideal sind Methoden, die sich in einem Methodenmix kombinieren und durch Tools unterstützen lassen. - Wünschenswert ist ein möglichst breit angelegtes Einsatzgebiet für eine Methode. Dadurch lassen sich dann Probleme einer oder mehrerer Klassen (ζ. B. Realtimesysteme, kommerzielle Dialogsysteme, verteilte Systeme) damit bearbeiten.

833

834

V g l . SCHUMANN, J.; GERISCH, M . : S o f t w a r e - E n t w u r f , a.a.O., S. 148 ff. undNIESWIODEK,

J.-A.: Die Einführung von Methoden und Werkzeugen des Software Engineerings - Probleme und Management, Dissertation, Mainz 1984, S. 19 f. Vgl. Kapitel 4.3.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

339

b) Anforderungen bezüglich der Vorgehensweise535 Allgemeine, von der jeweiligen Phase unabhängige Anforderungen an eine Methode bezüglich der Vorgehensweise sind:536 - Berücksichtigung des entwicklungsorientierten Vorgehens: Die Entwicklung eines Informationssystems erfolgt in zeitlich und logisch aufeinander folgenden Phasen. Die Realisierung des konkreten Informationssystems erfolgt über die Phasen Spezifikation - Konstruktion - Implementierung - Verifikation - Einführung und Übergabe Wartung. Die Methode muss berücksichtigen, dass die Erkenntnis über das zu entwickelnde Informationssystem allmählich zunimmt und nicht von vornherein gegeben ist. - Berücksichtigung der Reihenfolge der Entwicklungsentscheidungen. Entscheidungen des Entwicklers dürfen erst dann verlangt werden, wenn sie fundiert getroffen werden können, das heißt Entscheidungen bezüglich der Implementierung sollten erst dann gefordert werden, wenn die Phasen der Spezifikation und der Konstruktion abgeschlossen sind. Die Methode sollte dem Entwickler Hinweise geben, welche Entscheidung wann getroffen werden muss. Ein Entwurf sollte mit relativ sicheren Entscheidungen begonnen werden. - Aus den ersten beiden Anforderungen ergibt sich die Anforderung, dass Methoden Programmiersprachen- und betriebssystemunabhängig sein sollten. Eine Ausrichtung einer Methode an einem dieser Aspekte führt dazu, dass die Methode nicht allgemein einsetzbar ist und die Auswahl der Methode die konstruktive Freiheit der Entwickler stark einengt, indem ihre Auswahl schon Aspekte der Implementierung vorwegnimmt. - Sicherstellung der Vollständigkeit, Eindeutigkeit und Konsistenz der Entwurfsentscheidungen durch Anleitungen zum Vorgehen und zur Überprüfung der getroffenen Entscheidungen. - Möglichst vollständige Dokumentation der getroffenen Entscheidungen zusammen mit den Gründen, die zu ihnen geführt haben. Die Systementwicklung ist ein zyklischer Prozess. Sollten sich ζ. B. während der Entwicklung Anforderungen ändern oder sollte sich herausstellen, dass eine Anforderung nicht realisierbar ist, müssen Entscheidungen revidiert werden. Die gemeinsame Dokumentation von Entscheidungen und Gründen ermöglicht es, Entscheidungen nachvollziehbar zu 835

V g l . GEWALD, K.; HAAKE, G.; PFADLER, W . : Software Engineering, a.a.O., S. 5 9 f.

836

V g l . BALZERT, H.: D i e E n t w i c k l u n g v o n S o f t w a r e - S y s t e m e n , a.a.O., S. 6 8 f.; WLRTZ, K.W.:

Methoden und Werkzeuge, a.a.O., S. 327 f. und SCHULZ, Α.: Software-Entwurf, a.a.O., S. 15.

340 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung machen und zu untersuchen, ob eine Entscheidung trotz der Änderungen aufrechterhalten werden kann. - Darstellung der Ergebnisse in einer möglichst verständlichen und kommunikationsfördernden Form. Die Ergebnisse einer Phase bilden die Basis für die folgende Phase. Die Ergebnisse müssen so dargestellt werden, dass sie auch von Personen, die während dieser Phase nicht beteiligt waren, verstanden werden können. Darüber hinaus ermöglicht eine verständliche Darstellungsform, die späteren Systembenutzer und Systemanwender in den Entwicklungsprozess einzubeziehen. 4.2.2.2 Phasenspezifische Anforderungen Phasenspezifische Anforderungen sind zu beachten - bezüglich der Spezifikation - bezüglich der Systemkonstruktion und - bezüglich der Implementierung. Diese Anforderungen sollen in den folgenden Abschnitten näher erläutert werden. 4.2.2.2.1 Anforderungen bezüglich der Spezifikation Das Ziel der Problemspezifikation ist die Ermittlung und Darstellung der gegenwärtigen Probleme des bestehenden Systems. Das bestehende System wird dazu analysiert (Ist-Analyse), Problembereiche werden aufgedeckt und Lösungsvorschläge zu deren Behebung erarbeitet. Es wird untersucht, welche Anforderungen an ein zu entwickelndes System zu stellen sind. Diese werden als Grob-Sollkonzept ζ. B. in Form eines gegebenenfalls noch zu ergänzenden Pflichtenheftes dokumentiert. Im Rahmen der Systemspezifikation wird ein logisches Modell des zu entwickelnden Systems entworfen. Das Modell soll eine grobe Beschreibung des Systems sein. Schwerpunkt dieser Spezifikation ist die Bestimmung der Schnittstellen des Systems zur Umwelt, das heißt die Definition der erforderlichen Eingabe- und der benötigten Ausgabedaten. Die Modellbildung erfolgt auf der Grundlage der Ergebnisse der Problemspezifikation. Aspekte der inter-

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

341

nen Realisierung (Modulbildung u.ä.) sowie der physischen Realisierung spielen keine Rolle. 557 Diese Aufgaben verlangen: -

-

Es muss möglich sein, komplexe Aufgaben zu beschreiben und zu dokumentieren. Hierzu müssen Aussagen über Funktionsstrukturen (Abläufe) und Datenstrukturen gemacht werden, wobei ein möglichst hoher sprachlicher Freiheitsgrad anzustreben ist. Die Methode muss eine klare Trennung zwischen den Phasen der Spezifikation und der Konstruktion erlauben. Wichtig ist auch, dass Beschreibungsmittel verwendet werden, die sowohl für die Anwender als auch für die DV-Spezialisten leicht verständlich sind. Der Grad der Formalisierung sollte möglichst klein sein. Eine hierarchische und modulare Systemdarstellung sollte unterstützt werden.

Einige der in der Spezifikation anwendbaren Methoden wurden bereits in Band I dargestellt. Hierzu zählen Brainstorming, Funktionsanalyse, Delphi-Methode, das Interview, Fragebogen, Formulare usw. 535 4.2.2.2.2 Anforderungen bezüglich der Systemkonstruktion Im Rahmen der Systemkonstruktion soll ein detailliertes Lösungsmodell entwickelt werden. 559 Schwerpunkt dieser Phase ist die innere Ausgestaltung des in der vorangegangenen Phase entworfenen logischen Modells, mit anderen Worten, die Entwicklung einer Systemarchitektur. 540 Zu der Ausgestaltung gehören insbesondere die Zerlegung des Systems in Teilsysteme, Umsetzung der Teilsysteme in Module und die Festlegung der internen Schnittstellen. 547 Die Konstruktionsphase kann in zwei Phasen unterteilt werden: -

logisches Design und physisches Design. 542

557

Vgl. BIETHAHN, J.; a.a.O., S. 257 ff.

MUCKSCH, H . ; RUF, W . :

Ganzheitliches Informationsmanagement, Band

I,

838 YGI BIETHAHN, J.; MUCKSCH, H . ; RUF, W . : Ganzheitliches Informationsmanagement, Band I,

a.a.O., S. 274 ff. Vgl. PETERS, L . : Advanced Structured Analysis and Design, Englewood Cliffs 1 9 8 8 , S. 11. 840 Vgl. BALZERT, H. (Hrsg.): CASE: Systeme und Werkzeuge, a.a.O., S. 25. 841 Vgl. BIETHAHN, J.; MUCKSCH, H.; RUF, W.: Ganzheitliches Informationsmanagement, Band I, a.a.O., S. 265 f. 842 Ygj p ETER g ; L : Advanced Structured Analysis and Design, a.a.O., S. 12. 839

342 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Als Methodenanforderungen sind zu nennen: - Die »richtige« Modularisierung muss gefordert werden. - Die Komplexität der Aufgabenstellung (aus der Spezifikation) und die Komplexität der Lösungen müssen beherrschbar sein. - Die Ergebnisse müssen auch in den Folgephasen nutzbar sein. - Die Dekomposition von Funktionen und Datenstrukturen muss möglich sein. 4.2.2.2.3 Anforderungen bezüglich der Implementierung In der Phase der Implementierung wird das Modell realisiert. Dazu muss das angestrebte Datenmodell mit den konkret vorhandenen Möglichkeiten DVtechnisch abgebildet, und die Funktionen müssen in einer bestimmten Programmiersprache realisiert werden. Die Anforderungen der Implementierung beziehen sich auf: - den Programmierstil - die Nutzung der Programmierumgebung - die Einhaltung von Softwarequalitätsanforderungen (wie ζ. B. Portabilität, Effizienz, Wartbarkeit) 4.2.3 Allgemeine Vorgehensweisen Die Top-Down-Methode, die Bottom-Up-Methode und die kombinierte TopDown/Bottom-Up-Methode nehmen als gedankliche Hilfsmittel eine Sonderstellung ein. Sie geben die Richtung der Entwicklung an: vom Abstrakten zum Konkreten oder umgekehrt. In der Literatur werden sie auch unter dem Begriff »Strategie« diskutiert. Sie stehen in einem engen Zusammenhang mit dem Prinzip der Abstraktion und dem daraus ableitbaren Begriff der Abstraktionsebenen und dem Begriff einer abstrakten oder virtuellen Maschine. »Eine abstrakte Maschine ist eine Menge von grundlegenden Operationen, in denen man die Gesamtoperation eines Systems oder eines Teilsystems auf irgendeiner Abstraktionsebene ausdrücken kann. Man geht dabei von der Vorstellung aus, eine Hardware zu besitzen, die diese Grundoperationen direkt ausführen kann.«54·5 Bereits im Band I, Kapitel 6.4 wurden Erhebungsmethoden und Darstellungstechniken erläutert. Diese haben zwar - wie in vielen Lehrbüchern ausgeführt wird - den Schwerpunkt ihres Einsatzes in den ersten Phasen der 8 4 3

GEWALD, K . ; HAAKE, G . ; PFADLER, W . :

Software Engineering,

a.a.O.,

S.

64

f.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

343

Softwareentwicklung, jedoch müssen sie auch bei den Folgephasen immer wieder zur Anwendung kommen.544 4.2.3.1 Die Top-Down-Methode Dieser Methode (oder Strategie) liegt das Dekompositions- und das Geheimnisprinzip zugrunde. (Man verwendet hierfür auch die Begriffe »Methode der schrittweisen Verfeinerung«, »stepwise refinement« oder »successive refinement«.) Bei der Top-Down-Methode wird versucht, ein Ziel in mehreren Schritten zu erreichen. Dabei erfolgen die einzelnen Lösungsschritte von »oben nach unten«, das heißt, dass ausgehend von einem Globalziel (Ausgangsproblem) Subziele (Teilprobleme) gebildet werden. Diese hierarchische Aufteilung erfolgt solange, bis konkrete Lösungen möglich sind.

Die Top-Down-Methode lässt sich auch innerhalb einzelner Phasen anwenden.

844

Zur Anwendung dieser Methoden auch außerhalb der Wirtschaftsinformatik vgl. F+E-Controllerdienst, Stuttgart 1 9 9 4 , S . 2 7 f.

LIESSMANN, K . :

MAYER,

E.;

344 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung In der Phase Systemkonstruktion beginnt der Softwareentwurf auf der höchsten Abstraktionsebene (und wird auf der jeweils niedrigeren Abstraktionsebene fortgesetzt). Prinzipiell eignet sich die Top-Down-Methode also zur schrittweisen Verfeinerung. Anstehende Entwurfsentscheidungen sollen möglichst früh getroffen werden, damit sie jeweils den größtmöglichen Teil des zu entwickelnden Systems betreffen/''· 5 Durch diese schrittweise Verfeinerung wird versucht, den Entwurf in Richtung auf die Basismaschine zu konkretisieren. Dabei werden abstrakte Funktionen konkretisiert, das heißt durch einfachere, weniger komplexe Funktionen der Basismaschine ersetzt. Aus der Summe der gebildeten einfachen Funktionen müssen sich wieder die komplexen Funktionen realisieren lassen. 540 Die Top-Down-Methode bezieht sich auf das Vorgehen beim Softwareentwurf. Sie macht jedoch keine Aussagen über die nachher zu realisierende Systemstruktur. Sie eignet sich lediglich als Hilfsmittel zur Festlegung einer Modulstruktur. Verwendet man die Top-Down-Methode, so erhält man bei der Systemimplementierung eine hierarchisch gegliederte Modulstruktur bei den einzelnen Programmen. Dabei befindet sich auf höchster Hierarchieebene ein Hauptmodul, das die Verarbeitung beginnt, bzw. die Verarbeitung durch einen entsprechenden Modulaufruf ausführen lässt. Vom Hauptmodul werden die zur Ausführung bestimmten Funktionen ebenfalls in einem Untermodul aufgerufen. Letzteres kann wiederum durch weitere Modulaufrufe hierarchisch gegliedert sein, sofern der Funktionsaufruf hinreichend komplex ist. 547 Die Top-Down-Methode ist in der Praxis weit verbreitet und weitgehend akzeptiert. Die Vorteile der Top-Down-Methode sind: - Die Top-Down-Methode entspricht weitgehend dem natürlichen Problemlösungsverhalten des Menschen. - Die Erfolgsaussichten, das angestrebte System zu erhalten, sind relativ hoch. - Gravierende und weitreichende Entscheidungen werden bereits auf hoher Abstraktionsebene getroffen.

« « V g l . HANSEN, H . R . : Arbeitsbuch: Aufbau betrieblicher Informationssysteme, 4 . , neubearbeitete und erweiterte Auflage, Wien 1981, S. 39 f. wö V g l . ÖSTERLE,H.: Entwurf betrieblicher Informationssysteme, a.a.O., S. 88 ff. 847 Vgl. LABUDDE, K . : Strukturiert programmieren - mit Anwendungen für die Wirtschaft, Hamburg 1987, S. 40 ff.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

345

-

Die stufenweise strukturierte Vorgehensweise ermöglicht es dem Entwickler, Gesamtzusammenhänge im Auge zu behalten. - Die Top-Down-Methode setzt die Prinzipien der Abstraktion, der Strukturierung und der Hierarchisierung um. Der Entwicklungsprozess wird übersichtlich.«^ - Es ist möglich, dass die Top-Down-Methode in mehreren Phasen angewandt wird. Dadurch lässt sich eine einheitliche Vorgehensweise realisieren. Als Nachteile sind zu nennen:549 - Es ist nicht möglich, wiederverwendbare Komponenten zu erkennen und abzugrenzen. - Es wird ein hohes Maß an Abstraktionsvermögen vorausgesetzt. - Es besteht die Gefahr, dass der Entwerfer schwierige und unbequeme Entscheidungen auf niedrigere Stufen verlagert. - Sofern auf bereits vorhandene Teillösungen Rücksicht genommen werden muss, kann nicht mehr streng nach der Top-Down-Strategie vorgegangen werden. - Da Entscheidungen vom Top her getroffen werden, besteht die Gefahr von Fehlentscheidungen aufgrund nicht vorhandener Detailkenntnisse. - Es können unbeabsichtigt Kenntnisse über die Basismaschine mit in den Entwicklungsprozess einfließen und die Lösungsmöglichkeiten frühzeitig einengen. - Es fehlen Regeln für die Dokumentation und Darstellung. - Es wird bezweifelt, dass es überhaupt möglich ist, nur nach der Top-DownMethode Software zu entwerfen. Zwänge der Praxis und die Berücksichtigung vorhandener Hard- und Software machen dies unmöglich.550 4.2.3.2 Die Bottom-Up-Methode

Die Bottom-Up-Methode (oder Strategie) geht genau umgekehrt wie die TopDown-Methode, also »von unten nach oben«, vor. Durch Komposition von Teillösungen soll eine neue Gesamtlösung gebildet werden. Auch die Bottom-Up-Methode lässt sich in mehreren Entwicklungsphasen anwenden. 848 849

850

Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 72. Vgl KIMM, R.; KOCH, W.; SIMONSMEIER, W.; TONTSCH, F.: Einführung in SoftwareEngineering, a . a . O . , S. 127 f., BALZERT, H.: Die Entwicklung von Software-Systemen, a . a . O . , S. 72 sowie SCHUMANN, J.; GERISCH, M . : Software Entwurf, a.a.O., S. 211. Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 30.

346 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Bei der Systemkonzeption werden Entwurfsentscheidungen zuerst auf niedrigster Ebene getroffen. Bezogen auf das Konzept der abstrakten Maschinen beginnt der Entwurf auf der Ebene der Basismaschine, oder man geht von bereits vorhandenen Basisfunktionen aus. Durch Komposition von Funktionen wird der Entwurf in Richtung Benutzermaschine vorangetrieben. Komplexe Funktionen werden aus elementaren Funktionen der darunter liegenden Ebenen gebildet. Die Bottom-Up-Methode ist für den Entwicklungsprozess im Ganzen weniger geeignet. Das technisch Machbare steht im Mittelpunkt der Betrachtung und nicht die Anforderungen an das zu entwickelnde System. Die Bottom-Up-Methode findet hauptsächlich bei der Prüfung von Phasenergebnissen und bei der Ermittlung von Nutzungsmöglichkeiten bestehender Lösungen ihre Anwendung. Bspw. muss in der Phase der Problemspezifikation geprüft werden, inwieweit aufbereite existierende Systeme zurückgegriffen werden kann. In den Phasen der Systemspezifikation und der Systemkonzeption muss der Systementwickler prüfen, welche Module zu einem Modul zusammengefasst werden können, um Redundanz in der Entwicklung zu vermeiden. Die Vorteile der Bottom-Up-Methode sind:Ä5i - Die Integration bereits vorhandener Problemlösungen ist möglich. - Höhere Ebenen erreicht man nur über bereits realisierte darunter liegende Ebenen. Ob etwas realisiert werden kann, wird bereits auf den realisierten und darunter liegenden Ebenen entschieden. Diese sind i.d.R. getestet und erprobt. Sie bergen somit nicht das Risiko von kompletten Neuentwicklungen. - Die entwickelten Funktionen haben generellen Charakter. Die Chancen, dass generelle Funktionen mehrfach innerhalb des Systems verwendbar sind, sind groß. Damit steigt der Anteil an wiederverwendbaren Systemteilen. - Die Funktionen der Basismaschine sind eine konkrete Ausgangsbasis für die Systementwicklung. Als Nachteile sind zu nennen: - Man hat keine Gewähr dafür, dass der Entwickler sein Entwurfsziel erreicht. Die Eignung als Entwurfsstrategie ist deshalb umstritten.052

" ' V g L KIMM, R . ; KOCH, W . ; SIMONSMEIER, W . ; TONTSCH, F.: Einführung in SoftwareEngineering, a.a.O., S. 128 sowie BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 73. 852 Vgl. SCHUMANN, J.; GERISCH, M.: Software Entwurf, a.a.O., S. 212.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

347

- Details der Implementierung werden bereits in frühen Phasen betrachtet. - Die Gefahr, dass der Gesamtzusammenhang nicht mehr erkannt wird, ist groß. - Es besteht eine große Gefahr, dass das realisierte System nicht den Anforderungen entspricht. - Die Bottom-Up-Methode setzt die Prinzipien der Abstraktion, der Strukturierung und der Hierarchisierung nicht um. Der Entwicklungsprozess wird unübersichtlich. - Man kann nicht davon ausgehen, dass die vorhandenen Basislösungen miteinander verträglich sind. 4.2.3.3 Die kombinierte Top-Down/Bottom-Up-Methode

Der kombinierten Top-Down/Bottom-Up-Methode liegt im Rahmen der Systemkonstruktion und Systemimplementierung das Konzept der strukturierten Entwicklung zugrunde. Die kombinierte Top-Down/Bottom-Up-Methode setzt sich aus einem systematischen Wechsel des Top-Down- und des Bottom-Up-Approaches zusammen.Ä53 Betrachten wir einmal den Einsatz der Methode bei der Entwicklung eines Programms: Auf der Basis der Problemstellung und der Anwenderwünsche wird ein Entwurf des Programms erstellt. Der Entwurf besteht aus einer Anzahl von Modulen. Die bisherige Entwicklung erfolgte von einer hohen Abstraktionsebene in Richtung tieferer Abstraktionsebenen (top-down). Nun wird überprüft, ob es schon Realisierungen für die entworfenen Module gibt oder ob sich mehrere Module so ähneln, dass sie vereinheitlicht werden sollen (bottom-up). Eine weitere Einsatzmöglichkeit der kombinierten Top-Down/Bottom-UpMethode wird für die Entwicklung von kritischen Systemkomponenten vorgeschlagen. Zuerst werden diese kritischen Systemkomponenten, von denen eventuell die gesamte Entwicklung abhängig ist, entworfen (top-down) und realisiert. Durch eine Vergröberung der kritischen Systemteile (bottom-up) werden die Verbindungen zu den weniger kritischen Teilen hergestellt, die dann wiederum entworfen (top-down) und realisiert werden.*5·* Die kombinierte Top-Down-/Bottom-Up-Methode besitzt die Vorteile beider Einzelmethoden. 853 vgl. BIETHAHN, J.: Einführung in die EDV für Wirtschaftswissenschaftler, 8., durchgesehene Auflage, München/Wien 1996, Kapitel 3.2.1. 854 Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 32.

348 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 4.2.4 Phasenspezifische Vorgehensweisen Zu den phasenspezifischen Hilfsmitteln gehören die Methoden der Structured Analysis, die der Systemkonstruktion und die der Implementierung. 4.2.4.1 Methoden für die Spezifikation: Structured Analysis (SA) Bei Structured Analysis handelt es sich um einen datenflussorientierten Ansatz, wobei die schrittweise Erstellung immer detaillierterer Spezifikationen unterstützt wird. Die Structured-Analysis-MethodeÄ55 eignet sich vorwiegend zur Problemspezifikation, Systemspezifikation und zur Systemkonstruktion.556 Der Entwurf eines Systems erfolgt anhand des logischen Datenflusses. Anhand des Datenflusses werden die Funktionen eines Systems und die daraus resultierenden Datentransformationen ermittelt. Unberücksichtigt bleibt jedoch der Steuerfluss. Der Vorteil dieser Vorgehensweise ist darin zu sehen, dass Anforderungen an ein System im allgemeinen durch Spezifikationen von Outputdaten dargestellt werden. So ist es anscheinend »... leichter, eine Problemlösung zunächst vom Datenfluss her gesehen zu entwickeln, als sie top-down darzustellen.«557 Structured Analysis verwendet verschiedene Darstellungstechniken. Dazu zählen: -

Datenflussdiagramme (data flow diagramms) Data Dictionary, im Sinne eines Datenlexikons Transformationsbeschreibungen (transformation description)

Bei den Datenflussdiagrammen werden vier Elemente (Bild 4-9) verwendet -

Prozesse (Funktionen) werden in Form von Kreisen dargestellt. Rechtecke dienen der Kennzeichnung von Datenquellen und -senken. Pfeile symbolisieren den Datenfluss. Datenspeicher werden durch zwei waagerechte Striche symbolisiert.

555

Zu dieser Methode vgl. WEINBERG, V . : Structured Analysis, Englewood Cliffs 1980, BALZERT, Η. (Hrsg.): CASE, a.a.O., S. 66-69 sowie DEMARCO, T.: Structured Analysis and System Specifikation, 2. print, rev., New York, 1979. Geht man von anderen Phasenkonzepten aus, so würde man die Schwerpunkte von Structured Analysis in den Phasen Anforderungsanalyse, Anforderungsdesign und Entwurf zuordnen. SCHULZ, Α . : Software-Entwurf, a.a.O., S. 8 2 .

550

8 5 7

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

349

Name >= Datenfluss Transformation

Ablage

=

Datenspeicher

Endknoten

=

Systemschnittstelle

Bild 4-9: Symbole in Datenflussdiagrammen

Arzneilager

Bild 4-10: Datenßussdiagramm Das Datenflussdiagramm stellt damit Datenquellen und -senken, den Datenfluss, die Transformationen von Eingabe- in Ausgabedaten (Prozesse) sowie Dateien und physische Lager (Materiallager) dar. In Bild 4-10 wird ein solches Datenflussdiagramm dargestellt. Es handelt sich um die Darstellung

350 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung eines Apothekenbetriebes im Istzustand.858 Zu beachten ist, dass die Darstellungen nur den Datenfluss, nicht aber den Steuerfluss enthalten. Um die Übersichtlichkeit der Darstellungen zu gewährleisten, werden die im Datenflussdiagramm dargestellten Prozesse stufenweise verfeinert. Ein Prozess innerhalb eines Datenflussdiagramms kann wiederum als Datenflussgraph mit Teilprozessen dargestellt werden. Bild 4-11 zeigt die Zerlegung des Prozesses 1 aus der vorangegangenen Abbildung. Die Menge aller Datenflussdiagramme bilden eine Hierarchie. Auch dadurch erhält man einen immer detaillierteren Überblick über das Gesamtsystem. Folgende Regeln sind bei der Aufstellung von Datenflussdiagrammen zu beachten:*59 1. Jedes Diagramm umfasst max. 1 Seite. Reicht eine Seite nicht aus, bzw. wird das Diagramm zu unübersichtlich, so wird eine hierarchische Aufteilung der Transformationen vorgenommen. 2. Es werden ausschließlich Datenflüsse dokumentiert. Zeitliche Abhängigkeiten von Funktionsfolgen werden nicht berücksichtigt. 3. Verwendung von aussagekräftigen Namen für Datenflüsse und Transformationen. 4. Damit die Transformationen Ausgaben erzeugen können, muss darauf geachtet werden, dass alle hierfür erforderlichen Eingaben zur Verfügung stehen. Für die Transformationsbeschreibungen (Mini-Spezifikationen) werden oft verbale Beschreibungen verwendet, die der Anwender verstehen kann. Als weitere Darstellungsmittel kommen bei entsprechendem Anwenderverständnis zum Einsatz: - Entscheidungstabellen, - Strukturbilder, - Entscheidungsbäume, - Pseudocode (Structured English) - und Entity-Relationship-Diagramme.s K(p) + K(q) K: Komplexität p,q: Problembereiche

Bild 4-13: Gesamtkomplexität

Kopplungsart

Eigenschaften der Verbindung

Unabhängigkeit

Data

Übergabe sämtlicher Daten in einer

hoch

Parameterliste (nur skalare Größen) Stamp

Übergabe von Datenstrukturen

mittel

Control

Übergabe von Steueranweisungen

mittel

External

keine explizite Übergabe von

mittel bis klein

Parametern, sondern Übergabe der Parameter in einen gemeinsamen Speicherbereich (nur skalare Größen) Common

keine explizite Übergabe von

klein

Parametern, sondern Übergabe von Datenstrukturen in einen gemeinsamen Speicherbereich Content

ein Modul ist in einem anderen Modul

klein

enthalten

Bild 4-14: Spektrum der Kopplungsarten Kopplungen, die sich durch ein hohes Maß an Abhängigkeit auszeichnen, sind zu vermeiden. Es sollte also möglichst auf die Kopplungsarten External, Common und Content verzichtet werden. bb) innere Komplexität Als Maß für die innere Komplexität kann die Kohäsion, also der innere Zusammenhang von Anweisungen eines Moduls durch Bindungskräfte, herangezogen werden. Innerhalb eines Moduls sollte der Zusammenhang zwischen den einzelnen Anweisungen möglichst hoch sein. Die Arten der Bindung reichen von einer sehr schwachen, zufalligen Bindung, die entsteht, wenn Programmanweisungen willkürlich zu Modulen zusammengefasst werden, bis zu einer sehr starken, funktionellen Bindung, die gegeben ist, wenn ein Modul einen Prozess beschreibt, der völlig unabhängig von anderen Modulen ausgeführt werden kann. Bild 4-15 gibt einen Überblick über das Spektrum der verschiedenen Bindungsarten.

356 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

Bindungsart

Beschreibung der Bindungsart

Bindungsstärke niedrig

Willkürliche Verteilung der Anweisungen auf Module. Logische Anweisungen einer Klasse (arithmetische Anweisungen, 10-Anweisungen usw.) werden zu einem Modul zusammengefasst. zeitlich Anweisungen, die zu einem Zeitpunkt ausgeführt werden, werden zu einem Modul zusammengefasst (ζ. B.: Initialisierungsmodule, Terminierungsmodule). Anweisungen, die an demselben Arbeitsprozess prozedural beteiligt sind, werden zu einem Modul zusammengefasst. kommunikativ Anweisungen, die dieselben Eingabedaten benutzen oder dieselben Ausgabedaten erzeugen, werden in einem Modul zusammengefasst. sequentiell Anweisungen, deren Ergebnisse die Eingabedaten des nächsten Moduls sind, werden zu einem Modul zusammengefasst. funktionell Anweisungen, die einen Prozess völlig unabhängig von anderen Modulen ausführen, werden zu einem Modul zusammengefasst (z.B.: mathematische Funktion). hoch Bild 4-15: Spektrum der Bindungsarten zufällig

Es ist in der Realität nicht möglich, den genauen Grad der Bindung eines Moduls zu bestimmen. Es sollte aber bei dem Entwurf von Programmsystemen ein hohes Maß an Kohäsion angestrebt werden.577 Als Bindungsarten sollten nach L . L . C O N S T A N T I N E nur die prozedurale, kommunikative, sequentielle und die funktionelle Bindung vorkommen. Auf die zufallige, logische und zeitliche Bindung sollte verzichtet werden/ 72 Das Ziel ist es, die Gesamtkomplexität eines Programmsystems möglichst gering zu halten. Eine alleinige Reduzierung der inneren Komplexität führt zu 871 VGL PRESSMAN, R.S.: Software Engineering. A Practioner's Approach, 3. ed., New York/ St.Louis/San Francisco 1992, S. 387 f. 872

Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 68.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

357

einfach strukturierten, wenige Anweisungen umfassenden Modulen, die stark miteinander kommunizieren müssen, also eine hohe äußere Komplexität aufweisen. Eine alleinige Reduzierung der äußeren Komplexität, also der Kommunikation zwischen den Modulen, führt zu komplexen Modulen mit einer hohen inneren Komplexität. c) Vorgehensweise zur Erreichung einer stabilen Systemstruktur Die vorangegangenen Überlegungen bilden die Grundlage für die Vorgehensweise zur Systementwicklung. Die Entwicklung wird von den Begründern des Structured Design in zwei Schritte zerlegt: Den ersten Schritt bildet der Grobentwurf, auch »General Program Design« genannt. Das Ziel dieses Schrittes ist die Untersuchung, welche Funktionen zur Aufgabenerfüllung des Systems benötigt werden (»What functions are needed for the program?«). Der Feinentwurf, auch als »Detailed Design« bezeichnet, bildet den zweiten Schritt. In ihm wird untersucht, wie die im ersten Teilschritt ermittelten Funktionen in Module timgesetzt werden (»How to implement the functions?«).573 Für die Bildung der Module gelten die Richtlinien, die im vorangegangenen Abschnitt beschrieben wurden. G.J. MYERS bettet das Structured Design ein in den so genannten External Design Process, in dem die externen Eigenschaften des Systems spezifiziert werden, und den Modul Design Process, in dem die Feindefinition der Schnittstellen und der Logik der Programmodule erfolgt.574 A. SCHULZ verweist darauf, dass im Mittelpunkt des Structured Design »... der Entwurf von Modulen und ihrer kommunikativen Beziehungen (steht), nicht aber ihre Implementierung.«575 E. YOURDON und L.L. CONSTANTINE nennen vier Design-Strategien, die im Rahmen des Structured Design Anwendung finden können: »Transformationsanalyse«, »Transaktionsanalyse« und als alternative Design-Strategien die »Data-Structure Design Method« und das »Parnas Decomposition Criteria«.576 Die Transaktionsanalyse wird zum Entwurf transaktionsorientierter Programme eingesetzt.577 Die »Data-Structure Design Method« ist identisch mit dem Jackson-Structured-Programming. PARNAS' Strategie enthält eine Regel873 874 575 570

577

Vgl. STEVENS, W . P . ; MYERS, G.J.; CONSTANTINE, L . L . : Structured Design, a.a.O., S. 1 2 7 . Vgl. MYERS, G.J.: Reliable Software through Composite Design, New York 1 9 7 5 , S. 6 9 . Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 72. Vgl. YOURDON, E.; CONSTANTINE, L.L.: Structured Design: Fundamentals of a Discipline of a Computer Program and Systems Design, Englewood Cliffs 1979, S. 187-256. Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 77 f. Zur Transaktionsanalyse vgl. YOURDON, E.; CONSTANTINE, L.L.: Structured Design, a.a.O., S. 223-244.

358 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

menge für die Dekomposition von Systemen in Subsysteme. Die Transformationsanalyse wird als die wichtigste Analyseform bezeichnet.'5'75 Aus diesem Grunde wird beispielhaft nur die Transformationsanalyse betrachtet. Dabei steht die Transformation der Daten im Vordergrund (Eingabe - Verarbeitung - Ausgabe). E. YOURDON und L.L. CONSTANTINE definieren Transformationsanalyse (transform analysis oder auch transform-centered design) als eine besondere Form der Top-Down-Methode, als eine Strategie zur Erstellung von anfänglichen Strukturentwürfen, die gewöhnlicherweise recht gut sind und an denen in den meisten Fällen nur geringe Modifikationen auf dem Weg zur endgültigen Struktur vorgenommen werden müssen. Die Bezeichnung »Transformationsanalyse« spiegelt die Vorgehensweise wieder, Funktionen und Module durch Ein- und Ausgabedaten zu bestimmen und in ihrer Verrichtung zu beschreiben. G.J. MYERS nennt folgende Schritte der Transformationsanalyse im Rahmen des Structured Designs:579 Schritt 1: Identifikation der Problemstruktur Darstellung des Problems in einer nichtprozeduralen Abfolge von Funktionen. Nach G.J. MYERS können die meisten Probleme durch eine lineare Kette von drei bis zu zehn Funktionen dargestellt werden/ 50 Die wichtigsten dieser Funktionen können ζ. B. mit Hilfe eines Datenflussdiagramms ermittelt werden. Schritt 2: Identifikation der Hauptdatenströme (Input und Output) des Problems (Externe Datenflüsse) Es werden die externen und logischen Datenströme mit Hilfe eines so genannten Datenflussgraphen ermittelt. Ein Datenstrom heißt extern, wenn er außerhalb des Systems beginnt und/oder außerhalb des Systems endet; er heißt logisch, wenn er unabhängig von einer physischen Input-/Output-Einheit ist. Schritt 3: Identifikation der Quellen und Senken der Hauptdatenströme und Ermittlung der Punkte der höchsten Abstraktion Es wird der externe und logische Hauptdatenstrom ermittelt. Die Punkte der höchsten Abstraktion sind zum einen der Punkt, an dem der Input-Strom so abstrakt ist, dass er zu verschwinden scheint, zum anderen der Punkt, an dem

878

Vgl. YOURDON, E.; CONSTANTINE, L.L.: Structured Design, a.a.O., S. 223, 246 u. 251. Zur Data Structured Design Method und PARNAS-Strategie vgl. YOURDON, E.; CONSTANTINE, L.L.: Structured Design, a.a.O., S. 223-256.

879

Vgl. MYERS, G.J.: Reliable Software, a.a.O., S. 70-78 und YOURDON, E.; CONSTANTINE, L.L.:

880

Structured Design, a.a.O., S. 187-222. Vgl. MYERS, G.J.: Reliable Software, a.a.O., S. 71.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

359

der Output-Strom in seiner abstraktesten Form zum ersten Mal erscheint. Die Funktionen, die zwischen den Punkten der höchsten Abstraktion liegen, heißen Hauptumformung des Problems (central transform of the problem). Schritt 4: Dekomposition des Problems in eine Menge von untergeordneten Modulen Die Funktionen vor der Hauptumformung (Noch-Eingabe), die Funktionen der Hauptumformung (Umformung) und die Funktionen nach der Hauptumformung (Schon-Ausgabe5*7) werden zu jeweils einer Funktion zusammengefasst und beschrieben. Daraus werden Unterfunktionen der Gesamtfunktion des Systems gebildet. Die graphische Darstellung dieses Baumes wird als Strukturgraph bezeichnet. Schritt 5: Wiederholung (Recursing) Jedes Modul wird als Unterproblem betrachtet. Für jedes Unterproblem werden die Schritte 1 bis 4 wiederholt. Schritt 6: Beendigung (Stopping) Für die Beendigung des Prozesses können folgende Faustregeln herangezogen werden. Ein Modul soll ζ. B. nicht weiter zerlegt werden, wenn die Zerlegung zu einer Menge von Modulen mit hoher Kopplung und geringer Bindung fuhrt. Die Schritte des Structured Design werden am Beispiel eines automatisierten Geldauszahlungssystems verdeutlicht.

Bild 4-16 enthält die lineare Darstellung der Problemstruktur. Der Hauptdatenstrom ist in Bild 4-17 dargestellt. Der Eingabedatenstrom »verschwindet« bei Beginn der Identifikationsüberprüfung, der Ausgabestrom »erscheint« nach 881

Zu diesen Begriffen vgl. ENDRES, Α.: Composite Design, a.a.O., S. 194.

360 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Beendigung des Update-Vorganges. Das Problem kann in die Funktionen NochEingabe (B), Umformung (C) und Schon-Ausgabe (D) aufgeteilt werden.

A I V Ε\ C 13 Bild 4-18: Dekomposition des Problems in Module (Strukturgraph) Das Structured Design enthält umfangreiche Darstellungstechniken für Systemteile und deren Verbindungen, auf die im Rahmen dieses Buches aber nicht eingegangen werden soll. Der Leser sei verwiesen auf die ausführlichen Erläuterungen bei E. YOURDON und L.L. CONSTANTINE.^ 2

882

Ygi

Y

0 U R D 0 N )

Ε · CONSTANTINE,

L.L.: Structured Design, a.a.O.,

S. 4 0 9 - 4 4 3 .

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

361

d) Vor- und Nachteile Als Vorteile des Structured Design sind zu nennen:553 -

überwiegende Unterstützung der allgemeinen und phasenspezifischen Prinzipien, besonders gute Modularisierung, - konkrete Richtlinien für die Vorgehensweise beim Programmentwurf und Ausübung eines methodischen Zwanges, - gesteigerte Produktivität. Als Nachteile des Structured Design sind aufzuführen:554 -

hoher Speziflkations-, Codierungs- und Testaufwand, keine Unterstützung durch Werkzeuge/Tools, Beschränkung auf die Datenflüsse zu Beginn des Entwurfs, erfahrene Programmierer sind erforderlich, Zunahme der Laufzeit von Programmen, keine Hilfe für Datenstrukturierung (deshalb Kombination mit datenorientierten Ansätzen), - es sind keine eindeutigen Kriterien für die Zuordnung einer bestimmten Bindungsart vorhanden. 4.2.4.2.2 Hierarchy plus Input-Process-Output (HIPO) HIPO555 wurde ursprünglich bei der IBM (1974-1975) entwickelt 550 Die Methode wird vorwiegend zur Unterstützung von Dokumentations- und Entwurfsaufgaben eingesetzt. HIPO ist eine eher informelle Methode zur Konstruktion von Softwareprodukten.557

883

VGL

SCHULZ, Α . :

S. 1 9 4

f sowie

Software-Entwurf, a.a.O., S. 8 0 , ENDRES, Α . : Composite Design, a.a.O., Eine Untersuchung von Software-Entwicklungsmethoden, a.a.O.,

FLOYD, C . :

S. 2 6 1 - 2 6 3 . 884 885

556

557

Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 80 f. Die HIPO-Methode wird von ihren Entwicklern als Beschreibungsmittel bezeichnet, »das den gesamten Entwicklungsprozeß von der Problemanalyse bis zur Wartung begleiten kann.« KIMM u.a. kommen jedoch zu dem Ergebnis, daß HIPO als Spezifikationsmittel nicht geeignet ist. Vgl. KIMM, R.; KOCH, W.; SIMONSMEIER, W.; TONTSCH, F.: Einführung in Software-Engineering, a.a.O., S. 139 und 143. Aus diesem Grund wird HIPO als Methode zur Konstruktion eingeordnet. Vgl. o.V.: HIPO - Α Design Aid and Documentation Technique, IBM-Form GC 20-1851-1, Stuttgart 1974. Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 93.

362 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Den Ausgangspunkt bei HIPO (=Hierarchy plus Input-Process-Output) bilden die zu realisierenden Funktionen eines künftigen Softwareproduktes. Aus diesem Grund wird HIPO den funktionsorientierten Entwurfsmethoden zugeordnet. Die Methode HIPO gliedert sich in folgende Schritte:555 1. Erstellung einer Strukturübersicht über das geplante System. 2. Erstellung von Überblicksdiagrammen, die eine globale Einführung in die Systemfunktionen geben. 3. Erstellung von Detaildiagrammen zur detaillierten Beschreibung der jeweiligen Funktion. Neben der Strukturübersicht, Überblicksdiagrammen und Detaildiagrammen fertigt man sog. erweiterte Beschreibungen an. Zur Unterstützung des Entwurfs werden damit vier unterschiedliche Typen von Dokumenten verwendet. Diese werden im Folgenden näher beschrieben: 1. Strukturübersicht (»Visual Table of Contents«) Die Strukturübersicht repräsentiert die Teilfunktionen eines Programms und deren hierarchische Beziehungen. Sie entspricht im Wesentlichen dem Funktionenmodell559 und gibt die fachliche Sicht auf die Informationsverarbeitungsaufgaben wieder. Die Nummern der Teilfunktionen verweisen auf die Verfeinerungen der Teilfunktionen in den Ebenendiagrammen. Bild 4-19 zeigt den schematischen Aufbau einer Strukturübersicht. 1.0

Funktion IL

2.0 Teilfunktion

3.0 Teilfunktion

j=

3.1 Teilfunktion

4.0 Teilfunktion

Τ 3.2 Teilfunktion

Bild 4-19: Strukturübersicht

Die Strukturübersicht der HIPO-Methode kann einer Einteilung der Funktionen in Datenverwaltungs-, Vorgangs- und Analysefunktionen, wie

888 889

Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 348. Vgl. dazu Kap. 3.3

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

363

sie DERIGS/GRABENBAUER vorschlagen, angepasst werden.*90 Die Gesamtfunktion wird dann entsprechend dieser Kategorien in Teilfunktionen untergliedert. Zusätzlich zur eigentlichen Strukturübersicht der HIPOMethode wird außerdem eine DV-technische Strukturübersicht angefertigt. Diese ordnet Vorgangs- und Analysefunktionen denjenigen Datenverwaltungsfunktionen zu, auf die für die Realisierung der Funktionen zurückgegriffen wird.59-' 2. Übersichtsdiagramm (Overview Design; E-V-A-Diagramm; HIPO-Diagramm) Jede Teilfunktion aus dem Übersichtsdiagramm wird mit den dazugehörigen Eingabedaten (Input), Verarbeitungsaufgaben (Process) und Ausgabedaten (Output) dargestellt. Zur Darstellung der Datenobjekte verwendet man die Notation des Datenflussplanes. Dadurch wird deutlich, in welcher Form (Dateien, Datenträger, Geräte zur Dateneingabe und -ausgabe) die beschriebenen Daten vorliegen. Jeder Teilfunktion muss mindestens ein Datenobjekt als Input und eines als Output zugeordnet sein. Die Verarbeitungsaufgaben werden verbal beschrieben. HIPO-Diagramme enthalten sowohl Daten- als auch Steuerfluss. Teilfunktion 4.0 Teilfunktion 3.0 Teilfunktion 2.0 Input

Process

Output CT

t> CT

Ο • CT

ι

[> Datenfluß SteuerfluB

Bild 4-20:

890 891

Überblicksdiagramm

Vgl. Kap. 3.3. Vgl. DERIGS, U„ GRABENBAUER, G.L.: COLOWIN, a.a.O., S. 83-85 u. S. 96 f.

364 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Der Datenfluss wird durch hohle Pfeile, der Steuerfluss (auf den aber häufig der Übersichtlichkeit wegen verzichtet wird)592 durch ausgefüllte Pfeile dargestellt. 3. Detaildiagramme Detaildiagramme sind wie die Übersichtsdiagramme aufgebaut. Der Unterschied liegt darin, dass die Elementarfunktionen mit den zugehörigen Ein- und Ausgabedaten hier in differenzierter Form beschrieben werden (=Beschreibung der »Blätter« aus der Strukturübersicht). Zum Teil werden Datenobjekte und Funktionen als eine Einheit betrachtet. Diese Einheiten werden durch sie umschließende Rechtecke gekennzeichnet/95 Ein Detaildiagramm bildet die Grundlage für die sich anschließende Erstellung des Programmcodes. 4. Erweiterte Beschreibungen Zusätzliche Beschreibungen können sowohl bei Übersichts- als auch bei Detaildiagrammen verwendet werden. Dabei werden Anmerkungen zu den Diagrammen (ζ. B. Bedingungen) in tabellarischer Form aufgezeichnet. In den Detaildiagrammen ist es nicht möglich, Iterationen darzustellen, und auch die Beschreibung von Selektionen führt zu unübersichtlichen Darstellungen. Daher werden im Rahmen der erweiterten Beschreibungen häufig Teilfunktionen mit Hilfe von Struktogrammen noch einmal spezifiziert. Bild 2-21 skizziert den Aufbau eines Detaildiagramms mit einer erweiterten Beschreibung. Charakteristisch für die Methode HIPO ist die Vorgehensweise, die zum Entwurf der Übersichts- und Detaildiagramme vorgeschlagen wird. Sie kann wie folgt beschrieben werden:594 1. Ermittlung und Auflistung der bekannten Ausgabedaten. 2. Die Ausgabedaten werden als Funktion Ρ (Process) der Eingabedaten betrachtet.595 Nun werden parallel die Eingabedaten und die Funktionen (Verarbeitungsschritte) festgelegt.

892

893 894 895

Vgl. BUDDE, R . ; SCHNUPP, P.; SCHWALD, Α . : Untersuchung über Maßnahmen zur Verbesserung der Software-Produktion. Teil 1: Theoretische Ansätze auf dem Gebiet der Software-Technologie, GMD-Bericht Nr. 130, München/Wien 1980, S. 134. Vgl. HEINRICH, L.J.: Systemplanung I, a . a . O . , S. 1 0 3 . Vgl. BALZERT, H . : Die Entwicklung von Software-Systemen, a.a.O., S. 3 4 8 . Vgl. SCHULZ, Α . : HIPO-Methode, in: SCHNEIDER, H.-J. (Hrsg.): Lexikon der Informatik und Datenverarbeitung, 3., aktualisierte und wesentlich erweiterte Auflage, München/Wien 1991, S. 269.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

365

3. Verbindung der Ein- und Ausgabedaten mit den entsprechenden Funktionen. 4. Reorganisation und Neuerstellung des Diagramms. Teilfunktion 4.0 Teiifunktion 3.0 Teilfunktion 2.0 Output

Input

• ο CT

4. Return

to t

Erweiterte Beschreibung

Bild 4-21: Detaildiagramm Die HIPO-Methode besitzt folgende Vorteile:590 896

teilweise Unterstützung der allgemeinen und phasenspezifischen Prinzipien aufgrund der Darstellungstechnik leichte Erlernbarkeit aufgrund einfacher Regeln und einfacher Darstellungstechniken Top-Down-Zerlegung des Entwurfs durch HIPO wird die Strukturierung eines Problems erzwungen die Gliederung in Eingabe - Verarbeitung - Ausgabe entspricht einer weit verbreiteten Denkweise übersichtliche Darstellung in der Dokumentation der Programmierer wird dazu gezwungen, auf jeder Hierarchiestufe die Verarbeitungsschritte zu bestimmen Minimierung der Datenbasis in dem Sinne, dass nur die für die Teilfunktionen wirklich benötigten Daten erzeugt werden der Zusammenhang zwischen Daten und Funktionen wird deutlich. Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 351 und BUDDE, R.; SCHNUPP, P.; SCHWALD, Α.: Untersuchung, Teil 1, a.a.O., S. 134 f.

366 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Folgende Aspekte fuhren zu Kritik an der HIPO-Methode:597 - teilweiser Verstoß gegen die Prinzipien: - Datenunabhängigkeit - Modularisierung im engeren Sinne - Information Hiding - keine Regeln zur Bestimmung von Teilfunktionen oder Modulen, allgemein zu starke Informalität - Verstoß gegen das Geheimnisprinzip in dem Sinne, dass der Konstrukteur die Verarbeitungsschritte eines Moduls zeitlich nahezu parallel zu den Schnittstellen des Moduls (Ein- und Ausgabedaten) festlegen muss - keine Berücksichtigung abstrakter Datentypen insoweit, dass bei der Modularisierung eine Teilfunktion entworfen wird, auf der zahlreiche Ein- und Ausgabedaten arbeiten - kein Verfeinerungsmechanismus von Daten, nur von Teilfunktionen; daraus resultiert die Gefahr einer beliebigen Über- oder Unterspezifikation von Daten - die schwerpunktmäßige Betrachtung von Teilfunktionen erlaubt keine strukturierte Erstellung eines Datenmodells; es besteht die Gefahr einer Daten-Programm-Abhängigkeit; diesen Mangel versucht man zu beheben, indem die E-V-A-Diagramme um ein viertes Feld erweitert werden, in dem die Daten dargestellt sind, die programmunabhängig in einer Datenbank gespeichert werden können - Gefahr der Vermischung physischer und logischer Datenstrukturen; die Methode hält den Entwickler nicht davon ab, in einem zu frühen Stadium der Systementwicklung Implementierungsdetails festzulegen - keine geeignete Darstellung von Daten, die sowohl Eingabe- als auch Ausgabedaten sind (Zwischendaten) - die Darstellungen können verbal ergänzt werden; für die Ergänzung bestehen keine Regeln - Schwierigkeiten bei der Entwicklung mehrfach verwendbarer Module; Gefahr eines beträchtlichen Anwachsens des Programmcodes - keine ausreichende Unterstützung der Idee der strukturierten Programmierung im engeren Sinne

897

V g l . BALZERT, H.: D i e E n t w i c k l u n g v o n S o f t w a r e - S y s t e m e n , a.a.O., S. 3 5 1 ; BUDDE, R.; SCHNUPP, P.; SCHWALD, Α.: Untersuchung, Teil 1, a.a.O., S. 134 f. u n d SCHULZ, Α.: Software-

Entwurf, a.a.O., S. 92 ff.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

367

-

Selektionen sind nur schwer zu erkennen und Iterationen graphisch nicht darstellbar; diesen Mangel versucht man zu beheben, indem das Verarbeitungsfeld des HIPO-Diagramms als Struktogramm dargestellt wird - die Anwendung setzt eine strenge Baumstruktur des zu entwickelnden Systems voraus - aufwendige Erstellung und Modifikation. Zusammenfassend kann gesagt werden, dass sich die HIPO-Dokumente »...meist recht gut zum Entwurf der oberen Applikations- und Funktionsebenen einer Modularisierung (eignen), während sie auf der unteren Repräsentationsebene oft versagen... Eine erprobte Kompromisslösung bildet die HIPOModularisierung der oberen Programmebenen, wobei die Input- und OutputDaten nicht mehr die konkrete (Speicher-)Repräsentation, sondern abstrakte Daten sind.«S9S 4.2.4.3 Verfahren der Implementierung: Jackson-StructuredProgramming Die Jackson-Structured-Programming-Methode (auch JSP-Methode oder JSPVerfahren genannt) wurde 1975 erstmals in dem Buch »Principles of Program Design« beschrieben. Sie basiert auf Erfahrungen von M.A. JACKSON, die er während seiner Beratertätigkeit in den 60er Jahren sammeln konnte.'599 Aufgrund des detaillierten Regelwerks lässt sich JSP durchaus auch als ein Verfahren betrachten. Das Jackson-Structured-Programming ist eine Methode, die das Prinzip der strukturierten Programmierung zu verwirklichen versucht. JSP hat seinen eindeutigen Schwerpunkt im Bereich des Programm- und Modulentwurfs. C.H. CORRELL und X. DEBEST schildern den Einsatz der HIPO-Methode in den Phasen Spezifikation und Konstruktion der Entwicklung eines Gehaltsabrechnungssystems für eine amerikanische Versicherungsgesellschaft. HIPO wurde zusammen mit der strukturierten Programmierung, der Top-Down-Entwicklung, strukturierten Walkthroughs, dem ChiefProgrammer-Team und einer Entwicklungsbibliothek eingesetzt. Die Verfasser berichten von einem erfolgreichen Entwurf: Zeit- und Kostenvorgaben konnten eingehalten werden. Der erhöhte Aufwand (die Spezifikations- und Konstruktionsdauer betrugen 2/3 der gesamten Entwicklungsdauer des Systems) zahlte sich aus, als die Programme aufgrund veränderter Anforderungen häufig geändert werden mußten. Im Gegensatz zu den Programmen, die sich mühelos ändern ließen, war die Modifikation der HIPO-Diagramme sehr zeitintnsiv. CORRELL, C.H.; DEBEST, X.: Untersuchung über Maßnahmen zur Verbesserung der SoftwareProduktion, Teil 3: Einsatz von Methoden der Software-Produktion, GMD-Bericht Nr. 132, München/Wien 1980, S. 116-118. 899

JACKSON, M.A.: Principles of Program Design, London/New York/San Francisco 1975.

368 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

M.A. JACKSON überträgt die Idee der strukturierten Programmierung zusätzlich auf die Daten. Die Datenstrukturen sollten ebenfalls nach den Richtlinien der strukturierten Programmierung entworfen werden. Die JSPMethode wird allgemein den datenorientierten Entwurfsmethoden zugeordnet. Die zentrale Idee der JSP ist folgende: Programme verarbeiten und erzeugen Daten. Da viele Anweisungen von Programmiersprachen der dritten Generation und darunter das »... Auffinden des Weges durch die Datenstrukturen« betreffen, sollten die Programme die gleichen Strukturen aufweisen wie die Daten.«900 Die Programmstrukturen werden direkt aus den Datenstrukturen abgeleitet.po; Die JSP-Methode kann in fünf Schritte untergliedert werden:902 1. Gleichzeitiger Entwurf aller Datenstrukturen (Ein- und Ausgabedaten), die für ein Programm benötigt oder von diesem erzeugt werden. 2. Paarweiser Vergleich der Eingabe- und der Ausgabedatenstruktur auf Strukturgleichheit und Beseitigung von Strukturkonflikten. 3. Ableitung der Programmstruktur aus den Datenstrukturen (1:1-Abbildung). 4. Zuordnung von Elementaranweisungen (Operationen) zur Programmstruktur 5. Überführung der Programmstruktur einschließlich Elementaranweisungen in einen Pseudocode oder in die verwendete Programmiersprache. Als Darstellungstechniken werden sowohl für die Daten- als auch für die Programmstrukturen Baumdiagramme verwandt. Die Grundstrukturen der Baumdiagramme entsprechen den Strukturelementen der strukturierten Programmierung. Das Strukturelement Sequenz bedeutet, dass eine Folge von gleichrangigen, nacheinander angeordneten Teilen vorliegt: Eine Adresse besteht aus Name, Straße, Wohnort. Durch das Strukturelement Wiederholung (Iteration) wird gekennzeichnet, dass ein Teil mehrfach vorliegt.

900

JACKSON, M.A.: Grundsätze des Programmentwurfs, 7., unveränderte Auflage, Darmstadt 1986, S. 23. 901 Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 99, WIRTZ, K.W.: Methoden und Werkzeuge, a.a.O., S. 337 f. sowie BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 400. 902 VGL SCHULZ, Α.: Software-Entwurf, a.a.O., S. 99 sowie BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 400.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung Baumdiagramm

Datenstruktur

Kontrollstruktur

A: RECORD B:... C:... D:... END;

BEGIN Β:... C:... D:... END;

Auswahl

A: RECORD CASE ... OF Β:... C:... D:... END;

CASE ... OF Β:... C:... D:... END;

Wiederholung

A: ARRAY (x,y) OF Β;

WHILE ... DO BEGIN Β; END;

Reihung

369

Zeit

B°

Bild 4-22: Strukturelement Reihung (Sequenz), Auswahl (Selektion), Wiederholung (Iteration) als Jackson-Baumdiagramm, als Datenstruktur und als Kontrollstruktur903 Das JSP wird im Folgenden anhand der Entwicklung eines Programms zur Bestandsführung beschrieben. Bild 4-23 zeigt die Strukturen der Ein- und Ausgabedaten.

903

Vgl. JACKSON, M.A.: Grundsätze des Programmentwurfs, a.a.O., S. 29 sowie BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 400 f.

370 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

Bild 4-23: Ein- und Ausgabedatenstruktur Zwei Datenstrukturen (Ein- und Ausgabestruktur) weisen keine Strukturkonflikte auf, wenn Anzahl und Reihenfolge der Iterationen für beide Datenstrukturen gleich sind und das zu entwerfende Programmsystem beide Datenstrukturen gleichzeitig bearbeiten kann.904 In diesem Fall lassen sich den

904 VGL. TRUÖL, K.; VFFIBEG, U.: Strukturierter Programmentwurf, a.a.O., S. 56. Strukturkonflikte können u.a. durch die sogenannte Programminversion beseitigt werden. Zur Programminversion vgl. JACKSON, M.A.: Grundsätze des Programmentwurfs, a.a.O., S. 172-186.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

371

korrespondierenden Datenstrukturen die entsprechenden Programmfunktionen zuordnen. Die Programmstruktur muss die Strukturen der Daten widerspiegeln. Jedes Element einer Datenstruktur ist in ein Element der Programmstruktur zu überführen.905 Bild 4-24 enthält die Ausgabedatenstruktur und die daraus abgeleitete Programmstruktur.

Bild 4-24: Daten- und

Programmstruktur

1) öffne Bestandsdatei 2) Lese Eintrag Artikeldatei 3) Schließe Bestandsdatei 4) Eingabe Lieferschein 5) Suche Satz in Artikeldatei mit Schlüssel Artikel# 6) Lagerbestand_neu:=Lagerbestand_alt+Zulieferung 7) Zugänge_neu:=Zugänge_alt - Zulieferung 8) Speichere neuen Datensatz Bild 4-25:

905

Elementaranweisungen

Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 105.

372 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Die Programmstruktur wird nun um die Elementaranweisungen ergänzt. Bild 4-25 enthält die für das Programm benötigten Anweisungen. Die Elementaranweisungen werden der Programmstruktur hinzugefügt (Bild 4-26).

Die um die Elementaranweisungen erweiterten Programmstrukturen können nun ζ. B. direkt in Pseudocode oder in ein Struktogramm (Bild 4-27) überführt und mit Hilfe von Programmgeneratoren in einer Programmiersprache codiert werden. Das Jackson-Structured-Programming weist folgende Vorteile auf: - Standardisierung in der Vorgehensweise und in der Darstellungstechnik - verschiedene Personen können bei der gleichen Problemstellung zu vergleichbaren Ergebnissen kommen906 - die Strukturierung von Daten und Programmen erfolgt mit gleichen Strukturelementen

906 YGJ BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 411.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung -

-

-

-

eine Überprüfung des Programmentwurfs kann automatisch mit Hilfe von Tools erfolgen. Tools lassen sich auch für die Generierung von Quellcode einsetzen. integrierte Dokumentation; die ganze Phase der Implementierung wird dokumentiert. Schwerpunkt der Dokumentation sind die Jackson-Baumdiagramme, die auch als reines Dokumentationsmittel geeignet sind. Erzielung linearer Kontrollstrukturen durch Beschränkung auf die Strukturelemente der Strukturierten Programmierung schrittweise Verfeinerung der Strukturen durch Baumdiagramme eine gewisse Art der Hierarchisierung wird erreicht, indem zuerst die Kontrollstrukturen und erst im Anschluss daran die Elementaranweisungen bestimmt werden. gute Eignung für die Modulimplementierung bei vorgegebenen Datenstrukturen und serieller Datenverarbeitung. 907 Stabilität des Entwurfs aufgrund der Ausrichtung der Programme an den Datenstrukturen, die i.a. im Zeitverlauf stabil sind.PÖS

1) öffne Bestandsdatei Solange Lieferschein vorhanden tue 4) Eingabe Lieferschein 5) Lese Datensatz bis Art#(Lieferschein)=Art#(Datensatz) 2) Lese Eintrag Artikeldatei 6) Lagerbestand_neu:=Lagerbestand_alt+Zulieferung 7) Zugänge_neu:=Zugänge_alt-Zulieferung 8) Speichere neuen Datensatz 3) Schließe Bestandsdatei

Bild 4-27: Struktogramm des entwickelten Programms

907 908

373

Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 411. Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 124.

374 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Das Jackson-Structured-Programming weist folgende Nachteile auf: -

-

-

Verstoß gegen Prinzipien, insbesondere gegen die Prinzipien der Datenunabhängigkeit (die entwickelten Programme sind in starkem Maße datenabhängig; Änderungen der Datenstrukturen fuhren zu Änderungen an den Programmen), der Abstraktion, der Modularisierung909, des Information Hiding (die gleichzeitige Strukturierung aller Daten im Entwurfsprozess) und der Strukturierung die Anwendung des Jackson-Structured-Programming ist auf den Entwurf kleiner Systeme und den Detailentwurf von Programmmodulen begrenzt.970 die erforderliche Strukturgleichheit von Ein- und Ausgabedatenstrukturen ist i.d.R. nicht gegeben, so dass häufig Strukturkonflikte auftreten, die beseitigt werden müssen. JSP widerspricht dem Konzept der Datenabstraktion. der Datenfluss zwischen den Modulen (die Modulkommunikation) wird nicht betrachtet.

Nach den allgemeinen und den phasenspezifischen gedanklichen Hilfsmitteln sollen nun die phasenübergreifenden behandelt werden. 4.2.5 Phasenübergreifende Vorgehensweisen

Zu den im folgenden beschriebenen phasenübergreifenden Vorgehensweisen zählen die Structured Analysis and Design Technique (SADT) und das JacksonSystem-Development (JSD). 4.2.5.1 Methoden für die Spezifikation und Konstruktion: Structured Analysis and Design Technique (SADT)

Die Structured Analysis and Design Technique (SADT) 9// wurde von D.T. ROSS, dem Gründer der Firma SofTech, in den Jahren 1 9 6 9 - 7 3 entwickelt und

909

9 1 0

Eine Mehrfachverwendung von Modulen ist nicht zulässig. Vgl. SCHULZ, Α.: SoftwareEntwurf, a.a.O., S. 125. C . H . CORRELL und X. DEBEST berichten von der Anwendung der JSP (im Zusammenhang mit weiteren Methoden) durch die Mathematics, Computers and Systems-Abteilung des amerikanischen Erdölkonzerns EXXON. Das Ergebnis war eine verringerte Komplexität der Programme, effektive Programmdokumentation als Nebenprodukt des Entwurfs sowie die Möglichkeit einer effektiven Software-Unterstützung des Entwicklungsprozesses aufgrund der Schritt-für-Schritt-Methodologie. Vgl. CORRELL, C . H . ; DEBEST, X.: Untersuchung, Teil 3 , a.a.O., S. 145 f.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

375

danach weiter verfeinert. Es handelt sich um eine allgemeine Systementwicklungsmethode, die es ermöglicht, Systeme jeder Art zu analysieren und zu entwerfen. SADT hat seinen Schwerpunkt in den Phasen der Problem- und Systemspezifikation und in der Systemkonstruktion. SADT bedient sich graphisch-verbaler Beschreibungs- und Entwurfsmitte\?12 Diese basieren auf der Top-Down-Strukturierung. SADT erlaubt eine duale Abbildung des Systems: Eine funktionsorientierte Darstellung (Aktivitätenmodell) beschreibt die betrieblichen Aktivitäten und die Daten als funktionsverbindende Schnittstellen. Das Datenmodell beschreibt die Daten des Systems und stellt die Aktivitäten als Verbindungen zwischen den Daten dar.975 Aktivitätenmodell: Die SADT-Graphik besteht aus Kästen und Pfeilen. Ein Kasten konkretisiert eine Aktivität, ein Pfeil die informative Verbindung (Schnittstelle) der Aktivität zur Umwelt. Die Schnittstellen stellen dabei Daten dar. Es werden vier Pfeiltypen unterschieden (Bild 4-28): -

Eingabedaten durch die Aktivität erzeugte Ausgabedaten die Aktivität steuernde Daten der die Aktivität ausführende oder mus (Prozessor).

unterstützende

Mechanis-

Datenmodell: Beim Datenmodell stehen die Daten im Mittelpunkt. Sie werden in Kästen und die Aktivitäten durch Pfeile dargestellt. Die Symbole entsprechen dem 911

Zu SADT vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 111-133, WILLMER, H.; BALZERT, H.: Fallstudie einer industriellen Software-Entwicklung. Definition, Entwurf, Implementierung, Abnahme, Qualitätssicherung, Mannheim/Wien/Zürich 1984, Fallstudie

SADT,

S. 1 6 9 - 1 9 0 ,

KIMM, R . ; KOCH, W . ;

SIMONSMEIER, W . ;

TONTSCH, F.:

Einführung in Software-Engineering, a.a.O., S. 59-64, PRESSMAN, R.S.: Software Engineering, a.a.O., S. 283-287, WIRTZ, K.W.: Methoden und Werkzeuge, a.a.O., S. 328-332, VALDER, W.; WELLER, U.: Schwierigkeiten mit der klassischen Systemanalyse, in: AI: 8/1984, S. 323-328 sowie DANIELS, HJ.: Die Bedeutung des Pflichtenheftes für den SoftwareEntwicklungsprozeß, in: AI: 3/1984, S. 87 f. (87-97). 912

Vgl. WAGEMANN, R.: SADT, in: MERTENS, P. (Haupthrsg.): Lexikon der Wirtschaftsinformatik, Berlin u.a. 1987, S. 295-298 (295-298).

^Vgl.

BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S . l l l ff. sowie

KIMM, R . ; KOCH, W . ; SIMONSMEIER, W . ; TONTSCH, F.: E i n f ü h r u n g i n S o f t w a r e - E n g i n e e r i n g ,

a.a.O., S.59 ff.

376 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

Aktivitätenmodell. Systemzusammenhänge werden lediglich aus einer anderen, datenorientierten Betrachtung analysiert.974 Steuerungsdaten

1

Eingabedaten

Aktivitätsbezeichnung

Ausgabedaten

t

Mechanismus

Bild 4-28: SADT-Aktivitätenmodell Regeln/V orgehensweise: Jeder Kasten bezieht sich auf eine bestimmte Abstraktionsstufe. Davon ausgehend bietet SADT die Möglichkeit der fortschreitenden Verfeinerung der Darstellung durch die Herauslösung von Subsystemen. Es ist allgemein üblich, bei der höchsten Abstraktionsstufe zu beginnen und diese schrittweise zu verfeinern. Dabei sollte darauf geachtet werden, dass jedes Teilsystem unabhängig von den Teilsystemen beschrieben werden kann, die sich auf der gleichen Abstraktionsebene befinden. Die Darstellungsform gestattet es, die Betrachtung auf eine hierarchisch höhere Systemebene zurückzuführen, so dass es dem Betrachter ermöglicht wird, stets einen Überblick über die Wirkungszusammenhänge des Gesamtsystems zu besitzen (Bild 4-29).915 Die in SADT enthaltene Vorgehensweise lässt sich so zusammenfassen:970 1. Parallele Entwicklung des Aktivitäten- und des Datenmodells, wobei die Entwicklung des Datenmodells i.d.R. zeitlich etwas später erfolgt. Dazu ist festzulegen, welchem Zweck die Darstellungen dienen sollen. Sie können einerseits der Beschreibung eines Systems im Istzustand dienen, andererseits Anforderungen an ein zu entwickelndes System oder den Entwurf eines solchen Systems enthalten. Es müssen in Abhängigkeit vom jeweiligen Zweck Aktionen und Daten bestimmt werden. Als erstes werden die Schnittstellen des Systems zum Umsystem durch Daten (im Aktivitä914 915 916

Vgl. HÖCKER, H.-J.: Die Bewertung, a.a.O., S . 1 0 5 . Vgl. DANIELS, H.-J.: Die Bedeutung, a.a.O., S. 90. Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 128 f.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

377

tenmodell) und Aktivitäten (im Datenmodell) untersucht und dargestellt. Das Ergebnis ist das Wurzeldiagramm A-0. Ausgehend von dem Wurzeldiagramm werden die Kästen (Aktivitäten oder Daten) schrittweise verfeinert, bis das erforderliche Konkretisierungsniveau erreicht ist. Die inhaltliche und formale Richtigkeit der Darstellungen werden in einem so genannten Autor-Kritiker-Zyklus überprüft.

2. Vergleich des Aktivitätenmodells und des Datenmodells, um inhaltliche oder formale Mängel aufzudecken und gegebenenfalls zu korrigieren. Eine Aktivität des Aktivitätenmodells muss ebenso im Datenmodell enthalten sein wie umgekehrt Daten des Datenmodells im Aktivitätenmodell. Ferner muss eine Datengruppe, die im Aktivitätendiagramm erzeugt wurde, in einem Datendiagramm als Kasten dargestellt sein. Für Aktivitäten und Daten sollten die gleichen Abstraktionsstufen eingehalten werden.977 3. Einführen des Steuerflusses durch Sequenzialisierung. Es ist zu beachten, dass die Pfeile im Aktivitätenmodell und im Datenmodell keinen Steuerfluss beschreiben. Die Anordnung der Aktivitäten sagt somit nichts über die 917

Vgl. BALZERT,H.: Die Entwicklung von Software-Systemen, a.a.O., S. 127.

378 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung zeitliche Abfolge der Aktivitäten aus. Es besteht jedoch die Möglichkeit der Berücksichtigung der zeitlichen Abfolge der Aktivitäten durch die Einfuhrung eines Steuerflusses mittels Nummerierung der Pfeile (Sequenzialisierung). Grundregeln: In einem SADT-Diagramm werden die Kästen von links oben nach rechts unten angeordnet. Bei der Erstellung eines SADT-Diagramms sollte darauf geachtet werden, dass ein Diagramm zwischen 3 und 6 Kästen (also Aktivitäten oder Daten) enthält. Diese Regel soll verhindern, dass die Darstellungen unübersichtlich werden. Sie kann aber dazu führen, dass zusätzliche abstrakte Aktivitäten oder Daten gebildet werden müssen, wenn eine Hierarchiestufe mehr oder weniger Aktivitäten oder Daten enthält. A-0 AO A1 A31

A2 A3 A4 A5 A6 ... A361

A3611

... A36161

Bild 4-30:

A36 . ..

A366

A3616 ...

A36166

SADT-Diagrammbaum

Der entscheidende Vorteil der Regel ist es aber, dass der Entwickler zu einer Beschreibung oder einem Entwurf gezwungen wird, der den Prinzipien der Abstraktion, der Hierarchisierung und der Strukturierung gerecht wird. Das Erstellen eines SADT-Diagramms oder besser einer Diagrammhierarchie zwingt den Entwickler zu einem exakten Verständnis des Systems. Ein »Herummogeln« um unverständliche Aspekte »rächt« sich in hierarchisch tieferen Diagrammen und zwingt oft zu einem völligen Neuanfang der Beschreibung

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

379

oder des Entwurfs. Bild 4-30 zeigt eine idealtypische Hierarchie von SADTDiagrammen. Jedes Diagramm weist maximal sechs Kästen auf. Bild 4-31 enthält ein SADT-Formular. Die Formularfelder haben folgende Bedeutung:97* Knoten: gibt die Position des Diagramms in der Hierarchie an, ζ. B.: A-0: Wurzel AO: Knoten hierarchisch direkt unter der Wurzel Al: Knoten hierarchisch zwei Stufen unter der Wurzel, Konkretisierung des ersten Kastens des AO-Diagramms A l l : Knoten hierarchisch drei Stufen unter der Wurzel, Konkretisierung des ersten Kastens des Al-Diagramms. Titel: Diagrammtitel des übergeordneten Diagramms Folgenummer: Nummer des auf die Darstellung folgenden Dokumentes. Projektbeschreibung Dokument Nr.

Knoten

Datum SADT-Formular

Titel

Kontext

Bezug

Folge Nr.

grafische Darstellung

Bemerkungen

Bild 4-31: SADT-Formular

Die Bilder 4-32 und 4-33 enthalten die Beschreibung des Istzustandes in einem Apothekenbetrieb mit Hilfe des Aktivitätenmodells.979 Die Kästen 1 und 3 des Knotens AO (Bild 4-32) stellen Aktivitäten der Umgebung des Systems 918 v g l . BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 113. 919

Vgl. FISCHER, D.: Sortimentsanalyse, a.a.O., S. 2 7 - 3 0 .

380 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Apothekenbetrieb dar. Bild 4-33 zeigt eine Verfeinerung des zweiten Kastens aus Bild 4-32. Es lassen sich folgende Vorteile feststellen:920 -

Unterstützung nahezu aller Prinzipien (mit Ausnahme der Modularisierung927 und der fehlenden expliziten Unterstützung der linearen Kontrollstrukturen) durch ein Regelwerk und die Darstellungstechnik. - Das Verfahren zwingt zu einem exakten Verständnis des zu beschreibenden oder des zu entwerfenden Systems. - SADT lässt sich unabhängig von der Projektgröße einsetzen. - Leichte Erlernbarkeit, sofort möglicher Einsatz, gutes Mittel zur Kommunikation. Dem gegenüber stehen folgende Nachteile: -

hoher Arbeitsaufwand bei Anwendung ohne Werkzeugunterstützung die Erweiterung von Modellen ist oft nur mit großem Aufwand möglich sehr großer Aufwand bei der Vornahme von Modifikationen, teilweise ist eine völlige Neuerstellung aller (!) Diagramme erforderlich. SADT ist deshalb ohne Werkzeugunterstützung ökonomisch kaum sinnvoll einsetzbar. - teilweise Einführung von künstlichen Abstraktionen, wenn eine Funktionsoder Datenebene nicht mit 3 bis 6 Kästen darstellbar ist - eine explizite Schnittstellenbeschreibung fehlt 4.2.5.2 Methoden für die Spezifikation, Konstruktion und Implementierung: Jackson-System-Development (JSD) Das Jackson-System-Development (JSD)922 ist eine Methode zur Spezifikation, zum Entwurf und zur Implementierung von Programmsystemen. Dabei wird ein einheitlicher phasenübergreifender Entwicklungsprozess angestrebt. Von Wichtigkeit ist die Verlagerung großer Teile des Entwurfs in die Implementierungsphase, so dass im Grunde die Phase Entwurf entfällt 923

920 921 922 923

Vgl. BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 132. Daher gibt es auch keine Unterstützung der Mehrfachverwendung, Bindung und Kopplung. Vgl. JACKSON, M.A.: System Development, Englewood Cliffs 1983. Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 136.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

381

Systemanalyse Apotheke Dokument Nr. 1-2 Knoten A 0

SADT-Formular

Titel System-Umwelt

medizinische Bestimmungen

Bezug Β Folge Nr. 1-3

Kontext A 0

Arzneimittelbestimmungen

Arzneimittelgesetzgebung allgemeine Bestimmungen

KKH versorgen 1

Bestellungen

allgem. Bestimmungen

Daten der HSt/GH \t

ι

f

bestellte Ware Daten der Apotheke Dienstleistungen

bestellte Ware betriebl. Informationssystem

Bemerkungen: Überblick Wirkungszusammenhänge System-Umsystem Bild 4-32: SADT-Diagramm (Apotheke und Umsystem)

382 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

Systemanalyse Apotheke Dokument Nr. 1-3

Knoten A2

SADT-Formular

Kontext AO

Titel System

•

Bezug C

lallg. Vorsch llg. Vorschriften I I Wareneingang Warenei

Daten KKH, HSt, GH

Folge Nr. 1-4

allg. Vorschriften, Daten

RIUF

Bestellungen

phys. WE

best. Ware

Aufträge bearbeiten

Auftragsdaten

1

Stammdaten Stammdaten pflegen

2 Stammdaten

w ιΜr ext./int. Informationen erstellen

3 statist. Daten

Bemerkungen: Überblick Arbeitsabläufe im System Bild 4-33: SADT-Diagramm

(Verfeinerung zweiter

Kasten)

externe Daten •

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

383

Das JSD beginnt mit einer Analyse der realen Welt außerhalb des zu entwickelnden Systems. Jacksons Vorstellung ist, dass vor einer Gestaltung des Systems ein Modell der Systemumgebung entwickelt werden muss. Im Zentrum des Modells stehen Objekte (Entities) und Aktionen, die von den Objekten erzeugt werden oder die auf sie wirken. Die Objekte und Aktionen, die das zu entwickelnde System betreffen, werden ermittelt und dargestellt. In Baumdiagrammen, so genannten Objektstrukturdiagrammen, wird die zeitliche Abfolge der Aktionen eines Objektes mit Hilfe der Strukturelemente der Strukturierten Programmierung (Reihung, Wiederholung, Auswahl) beschrieben. Im Anschluss daran erfolgt die Überführung jedes Objektes in einen Prozess und die Spezifikation der Kommunikation des Umwelt-Prozesses mit dem zu entwerfenden internen System-Prozess. Die Verknüpfung erfolgt entweder über Datenströme oder über so genannte Zustandsvektorinspektionen. Die von einem Systemprozess auszuführenden Aufgaben werden in Pseudocode beschrieben. Zur Erzeugung eines System-Outputs werden dem Modell Funktionen hinzugefügt. Funktionen sind nach M.A. JACKSON Systemprozesse, die beim Eintreten einer bestimmten Konstellation aus bestimmten Daten einen bestimmten Output erzeugen.924 Wenn alle Funktionen ermittelt und den Prozessen zugeordnet sind, werden zeitliche Beschränkungen wie Antwortzeiten u.ä. für die Prozesse eingeführt, die bei der Implementierung berücksichtigt werden müssen. Erst danach kann der Entwurf zur Implementierung weitergeleitet werden. Eine direkte Überführung des Entwurfs in eine Programmiersprache ist nicht möglich, da bis zum Beginn der Implementierung die Annahme galt, dass jeder Prozess genau einem Prozessor zugeordnet ist. Im Rahmen der Implementierung müssen die Prozesse auf die vorhandenen Ressourcen aufgeteilt werden. Der beschriebene Prozess des JSD kann in sechs Schritte zerlegt werden:92·5 1. Entity Action Step: Bestimmung der Objekte und Aktionen des Umsystems 2. Entity Structure Step: Beschreibung der Objekte durch Aktionen 3. Initial Model Step: Verbindung der Umsystem-Prozesse mit den internen System-Prozessen 4. Function Step: Einführung des Systemoutputs 924 VGL JACKSON, M.A.: System Development, a.a.O., S. 171. 925

Vgl. JACKSON, M.A.: System Development, a.a.O., S. 259-323.

384 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 5. System Timing Step: Einführung zeitlicher Anforderungen 6. Implementation Step: Aufteilung der Prozesse auf Ressourcen und Umwandlung in Programmiersprache. Wir wollen nun das JSD anhand eines Beispieles betrachten. Gegeben sei die folgende Problemstellung: Für einen Einzelhandelsbetrieb ist ein Informationssystem zu entwickeln, das die Verkäufe von Waren an Kunden erfasst. Die Bezahlung erfolgt direkt im Anschluss an den Kauf, oder das Konto des Kunden wird mit dem zu zahlenden Betrag belastet. 1. Entity Action Step Objekte des Umsystems sind zunächst das Personal des Betriebes, die Kunden, die Artikel, die Lagerorte der Artikel, die Kundenkonten und die Kassensysteme. Das Personal scheidet als Objekt des Umsystems aus, da wir unterstellen, dass es nicht von Interesse ist, welcher Verkäufer oder Kassierer mit dem Verkaufsprozess beschäftigt ist. Ebenso sind in diesem Fall die Lagerorte der Artikel für das zu erstellende Programm ohne Bedeutung. Objekte des Umsystems, die in das Programm einfließen müssen, sind in diesem Beispiel nur die Kunden und die Kundenkonten. Aktionen sind das Vorlegen von Artikeln an der Kasse sowie das Bezahlen, entweder direkt oder durch Belastung des entsprechenden Kundenkontos. Das Überweisen von Beträgen durch den Kunden auf das Kundenkonto ist in dem Beispiel auch von untergeordneter Bedeutung, da es nicht unmittelbar mit dem Verkauf von Ware zusammenhängt. Damit sind als Aktionen (Action steps) zu realisieren: ARTIKELVORLEGEN: Der Kunde entnimmt Artikel vom Lagerort und legt sie dem Kassenpersonal vor. BARZAHLUNG: Der Kunde bezahlt den genannten Betrag direkt im Anschluss an den Kauf in bar. Die Nummern und die Anzahl der vom Kunden gekauften Artikel werden für jeden Kaufakt in einer Datei gespeichert. BELASTUNGKONTO: Der Kunde identifiziert sich durch seinen Namen und seine Geheimnummer. Die Artikelnummern und die Anzahl der vom Kunden gekauften Artikel werden für jeden Kaufakt in einer Datei gespeichert. Der vom Kunden laut Datensatz

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

385

noch zu zahlende Betrag zuzüglich des aktuellen Kaufpreises darf einen festgelegten Betrag nicht übersteigen. ERÖFFNEKONTO: Für Kunden, die bisher noch kein Konto besitzen und nicht bar zahlen, ist ein neues Konto einzurichten. Es werden Name, Adresse und Geheimnummer des Kunden in einer Datei gespeichert. 2. Entity Structure Step Bild 4-34 enthält das Objektstrukturdiagramm, das sich aus dem Objekt »KUNDE« und den Aktionen »ARTIKEL VORLEGEN«, »BARZAHLUNG«, »BELASTUNG KONTO« und »ERÖFFNEJCONTO« ergibt. Aufgrund der Beschränkung auf die Strukturelemente der Strukturierten Programmierung sind einige abstrakte Aktionen einzuführen.

Bild 4-34: Objektstrukturdiagramm »KUNDE«

3. Initial Model Step Bild 4-35 zeigt die Darstellung des Objektes »KUNDE« als Prozess »KUNDE0« und dessen Verknüpfung mit dem Prozess »KUNDE-1«. Die Null kenn-

386 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung zeichnet einen Prozess des Umsystems, die Eins einen internen Systemprozess. Κ bezeichnet den Datenstrom für jede Aktion des Kunden in der Realität.

Bild 4-35: Systemspezifikationsdiagramm »KUNDE« Die beiden KUNDEN-Prozesse werden über einen Datenstrom miteinander verknüpft.926 Eine andere Form der Verknüpfung ist die Zustandsvektorinspektion, bei der der interne Systemprozess auf die Zustände des UmsystemProzesses zugreift und sie auswertet.927 Aus Gründen der Vereinfachung wird angenommen, dass bereits jeder Kunde des Betriebes ein Konto besitzt. Somit entfallen aus Bild 4-36 die Äste des Teilbaumes »KONTOAKTION«. Die Beschreibung des Prozesses 1 in Pseudo-Code lautet dann (Bild 4-36): KUNDE-1 sea read K; ARTIKEL_LESEN itr while (ARTIKEL_VORLEGEN); ARTIKEL_VORLEGEN; read K; BEZAHLEN sei (BARZAHLUNG) BARZAHLUNG; read K; BEZAHLEN sei (KONTOAKTION) KONTOAKTION; read K; BEZAHLEN end; TERMINATE; KUNDE-1 end

Bild 4-36: Pseudocode des Prozesses »KUNDE-1«92^ 4. Function Step Wir wollen uns bei diesem Schritt auf das Hinzufügen von zwei Funktionen beschränken. Als erstes soll jeder Kunde zum Abschluss seines Kaufes eine Rechnung über seinen Kauf erhalten (Funktion »Fl«), als zweites soll dem 920 927 928

Vgl. J A C K S O N , M . A . : System Development, a.a.O., S. 1 2 9 - 1 3 7 . Vgl. J A C K S O N , M . A . : System Development, a.a.O., S. 1 3 7 - 1 3 9 . Zum Pseudocode vgl. J A C K S O N , M . A . : System Development, a.a.O., S.

45.

4.2 Vorgehensweisen bei der traditionellen Softwareentwicklung

387

Kassenpersonal bei unbarer Zahllingsweise ein Überschreiten des Kreditrahmens angezeigt werden (Funktion »F2«).

Die Funktionen Fl und F2 stellen die beiden möglichen Funktionstypen dar. Die Funktion Fl ist unmittelbar mit dem Prozess KUNDE-1 verbunden; am Ende eines Einkaufs erhält jeder Kunde eine Rechnung. Funktion Fl wird als eine eingebettete Funktion bezeichnet.P2P Funktion F2 ist nicht unmittelbar mit dem KUNDE-1-Prozeß verbunden. Sie erfordert einen zusätzlichen Systemprozess, in der Abbildung als Inspektionsfunktion dargestellt. Der Prozess KUNDE-1 und die Funktion F2 werden durch eine Zustandsvektorinspektion verbunden. Die Funktion F2 heißt inspizierende Funktion.930 Die graphische Darstellung aus Bild 4-37 kann nun wieder in Pseudocode umgesetzt werden. Das Jackson-System-Development weist folgende Vorteile auf: - Umsetzung der Prinzipien der Standardisierung (durch ein durchgängiges Entwicklungsregelwerk), der Abstraktion (durch Beginn der Analyse beim Umsystem, aber kein Regelwerk), der integrierten Dokumentation, der Vollständigkeit und der Integriertheit (durch Einbeziehung der Umwelt) und der linearen Kontrollstrukturen (durch Einhaltung der Richtlinien der Strukturierten Programmierung). - Berücksichtigung der Umwelt bei der Systementwicklung. Integration von System- und Softwaredesign durch Analyse auch des Umsystems.957 - Eignung zur Entwicklung von Batch- und On-Line-Programmen. - Eignung für technische und betriebswirtschaftliche Aufgabenstellungen. 9 2 9

V g l . JACKSON, M . A . : S y s t e m D e v e l o p m e n t , a . a . O . , S. 1 7 8 - 1 8 1 .

9 3 0

V g l . JACKSON, M . A . : S y s t e m D e v e l o p m e n t , a . a . O . , S . 1 8 7 - 1 9 3 .

931

Vgl. SCHULZ, Α.: Software-Entwurf, a.a.O., S. 136.

388 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

- Umfangreiches Regelwerk Das Jackson-System-Development weist folgende Nachteile auf: - kein Regelwerk zur schrittweisen Verfeinerung der ermittelten und entworfenen Prozesse und Funktionen, zur Strukturierung des (internen) Systems, wie die einzelnen Prozesse und Funktionen in eine Rangordnung zu bringen sind. - Verstoß gegen das Prinzip des Information Hiding. Ein Prozess, der über Statusvektorinspektion mit einem anderen Prozess verbunden ist, muss dessen internen Aufbau kennen. - Verstoß gegen das Prinzip der Modularisierung. M.A. JACKSON berücksichtigt nicht die Aufteilung des Gesamtprozesses in Module, die das Prinzip des Information Hiding berücksichtigen. Die entworfenen Prozesse und Funktionen erfüllen nicht die Anforderungen, die an ein Modul zu stellen sind. 4.3 Qualitätsmanagement von Software

Nachdem die Vorgehensweisen der traditionellen Softwareentwicklung vorgestellt wurden, liegt der Schwerpunkt des letzten Abschnitts auf der Qualitätssicherung. Wie in anderen Wirtschaftsbereichen gewinnt der Qualitätsfaktor bei der Softwareproduktion zunehmend an Bedeutung. Dies liegt darin begründet, dass: -

die Korrektur von Fehlern einen erheblichen Kostenfaktor darstellt, besonders dann, wenn Fehler an fertigen Produkten korrigiert werden müssen. - die Maßnahmen zur Qualitätssicherung selbst Kosten verursachen und einer gründlichen Auswahl und Planung bedürfen. Damit kann es also nicht das Ziel sein, ein Maximum an Qualität zu produzieren. Die Anforderungen an die Qualität ergeben sich aus den Anforderungen an ein ganzheitliches Informationssystem. Welche Ziele durch dieses System erreicht werden sollen, orientiert sich an den Unternehmenszielen. Die Festlegung von Unternehmenszielen ist ihrerseits eine eindeutige Managementaufgabe. Nach ISO umfasst damit das Qualitätsmanagement „alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie Qualitätsplanung,

4.3 Qualitätsmanagement von Software

389

Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen"952. Der erste Teil dieses Kapitels dient der Klärung von Begriffen und der Darstellung von Qualitätsmerkmalen. Darauf aufbauend werden Möglichkeiten zur qualitativen Beurteilung von Software und Softwaremetriken beschrieben. Anschließend wird gezeigt, welche Maßnahmen zur Qualitätssicherung ergriffen werden können. Das Kapitel wird durch eine kurze Beschreibung von wesentlichen Normen zum Qualitätsmanagement abgeschlossen. Das Ziel der folgenden Ausführungen ist es, Ansätze aufzuzeigen, mit denen sich die Softwarequalität zum einen beurteilen und zum anderen durch ein ganzheitliches Qualitätsmanagement beeinflussen lässt. Die Qualitätssicherung betrifft nicht nur in der Entwicklung befindliche Software, gleichermaßen sollte auch die Qualität bereits bestehender Programme beurteilt und beeinflusst werden. Der erste Teil dieses Kapitels dient der Definition von Begriffen und der Darstellung von Qualitätsmerkmalen. Darauf aufbauend werden Möglichkeiten zur qualitativen Beurteilung von Software und Softwaremetriken beschrieben. Anschließend wird gezeigt, welche Maßnahmen zur Qualitätssicherung ergriffen werden können. Das Kapitel wird durch eine kurze Beschreibung von wesentlichen Normen zum Qualitätsmanagement abgeschlossen. 4.3.1 Begriffe zur Qualitätssicherung und Darstellung der Qualitätsmerkmale Die im folgenden verwendeten Begriffe Qualität und Qualitätssicherung werden gemäß der geltenden Norm ISO 8402 wie folgt definiert:953 Qualität: »Die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Dienstleistung, die sich auf deren Eignung zur Erfüllung festgelegter oder vorausgesetzter Erfordernisse beziehen.« Qualitätssicherung: »Alle diejenigen geplanten und systematischen Tätigkeiten, die notwendig sind, um ein hinreichendes Vertrauen zu schaffen, dass ein Produkt oder eine Dienstleistung die festgelegten Qualitätsanforderungen erfüllen wird.«

Normen zum Qualitätsmanagement bei der Softwareentwicklung, in: Informatik Spektrum: 1 8 / 1 9 9 5 , S. 3 1 5 ( 3 1 4 - 3 2 3 ) . DIN DEUTSCHES INSTITUT FÜR NORMUNG E . V . (Hrsg.): DIN ISO 8 4 0 2 : Qualitätsmanagement und Qualitätssicherung, Berlin 1992. KNEUPER, R . ; SOLLMANN, F.:

955

390 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Der Nutzen eines Systems ist im wesentlichen von dessen Qualität abhängig. Die Softwarequalität wird weitgehend festgelegt durch die Methoden, Beschreibungsmittel, Richtlinien und Werkzeuge, die bei der Softwareentwicklung verwendet werden.934 Um die Softwarequalität zu überprüfen empfiehlt es sich, den Qualitätsbegriff zu operationalisieren. Dieses geschieht durch die Definition von Qualitätsmerkmalen. Damit ergibt sich die angestrebte Qualität der Software aus der Summe von erreichten Qualitätsmerkmalen. Vor einer Diskussion der Maßnahmen zur Qualitätssteigerung müssen die angestrebten Qualitätsmerkmale festgelegt werden. Welche Qualitätsmerkmale Software aufweisen sollte, wird in der Literatur unterschiedlich diskutiert. Daher werden im folgenden vier unterschiedliche Ansätze in chronologischer Ordnung vorgestellt und anschließend im Überblick systematisiert und verglichen. 1. Ansatz von B.W. BOEHM (1976)935 Hier stehen technische Qualitätsmerkmale wie Zuverlässigkeit und Effizienz im Vordergrund, die Erfüllung der fachlichen Anforderungen wird nicht berücksichtigt. Ebenso wird der Bedienbarkeit eine eher untergeordnete Rolle zugewiesen. Zuverlässigkeit In Anlehnung an DIN 40041 (Vornorm) lässt sich Zuverlässigkeit verstehen als die Fähigkeit einer Betrachtungseinheit, innerhalb von vorgegebenen Grenzen denjenigen Anforderungen zu genügen, die an das Verhalten während einer gegebenen Zeitdauer gestellt werden. Die Zuverlässigkeit bezieht sich also darauf, beabsichtigte Funktionen unter festgelegten Bedingungen für einen festgelegten Zeitraum zu erfüllen. 956 Effizienz Die Effizienz bezieht sich auf eine möglichst günstige Ausnutzung der Systemressourcen. Dabei wird bspw. unterscheiden zwischen -

Speichereffizienz, Laufzeiteffizienz und

Über das Prüfen, Messen und Bewerten von Software, in: Informatik Spektrum: 2/1987, S. 123 (123-144). Vgl. BOEHM, B . W . : Software Engineering, in: IEEE Transactions on Computers: C-25, 12/1976, S. 1226-1241, zitiert nach: FRÜHAUF, K . ; LUDEWIG, J.; SANDMAYR, H . : SoftwareProjektmanagement und -Qualitätssicherung, Stuttgart 1988, S. 18 f. Vgl. SCHWEIGGERT, F.: Software-Qualität - Eine Standortbestimmung, in: KÖLSCH, R . ; SCHMID, W.; SCHWEIGGERT, F. (Hrsg.): Wirtschaftsgut Software, Stuttgart 1985, S. 14 (9-30).

9 3 4 YGJ JJAUSEN, H . - L . ; MÜLLERBURG, M . ; SCHMIDT, Μ . : 935

936

4.3 Qualitätsmanagement von Software

391

- Übertragungseffizienz (ζ. B. in Netzwerken). Durch dieses Qualitätskriterium soll einem unnötigen Verbrauch an Ressourcen Einhalt geboten werden. Bedienbarkeit Dieses Kriterium weist in Richtung Anwender und steht in Zusammenhang mit den Begriffen Bedienungshilfen und Mensch-Maschine-Schnittstelle. Änderbarkeit Software sollte die Eigenschaft haben, dass sie sich später leicht an geänderte Problemstellungen anpassen lässt, denn Software ist kein statisches Gebilde. Es muss die Möglichkeit zur dynamischen Anpassung an geänderte Anforderungen bestehen. Das Qualitätskriterium Änderbarkeit besitzt dadurch nicht nur in der Wartungsphase, sondern auch während der Entwicklungsphase Bedeutung. Portabilität Dieses Kriterium bezieht sich auf den Aufwand für die Übertragung eines Softwareproduktes auf eine andere Hardware- und/oder Systemsoftwareumgebung. Dabei sollte weder der funktionelle Umfang noch die Qualität der portierten Software beeinträchtigt werden.937 Testbarkeit «Die Testbarkeit von Softwarezwischen-/-endprodukten drückt sich in den Ergebnissen des Testens, das heißt in der Fehleraufdeckungsrate und dem Testaufwand aus.« ws Verständlichkeit Die Software soll eine gute Strukturierung aufweisen und aus sich selbst heraus verständlich sein. Zudem sind die Anweisungen prägnant zu formulieren. 2. Ansatz von K. FRÜHAUF, J. LUDEWIG und H. SANDMAYR (1985)P59 Die von BOEHM definierten Merkmale werden von FRÜHAUF U.A. im wesentlichen aufgegriffen, zusätzlich wird auch die Benutzungsfreundlich937

938

Vgl. WILLMER, H.: Systematische Software-Qualitätssicherung anhand von Qualitäts- und Produktmodellen, Berlin u.a. 1985, S. 36 f. SCHMITZ, P.; BONS, H.; VAN MEGEN, R.: Software-Qualitätssicherung - Testen i m Software-

Lebenszyklus, Braunschweig/Wiesbaden 1983, S. 27. 939

V g l . FRÜHAUF, K.; LUDEWIG, J.; SANDMAYR, H.: Software-Projektmanagement und -Quali-

tätssicherung, Stuttgart 1988, S. 19 f.

392 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung keit und die Fehlerrobustheit des Systems berücksichtigt. Auch hier werden fachliche Anforderungen nicht genannt. Korrektheit Korrektheit lässt sich als Übereinstimmung zwischen den realisierten und den spezifizierten Funktionen verstehen. Effizienz Eine hohe Effizienz wird erreicht, wenn die Ressourcen (Prozessoren, Speicher usw.) nur wenig beansprucht werden. Robustheit Ein System besitzt diese Qualitätseigenschaft, wenn es auch bei der Verletzung von Randbedingungen die vereinbarten Funktionen erfüllt oder wenn die Funktionsfahigkeit des Systems erhalten bleibt. Benutzungsfreundlichkeit Unter diesem Kriterium wird der »Grad, in dem das Produkt seine Aufgaben erfüllt, ohne Zeit und Energie des Benutzers zu verschwenden bzw. ohne seine Motivation herabzusetzen«940 verstanden. Änderbarkeit Die Adaptierbarkeit oder Änderungsfreundlichkeit wird dadurch bestimmt, wie gut ein Programm sich an Änderungen in der »realen Welt« anpassen lässt. Portabilität Portabilität ist ein qualitatives Maß, das sich auf den Aufwand bei der Übertragung einer gegebenen Software auf eine andere Ablaufumgebung bezieht. Lesbarkeit Dieses Kriterium betrifft sämtliche Dokumente, von der Spezifikation bis zum Programmcode, die während des Softwareentwicklungsprozesses erstellt werden. Außenstehende müssen in der Lage sein, die einzelnen Dokumente zu verstehen. Der Aufwand, der hierfür erforderlich ist, kann als Anhaltspunkt für das Kriterium Lesbarkeit gelten. Strukturierung Sowohl Software selbst als auch sämtliche Dokumente der Entwicklung sollten eine »innere Ordnung« aufweisen. Dies bedeutet, dass ähnliche

940 YGJ BALZERT, H.: Die Entwicklung von Software-Systemen, a.a.O., S. 12.

4.3 Qualitätsmanagement von Software

393

Dinge ähnlich realisiert werden und dass eine einheitliche Gliederung im gesamten System verwendet wird. 3. Ansatz von R . A S A M , N. DRENKARD und H.-H. M A I E R (1986)941 Der Ansatz von ASAM U.A. stellt eine deutliche Weiterentwicklung dar. Es wird beurteilt, inwieweit das System die fachlichen Anforderungen erfüllt, ebenso wird der Begriff der Wartungsfreundlichkeit definiert. Zudem rücken die Bedürfnisse der Benutzer stärker in den Vordergrund. Außerdem werden konzeptionelle Merkmale, bspw. die Konsistenz der Software, ausdrücklich berücksichtigt. Brauchbarkeit Dieses Kriterium bezieht sich auf die Eignung von Software zur ständigen Erfüllung der vorgesehenen Aufgaben. Störungserkennung/Störungstoleranz Wiederherstellbarkeit Software sollte nach einem Fehlerfall wieder in einen korrekten Ausgangszustand versetzt werden können. Erlernbarkeit/Transparenz Handhabbarkeit Wartungsfreundlichkeit Die Wartungsfreundlichkeit bezieht sich auf den Aufwand für Fehlerkorrekturen und auf den Aufwand für Änderungen/Erweiterungen. Dieser Aufwand sollte möglichst klein gehalten werden.^ 2 Verständlichkeit Dokumentation und Quellcode müssen primär auf den »Leser« ausgerichtet sein. Durchschaubarkeit Verständlichkeit des Systemverhaltens in allen Komponenten. Konsistenz Damit ist die Widerspruchsfreiheit zwischen Dokumentation und/oder implementierten Modulen gemeint. 941 vgl. ASAM, R.; DRENKARD, N.; MAIER, H.-H.: Qualitätsprüfung von Softwareprodukten, Berlin/München 1986, S. 98 ff. 942

ASAM, R.; DRENKARD, N.; MAIER, H.-H.: Qualitätsprüfung von Softwareprodukten, a.a.O., S. 27.

394 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 4. Ansatz von H. TRAUBOTH (1993)943

fuhrt die Ideen von BOEHM weiter und konkretisiert sie auf technischer Ebene, so dass der Merkmalskatalog gut operationalisiert ist. Erstmals wird die Wiederverwendbarkeit der Software als Qualitätsmerkmal genannt. Zudem legt TRAUBOTH auch einen Schwerpunkt auf die fachliche Funktionserfüllung. Es werden jedoch keine Kriterien zu konzeptionellen Merkmalen der Software berücksichtigt. TRAUBOTH

Zuverlässigkeit Die Beschaffenheit der Software, während oder nach einer definierten Zeitspanne bei vorgegebenen Anwendungsbedingtingen die in der Spezifikation festgelegten Zuverlässigkeitsforderung zu erfüllen. Diese Größe wird z.B. durch eine Wahrscheinlichkeit operationalisiert. Leistung Die Leistung einer Software drückt sich durch das Zeitverhalten (z.B. Rechenzeit, Antwortzeit, Wartezeit) und die Inanspruchnahme von Betriebsmitteln (z.B. Speicherplatzbedarf, Zugriffshäufigkeit auf Ressourcen, manuelle Bedieneingriffe des Personals) aus. Sicherheit Qualitativ lässt sich Sicherheit als Eigenschaft der Software ansehen, durch die unter definierten Bedingungen in einem vorgegebenen Zeitraum unzulässige Ereignisse (z.B. Unfälle, die zu Schäden führen) nicht möglich sind. Verfügbarkeit Die Verfügbarkeit ist eine statistische Zuverlässigkeitskenngröße. Sie definiert sich durch die Wahrscheinlichkeit, ein System zu einem gegebenen Zeitpunkt in einem funktionsfähigen Zustand anzutreffen (availability). In der Praxis wird diese Größe häufig als Quotient operationalisiert: Verfügbarkeit = mittlere Betriebszeit / (mittlere Betriebszeit + mittlere Ausfallzeit) Benutzerfreundlichkeit Dieser Faktor hängt stark von der Anwendung der Software und der Qualifikation des Bedienungspersonals ab. Dabei wird unter Benutzerfreundlichkeit der Aufwand des Benutzers (z.B. Lernzeit, Anzahl der Schritte bei Fehlersituationen) und der Grad der Handhabbarkeit (z.B. 943 YGJ TRAUBOTH, H.: Software-Qualitätssicherung Maßnahmen, München 1993, S. 25-36.

-

konstruktive

und

analytische

4.3 Qualitätsmanagement von Software

395

Übersichtlichkeit der Informationsdarstellung, Art der Bedienerführung) subsumiert. Funktionserfüllung Die betrachtete Software soll die in der Anforderungsspezifikation festgelegten Funktionen innerhalb definierter Restriktionen erfüllen. Wartungsfreundlichkeit Als wartungsfreundlich wird eine Software dann bezeichnet, wenn der Aufwand für das Erkennen von Fehlerursachen und ihre Korrektur oder das Durchführen von Änderungen mit möglichst geringem Aufwand erfolgen kann. Portabilität Dieser Punkt bezeichnet die Eignung einer Software für den Einsatz in geänderter technischer Umgebung. Voraussetzung hierfür ist die Standardisierung der Programmiersprache, wenn der Quellcode von einem Rechnertyp auf einen anderen durch den Einsatz von Compilern übertragbar werden soll. Ebenso wird unter Portabilität die Wiederverwendbarkeit von ProgrammModulen in anderen Softwaresystemen verstanden. In Bild 4-38 sind die vorgestellten Ansätze zur Softwarequalität im Überblick und im Vergleich dargestellt. Gleichzeitig werden die Softwarequalitätskriterien in eine Systematik von vier Merkmalsgruppen eingeordnet. Manche Kriterien können nicht eindeutig in eine Gruppe eingeordnet w e r d e n d Es wird deutlich, dass Ausgestaltung und Bedeutung der einzelnen Qualitätsmerkmale einem Wandel unterliegen. Unserer Meinung nach muss Software in technischer Hinsicht (möglichst) fehlerfrei, effizient und zuverlässig laufen. Selbstverständlich müssen die fachlichen Anforderungen erfüllt werden, dabei ist, aus Gründen der Akzeptanz und der Effektivität des Anwenders, darauf zu achten, dass die Software benutzerfreundlich ist. Aus ökonomischen Gründen sollte die Software wartungsfreundlich und ggf. wiederverwendbar sein. Im Rahmen eines ganzheitlichen Informationsmanagements muss zudem darauf geachtet werden, dass der Software ein konsistentes Konzept zugrunde liegt.

944

Bspw. ist die Einordung der Leistung nicht eindeutig. In erster Linie ist die Antwortzeit zwar eine technische Größe, bei einem Echtzeit-Platzbuchungssystem kann jedoch eine maximale Antwortzeit auch durch fachliche Anforderungen definiert sein. Die Portabiliät wird als ökonomisches Merkmal aufgefaßt. Wenn eine Software-Lösung auf ein anderes System übertragen werden soll, treten bei mangelnder Protabilität Anpassungsschwierigkeiten auf, die durch erhöhten Ressourceneinsatz, und damit höhere Kosten, kompensiert werden müssen.

396 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

L

Technische Merkmale

BOEHM

FRÜH AUF U. A.

ASAMU.A.

TRAUBOTH

(1976)

(1985)

(1986)

(1993)

Zuverlässigkeit

Korrektheit

Effizienz (Ressourcen, Übertragung)

Effizienz (Ressourcen)

Robustheit

Brauchbarkeit

Zuverlässigkeit Leistung (Zeitverhalten, Betriebsmittel)

Sicherheit Störungserkennung/Störungstoleranz, Wiederherstellbarkeit Verfügbarkeit

Π.

Bedienbarkeit

Fachliche Merkmale

in. Ökonomische Merkmale

IV.

Konzeptionelle Merkmale

Benutzungsfreundlichkeit

Änderbarkeit

Änderbarkeit

Portabilität

Portabilität

Erlernbarkeit/ Transparenz, Handhabbarkeit

Benutzerfreundlichkeit, Aufwand, Handhabbarkeit

Brauchbarkeit

Funktionserfüllung

Wartungsfreundlichkeit

Wartungsfreundlichkeit, Änderbarkeit, Wartbarkeit Portabilität, Wiederverwendbarkeit

Testbarkeit Verständlichkeit

Lesbarkeit

Verständlichkeit

Strukturierung

Durchschaubarkeit Konsistenz

Bild 4-38: Systematisierung und Vergleich der Softwarequalitätsmerkmale Eine Definition der einzelnen Qualitätsmerkmale reicht allerdings noch nicht aus, da die Begriffe abstrakter Natur und kaum operational sind. Für eine Operationalisierung werden die angestrebten Qualitätsmerkmale solange verfeinert, bis sie auf einer konkreten Betrachtungsebene definiert werden.

4.3 Qualitätsmanagement von Software

397

Die Softwarequalitätsmerkmale stehen in Beziehung zueinander. Sie dürfen daher nicht isoliert betrachtet werden. Eine zusammenhängende Darstellung von Qualitätskriterien wird auch als Qualitätsmodell bezeichnet. Oft wird versucht, hierarchische oder Netzwerkstrukturen zwischen den einzelnen Qualitätsmerkmalen aufzustellen. Bild 4-39 zeigt ein hierarchisches Qualitätsmodell zur Softwarequalität, in dem beispielhaft das Qualitätsmerkmal Wartungsfreundlichkeit ebenfalls hierarchisch eingebunden ist. Software-Qualität

BenutzerAkzeptanz

Ausbaufähigkeit

Bild 4-39: Hierarchisches Qualitätsmodell zur Softwarequalität945

4.3.2 Möglichkeiten zur qualitativen Beurteilung von Software Zur Beurteilung der Softwarequalität lassen sich mehrere Formen unterscheiden:

In Anlehnung an SNEED, H.M.: Software Qualitätssicherung, a.a.O., S. 3 2 und ASAM, R.;

DRENKARD, N.; MAIER, H.-H.: Qualitätsprüfung von Softwareprodukten, a.a.O., S. 99.

398 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

1. Beobachtung940 Qualitätsmerkmale lassen sich durch Beobachtung des Softwareproduktes im produktiven Einsatz, bspw. durch Auswertungen der Fehlerhäufigkeit oder der Hot-Line-Statistik ermitteln. 2. Abschätzung Wird durch ein noch nicht installiertes (Teil-) Produkt auf Eigenschaften eines künftigen Systems geschlossen, so handelt es sich um eine Abschätzung. 3. Voraussage (Prognose) Voraussagen werden auf analytischem Wege gewonnen, indem ζ. B. durch Analogieschlüsse auf Qualitätsmerkmale eines künftigen Systems geschlossen wird. 4. Analysen Bei den Analysen wird zwischen maschinellen und manuellen Analysen unterschieden. Bei den maschinellen Analysen werden Programme eingesetzt, die erstellte Software ζ. B. auf die Einhaltung von Programmierrichtlinien, Komplexität, Korrektheit etc. prüfen.947 Durch manuelle Prüfverfahren können die Dokumente der Softwareentwicklung auf die Einhaltung von Qualitätsmerkmalen überprüft werden. Zu den manuellen Prüfverfahren zählen Code-Inspektion, Walk-through etc. Diese Verfahren bauen auf dem Prinzip »4 Augen sehen mehr als 2« auf. Der Erfolg der Analysen hängt allerdings wesentlich von den beteiligten Personen ab.948 5. Verifikation (im engeren Sinne) Bei der Verifikation (im engeren Sinne) wird versucht, die Korrektheit formal zu beweisen. Der Aufwand für einen formalen Beweis ist außerordentlich hoch, daher wird die Verifikation (im engeren Sinne) im Bereich der kommerziellen Datenverarbeitung nur selten angewandt.

946

Vgl. ASAM, R . ; DRENKARD, N . ; MAIER, H . - H . : Qualitätsprüfung von Softwareprodukten, a.a.O., S. 44 ff. 947 Vgl. MAJORONS, M . : Softest: Α System for the Automatic Verification of PL/1, COBOL and Assembler Programms, in: SNEED, H . M . ; WIEHLE, H . R . (Hrsg.): Software-Qualitätssicherung, Stuttgart 1982, S. 253 ff. (253-264). 948 VGL HAUSEN, H.-L.: MÜLLERBURG, Μ . ; SCHMIDT, Μ . : Über das Prüfen, Messen und Bewerten von Software, a.a.O., S. 126.

4.3 Qualitätsmanagement von Software

399

6. Test Tests beruhen auf Stichproben mit deren Hilfe bestehende Fehler aufgedeckt werden sollen. Bei den Stichproben wird versucht, mögliche zukünftige Situationen zu berücksichtigen. Allein mit Tests kann die Korrektheit eines Programmes jedoch nicht bewiesen werden. 7. Reviews Bei den Reviews werden die einzelnen Arbeitsergebnisse von einem Sachverständigen-Team auf Richtigkeit bezüglich der Vorgaben überprüft. Im Vergleich zu Tests verursachen Reviews wesentlich geringere Kosten.949 Ein weiterer Vorteil der Reviews ist, dass sie an vielen Stellen im Projektablauf eingesetzt werden können, so dass nicht gewartet werden muss, bis eine lauffähige Programmversion erstellt wurde. 8. Walk-Through Beim Walk-Through werden kleinere Entwicklungsabschnitte (Teilentwurf, Dokumente, Quellcodeteile etc.) in einem Team von maximal acht Teilnehmern besprochen. Die Teammitglieder erhalten vorab die zur Diskussion stehenden Unterlagen des Entwicklungsabschnitts, die bezüglich technischer Fragen, Standards, Stil, Fehlerquellen etc. betrachtet werden. Es ist möglich, dass bestimmte Testfälle ausgewählt werden und das Programm »im Kopf« ausgeführt wird. Der verantwortliche Entwickler ist während des WalkThrough anwesend und beantwortet Fragen. Die Diskussion sollte eine Zeitdauer von zwei Stunden nicht übersteigen.950 9. Softwaremessung95' Eine Softwaremessung ist eine einmalige, kurze Aktion, die i.d.R. von einem externen Dienstleister durchgeführt wird, damit eine möglichst neutrale Bewertung der Software erfolgt. Diese Bewertung basiert auf einer maschinellen Analyse des Quellcodes, gekoppelt mit einer manuellen Analyse der Dokumentation. Das Ergebnis stellt eine Beurteilung der Software nach verschiedenen Gesichtspunkten dar, z.B. nach Wartbarkeit, Sanierbarkeit und Kosten der Neuentwicklung. 949

V g l . FRÜHAUF, K.; LUDEWIG, J.; SANDMAYR, H.: S o f t w a r e - P r o j e k t m a n a g e m e n t und "Quali-

tätssicherung, a.a.O., S. 66. 950

951

V g l . ASAM, R.; DRENKARD, N ; MAIER, H.-H.: Qualitätsprüfung v o n

Softwareprodukten,

a.a.O., S. 86. Vgl. SNEED, H.M.; ROTHHARDT, G.: Software-Messung, in: Wirtschaftsinformatik·. Vol. 38, 2/1996, S. 172(172-180).

400 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Die Softwaremessung ist gut operationalisiert, bspw. sind die Qualitätsmerkmale, nach denen Softwareprodukte zu bewerten sind, sowie die Metriken für die Messung der einzelnen Merkmale detailliert in der Norm ISO 9126 beschrieben.^ 4.3.3 Softwaremetriken

Unter Metriken versteht man im allgemeinen Sprachgebrauch Maßsysteme. Sie werden z.B. im Bereich der Mathematik oder in der Physik eingesetzt, um Eigenschaften von Räumen, Körpern oder Prozessen vergleichbar und messbar zu machen. Auf das Gebiet der Softwareentwicklung übertragen kann man unter Softwaremetriken Maße, Maßzahlen oder Maßsysteme verstehen, mit denen sich Softwaresysteme quantitativ vergleichen lassen.95·5 Mit Hilfe von Softwaremetriken lassen sich die Softwarequalität und die Entwicklungsproduktivität messen und steuern. Bei der Bildung von Softwaremetriken ist darauf zu achten, dass - eine leichte Erfassbarkeit möglich ist, - die Metriken internationale Gültigkeit haben und - geringe Erfassungskosten entstehen. Beispiele für Softwaremetriken Die Programmgröße lässt sich mit Hilfe der Codezeilen (Lines of Code) ermitteln. Diese lassen sich i.d.R. einfach mit Hilfe von Editoren oder einfachen Tools erfassen. Häufig wird dieses Maß zur Beurteilung der Entwicklungsproduktivität (Lines of Code geteilt durch Entwicklungsaufwand in Monaten) verwendet. Auch zur Ermittlung der Systemfehlerrate werden die Codezeilen benötigt. Die Systemfehlerrate lässt sich berechnen aus der Gesamtzahl der während des Systemtests gemeldeten Softwarefehler bezogen auf die Produktgröße (z.B. Anzahl Fehler pro tausend Codezeilen). Zur Beurteilung der Qualität eines Produktes beim Kunden wird die Fehlerrate verwendet. Diese Kennzahl berechnet man aus der Gesamtzahl der während des ersten Jahres beim Kunden gefundenen Fehler, bezogen auf die Produktgröße (gemessen in tausend 952

953

Eine Darstellung der Norm findet sich in: INTERNATIONAL ORGANISATON FOR STANDARDIZATION (Hrsg.): ISO 9126 Software Product Evaluation, Genf 1994. Vgl. MÖLLER, K.H.; PAULISH, D J . : Software-Metriken in der Praxis, München/Wien 1993, S. 12.

4.3 Qualitätsmanagement von Software

401

Codezeilen). Zur Beurteilung der Termintreue lässt sich eine Kennzahl bilden aus der Differenz zwischen der geplanten und der tatsächlich benötigten Entwicklungsdauer geteilt durch die geplante Entwicklungsdauer. Eine negative Zahl zeigt dabei eine Terminüberschreitung an.954 Als weiteres Maß zur Beurteilung der Programmgröße verwendet man die Function-Point-Methode. Hierbei versucht man zu berücksichtigen, dass die Beurteilung einer zu lösenden Aufgabe von mehreren Faktoren wie z.B. der Anzahl der Datenein- und -ausgaben, Abfragen, Referenzdaten oder der verwendeten Programmiersprache abhängt. Die Function-Points werden mit Hilfe einer Formel ermittelt955. Die oben beschriebenen Kennzahlen lassen sich selbstverständlich auch im Hinblick auf die Function-Points ermitteln. Auch im Hinblick auf die Entwicklungsphasen können Kennzahlen abgeleitet werden. Beispiele hierzu sind: - Anzahl der Änderungswünsche an die Systemspezifikation - Anzahl der Systemkonstruktionsfehler - Testfehlerrate Bei der Entwicklung von Software ist es vorteilhaft, wenn aus bereits abgeschlossenen Entwicklungen Teile verwendet werden können. Wie gut dies gelingt, lässt sich durch die folgende Kennzahl beschreiben:950 W

=(S V /(S W + S n ))* 100

W: = Wiederverwendeter Anteil der Software in Prozent Sv: = Wiederverwendete Software in Lines of Code Sn: = Neu erstellte Software in Lines of Code Aus den bisherigen Ausführungen ist ersichtlich, dass man Softwaresysteme und auch den Entwicklungsprozess durch sehr viele Maße und Kennzahlen beschreiben kann. Die Auswahl der Maße und Kennzahlen ist abhängig von den verfolgten Qualitätszielen. Die Qualitätsziele ihrerseits lassen sich aus den verfolgten Unternehmenszielen gewinnen. Damit ergibt sich der in Bild 4-40 dargestellte Regelkreis. Die Gewinnung von Kennzahlen erfolgt in der Praxis häufig durch Tools, die entweder selbst entwickelt werden oder bereits als Standardlösungen zur Verfügung stehen. Oft besteht heute noch eine Diskrepanz zwischen den 954

Vgl. MÖLLER, K.H.; PAULISH, DJ.: Software-Metriken in der Praxis, a.a.O., S. 82 ff. Siehe Band 1, Kap. 6.4.3.8. 95i V g l . THALLER, G . E . : Software-Metriken - einsetzen, bewerten, messen, Hannover 1994, S. 102 f. 955

402 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung individuellen Bedürfnissen der Praxis und dem Angebot an Standardsoftware, so dass zur Zeit noch viele Unternehmen hier eigene Lösungen schaffen. Als ein Beispiel für eine Standardlösung zum statischen Softwaretest sei hier auf Qualigraph verwiesen.957

Zusammenfassung Durch den Einsatz von Softwaremetriken lässt sich -

die Softwarequalität verbessern, die Produktivität bei der Softwareentwicklung erhöhen, eine höhere Planungsgenauigkeit erreichen und die Softwareentwicklung im Rahmen des Entwicklungsmanagements besser steuern und überwachen.

957 YGJ STEIN, W.: Qualigraph - ein Werkzeug für den statischen Softwaretest, in: BALZERT, H .

(Hrsg.): CASE - Systeme und Werkzeuge; a.a.O., S. 401-422.

4.3 Qualitätsmanagement von Software

403

4.3.4 Maßnahmen zur Qualitätssicherung Im ersten Teil dieses Kapitels werden die Maßnahmen zur Qualitätssicherung aus der Sicht der Kosten betrachtet, im zweiten Teil werden dann Einzelmaßnahmen zur Qualitätssicherung beschrieben. Im dritten Teil wird gezielt dargestellt, welche Möglichkeiten zur Qualitätssicherung bei eingesetzter Software bestehen. 4.3.4.1 Qualitätssicherung und Entwicklungskosten Bei der Softwareentwicklung spielen vor allem die Personalkosten eine entscheidende Rolle. Kosten für Rechnernutzung, Räume, Verbrauchsmaterial etc. lassen sich i.d.R. kurz- und mittelfristig nicht beeinflussen und sind auch absolut betrachtet von untergeordneter Bedeutung. Basierend auf dem Softwarelebenszyklus bietet es sich an, zu ermitteln, wie sich die Personalkosten auf die einzelnen Phasen und auf die beteiligten Entwickler verteilen. Dabei ist festzustellen, dass sich die Kosten näherungsweise proportional zur Entwicklungszeit verhalten. Aus diesem Grund ist bei der Betrachtung der Entwicklungskosten eine Analyse der Entwicklungszeit hinreichend genau. Softwarequalität und Entwicklungskosten stehen zunächst in einem konträren Verhältnis zueinander. Kurzfristig gesehen führen Maßnahmen zur Qualitätssteigerung zuerst zu einem Anstieg der Entwicklungskosten. Mittelund langfristig betrachtet besteht jedoch die Chance, dass die Investitionen zu Produktivitätssteigerungen bei gehobenem Qualitätsniveau führen können. Auch ist offensichtlich, dass die Fehlerbehebungskosten steigen, je früher Fehler begangen und je später sie entdeckt werden.9·55 Deshalb müssen besonders die frühen Phasen im Softwarelebenszyklus überprüft und getestet werden. Eine Überprüfung, die erst vor der Übergabe stattfindet, ist unzureichend. Wie bereits in Kap. 4.1.4.2 erwähnt, berichtet H.M. S N E E D , dass ein CodeFehler etwa fünfmal soviel kostet, wenn er nach der Systemintegration und nicht gleich in der Codierungsphase behoben wird. Wenn derselbe Fehler nach der Systemfreigabe entdeckt wird, kostet die Fehlerbehebung bereits das zehnfache. Liegt der Fehler nicht in der Codierphase, sondern schon früher, so wird die Fehlerbehebung nochmals wesentlich teurer. Sofern ein Softwaresys-

958 VGL. FOIDL, H.; HILLEBRAND, K.; TAVOLATO, P.: Prototyping, die Methode - das Werkzeug -

die Erfahrung, in: AI: 3/1986, S. 96 (95-100).

404 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung tem erst nach Fertigstellung getestet oder verifiziert wird, ist im Fehlerfall ein hoher Korrekturaufwand zu erwarten, da generell gilt: Je später ein Fehler festgestellt wird, desto höher sind die Korrekturaufwendungen.959 Die Tendenz dieser Aussagen wird durch empirische Tests von B.W. BOEHM untermauert.900 Da Qualitätssicherungsmaßnahmen zunächst Kosten verursachen und ihre Anwendung eine Investitionsmaßnahme darstellt, müssen sie selbst einer Wirtschaftlichkeitsbetrachtung unterworfen werden. Dabei lassen sich allerdings keine allgemeingültigen Aussagen ableiten, denn die Höhe der Kosten für Qualitätssicherung hängt auch vom Anspruch an die Software und ihrem Einsatzgebiet ab. So muss ζ. B. ein höherer Maßstab angelegt werden, wenn durch den Softwareeinsatz eine Gefahrdung von Menschen möglich ist. 4.3.4.2 Einzelmaßnahmen Maßnahmen zur Qualitätssicherung lassen sich in organisatorische, konstruktive und analytische Maßnahmen unterteilen. Diese können phasenübergreifend oder phasenbezogen durchgeführt werden. 4.3.4.2.1 Phasenübergreifende Maßnahmen Zu den phasenübergreifenden Einzelmaßnahmen zur Qualitätssicherung zählen: 1. Analyse/Schätzung der Entwicklungszeit- und -kostenverteilung Anhand abgeschlossener Projekte wird ermittelt, welche zeitliche und sachliche Verteilung der Entwicklungskosten dort vorlag. Die Ergebnisse lassen sich zur Beurteilung der Effektivität der eigenen Qualitätssicherungsmaßnahmen verwenden. 2. Definierte Verantwortlichkeiten in Projekten Die Aufgabenbereiche müssen frühzeitig klar gegliedert und gegeneinander abgegrenzt werden. Dabei sollten die Aufgabenbereiche der einzelnen Mitarbeiter mit deren Kompetenz und Verantwortungsbereich übereinstimmen. Dies fordert die Identifikation mit der Aufgabe und damit auch die Motivation.

959

900

Vgl. SNEED, H.M.: Software-Qualitätssicherung für kommerzielle Anwendungssysteme, a.a.O., S. 46 ff. Vgl. BOEHM, B.W.: Wirtschaftliche Software-Produktion, a.a.O., S. 34 ff. und 328 ff.

4.3 Qualitätsmanagement von Software

405

3. Verwendung eines Phasenschemas als Überwachungsinstrument Aus der Sicht des Managements lassen sich durch die Verwendung eines Phasenmodells die einzelnen Entwicklungsabschnitte, bei denen es sich um überschaubare Intervalle handeln sollte, besser überwachen. Am Ende jeder Phase sollte ein fest definiertes und kontrolliertes Phasenergebnis stehen. Da Fehler frühzeitig entdeckt werden sollen, sind die Phasenergebnisse detailliert zu prüfen. Die Qualität der entwickelten Software setzt sich aus der Qualität der Phasenergebnisse zusammen. 4.3.4.2.2 Maßnahmen bei der Spezifikation

Die Qualitätssicherung hat hier die Aufgabe, zu prüfen, ob und inwieweit das erstellte Fachkonzept der ursprünglichen Aufgabenstellung gerecht wird. G. POMBERGER und G. BLASCHEK definieren als Ziel des Spezifikationstest, die Vollständigkeit, Klarheit, Konsistenz und Realisierbarkeit der Systemspezifikation zu prüfen.907 Zudem sind alle beschriebenen Funktionen und Informationsbeziehungen auf Aktualität, Notwendigkeit, Korrektheit und Plausibilität hin zu kontrollieren. Insbesondere sind drei Schwerpunkte zu bilden: 1. Konsistenzkontrolle der Funktionen/Daten Es muss geprüft werden, ob verwendete Funktionen/Daten logisch aufeinander aufbauen, vollständig die Anforderungen abdecken und nicht widersprüchlich sind. 2. Schnittstellen Da bei der Systemspezifikation die Benutzerschnittstellen definiert werden, ist es sinnvoll, wenn bereits in dieser Phase Bildschirmmasken in einer Form festgelegt werden können, die eine unveränderte Übernahme (ζ. B. mit einem Maskengenerator) für die Implementierungsphase erlauben. 3. Maskenaufbau Für den Maskenaufbau können ζ. B. DIN- oder Unternehmensrichtlinien bzw. betriebssystemspezifische Vorgaben verwendet werden.

961

Vgl.

POMBERGER, G . ; BLASCHEK, G . :

Software Engineering, a.a.O., S.

147.

406 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 4.3.4.2.3 Maßnahmen bei der Systemkonstruktion und -Implementierung In diesen Phasen lautet die zentrale Fragestellung: »Wie kann die Qualität der entworfenen und codierten Software beurteilt und beeinflusst werden?« Bei der Qualitätssicherung der Systemimplementierung gilt es »...festzustellen, ob ein Programm in sich richtig ist, das heißt widerspruchsfrei und vollständig (interne Konsistenz), und ob es das tut, was in seinen vorherigen Beschreibungen festgelegt wurde (externe Konsistenz).«9^ Zum Klären dieser Fragestellung bieten sich folgende zum Teil überschneidende Maßnahmen an: 1. Inspektionen Bei den Inspektionen wird die Problemspezifikation mit der konzipierten/ implementierten Software verglichen. Das Ziel ist, Abweichungen und Schwachstellen in den Mensch-Maschine-Schnittstellen aufzudecken und Performanceprobleme festzustellen.903 2. Reviews Mit Hilfe von Reviews wird versucht, Qualitätsschwachstellen zu ermitteln. Die Aufgabengebiete der Reviews liegen in der: - Analyse des Datenmodells auf Auswahl und Aufbau der verwendeten Datenstrukturen Dabei sind insbesondere die Wahl der Schlüssel, ihr Aufbau sowie die möglichen Wertebereiche der Daten von Bedeutung. - Prüfung der Modularisierung Hier erfolgt eine Prüfung, ob Strukturierungs- und Abstraktionsgrundsätze beachtet wurden. - Prüfung der Modulschnittstellen auf Vollständigkeit und Widerspruchsfreiheit - Kontrolle der eingesetzten Hilfsmittel Wie bereits erwähnt, bauen Softwareentwicklungssysteme auf Prinzipien des Softwareengineering auf. Der Einsatz von Konzepten, Methoden und Techniken gewährleistet, dass die damit erstellte Software bestimmten

9 6 2

HAUSEN, H . - L . ; MÜLLERBURG,

M.; SCHMIDT,

M.:

Über das Prüfen, Messen und Bewerten von

Software, a.a.O., S. 136. 963 YGJ COMMENTZ-WALTER, B . : Inspektionen aus der Sicht des Anwenders, in: KÖLSCH, R . ; SCHMID,

W.; SCHWEIGGERT,

F.

(Hrsg.): Wirtschaftsgut Software, Stuttgart

1985, S. 2 2 7 .

4.3 Qualitätsmanagement von Software

407

Prinzipien genügt, bzw., dass nicht gegen anerkannte Prinzipien verstoßen wird. Auch wenn sich Anwendungsprogramme stark voneinander unterscheiden, so sind sie i.d.R. doch in ihrer Grundstruktur sehr ähnlich. Dadurch ist es möglich, Programmierrichtlinien für - den generellen Programmaufbau, - die Maskenverarbeitung, - die Dateibearbeitung und - die Druckersteuerung aufzustellen. Im Rahmen von Reviews muss vom Entwicklungsmanagement weiterhin geprüft werden, ob der sinnvolle Einsatz von - Programmiertools (Programmgeneratoren), - Utilities, - Struktogrammgeneratoren, - usw. möglich ist. 3. Black-Box-Prüfung Die Black-Box-Prüfung oder funktionale Prüfung geht von vorgegebenen Eingaben aus und vergleicht die damit erzeugten Ergebnisse auf Korrektheit. Bei dieser Prüfung wird die Software ohne genaue Kenntnis der internen Abläufe untersucht. Grundlage für die Prüfung bilden das ablauffähige Programm und die Dokumentation. Die einzelnen in der Dokumentation beschriebenen Funktionen werden sukzessive auf Korrektheit und Vollständigkeit geprüft.904 4. White-Box-Prüfung Die Testaktivitäten der White-Box-Prüfung oder Strukturprüfung beziehen sich auf die Betrachtung der inneren Struktur des Testobjektes.905 Bei dieser aufwendigen Prüfungsmethode werden die einzelnen Quellcodezeilen innerhalb der Module untersucht. Als Hilfsmittel können Debug-Tools

964 v g l . PAPST, R.: Die Zuverlässigkeit von Software-Voraussetzungen für Softwareprüfung, in: KÖLSCH, R.; SCHMID, W.; SCHWEIGGERT, F. (Hrsg.): Wirtschaftsgut Software, Stuttgart 1985, S. 9 6 ( 9 5 - 1 0 5 ) . 965

Vgl. POMBERGER, G.; BLASCHEK, G.: Software Engineering, a.a.O., S. 152.

408 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung verwendet werden. Ein (interaktiver) Debugger ist ein Utility, das meist vom Betriebssystem- oder vom Programmiersystemanbieter zur Verfügung gestellt wird. Es bietet die Möglichkeit, am Bildschirm den Testablauf (Folge von Quellcode-Assemblerbefehlen) zu verfolgen und zu unterbrechen. Bei einer Unterbrechung kann dann z.B. der Feldinhalt von Variablen angezeigt werden. 5. Aufstellung von Testplänen Die Testpläne enthalten die Inhalte und die Ablauffolgen der einzelnen durchzuführenden Tests. Sie können allgemein oder auf ein bestimmtes Softwaresystem zugeschnitten sein. Beispielhaft könnten folgende Richtlinien zum Modultest aufgestellt werden: -

-

-

Test der Installationsprozedur Test der Sicherungsmechanismen (Datensicherung, Wiederherstellung des Datensystems nach Zerstörung, Wiederherstellung des Programmsystems nach Zerstörung) pro Datei sind mindestens drei Sätze anzulegen bei Eingabefeldern sind Grenzwerttests durchzuführen Die Mehrplatzfähigkeit muss durch konkurrierende Zugriffe mehrerer Nutzer im Erfassungs-, Änderungs- und Löschmodus nachgewiesen werden. Änderung der Testumgebung (z.B. Veränderung der Hardware, Wechsel des Betriebssystems)

4.3.4.3 Maßnahmen bei eingesetzter Software

Nicht nur bei der Neuentwicklung von Software muss die Softwarequalität sichergestellt werden. Auch die produktiv im Unternehmen eingesetzte Software soll den definierten Qualitätsanforderungen genügen. Daher sind Wartung und Pflege der Software ein wesentlicher Bestandteil des Softwareengineering.960 Insofern müssen sämtliche laufende Applikationen systematisch gewartet und im Einzelfall einem Reengineering unterzogen werden.

966

Vgl. GABRIEL, R.: Software Engineering, in: KURBEL, K.; STRUNZ, H. (Hrsg.): Handbuch Wirtschaftsinformatik, Stuttgart 1990, S. 262 (257-273).

4.3 Qualitätsmanagement von Software

409

4.3.4.3.1 Softwarewartung Unter Softwarewartung werden alle Arbeiten an einem Softwaresystem nach dessen erstem produktiven Einsatz, insbesondere Fehlerkorrektur, Optimierung, Änderung und Weiterentwicklung verstanden.967 Im Rahmen der Softwarewartung ist also sicherzustellen, dass die Software auf der zur Verfügung stehenden Hardware fehlerfrei und effizient läuft. Später erkannte Fehler im Programmcode sind sukzessive zu beseitigen und die erforderlichen Änderungen sind systematisch zu dokumentieren. Neben dieser, eher technischen Wartung, ist auch zu gewährleisten, dass die eingesetzte Software die sich ändernden Vorgaben (z.B. Veränderung der Betriebsstruktur, der Steuergesetze oder der Tarifverträge) und betrieblichen Prozessabläufe (z.B. Einführung einer neuen Produktionsstraße) zutreffend abbildet. Wird bspw. durch den Gesetzgeber zu einem Stichtag eine Steuerformel modifiziert, so muss auch in der davon betroffenen Software die Änderung stichtagsbezogen realisiert werden. Teilweise können individuelle Anpassungen durch den Anwender im Rahmen des Customizings der Standardsoftware selbst vorgenommen werden, ohne dass der Programmcode verändert werden muss. Umfangreiche Modifikationen, die eine Änderung des Quellcodes erfordern, werden bei Standardanwendungssoftware häufig durch den Softwarehersteller vorgenommen. Dieser liefert dann das sog. Update oder Release an den Anwender aus. Dazu ist es erforderlich, dass der Softwarenutzer mit dem Softwarehaus einen Wartungsvertrag abschließt. Probleme hierbei ergeben sich in der betrieblichen Praxis daraus, dass der Anwender Releasewechsel innerhalb vorgegebener Fristen vollziehen muss, da sonst der Anspruch auf Wartung erlischt, der jeweils nur für das aktuelle Softwarerelease bzw. den neuesten Korrekturstand besteht. Wird hingegen eine selbsterstellte Software eingesetzt, so ist i.d.R. der Quellcode durch den Softwareentwickler zu modifizieren. Um die Qualität der veränderten Software sicherzustellen, sollten die bereits vorgestellten Maßnahmen zur Qualitätssicherung systematisch durchlaufen werden, wobei gezielt nur der veränderte Bereich betrachtet wird. Allerdings ist auch auf die Konsistenz des Gesamtsystems zu achten.

967

Vgl. SNEED,H.M.; ROTHHARDT, G.: Software-Messung, a.a.O. S. 172.

410 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung 4.3.4.3.2 Softwarereengineering

Unter dem Begriff Reengineering werden alle Maßnahmen zusammengefasst, vorhandene Software zu sanieren, wobei die grundsätzliche Funktionalität unverändert bleibt. Dabei hängt die Möglichkeit zum Reengineering wesentlich davon ab, wie brauchbar die Entwicklungs- und Programmdokumentation sind. Für »Alt-Software«, die sich schon viele Jahre im Einsatz befindet, ist charakteristisch, dass -

die Dokumentation unübersichtlich, unvollständig, veraltet oder gar nicht mehr vorhanden ist und - die Programme nur selten klar strukturiert sind. 968 Das Reengineering lässt sich in drei Richtungen einteilen: Reverse Engineering, Restructuring (Restrukturierung) und Reuseability (Wiederverwendbarkeit).969 Beim Reverse Engineering werden die im Quellcode verborgenen Datenstrukturen sowie Kontrollstrukturen (Elemente der strukturierten Programmierung: Sequenz, Selektion, Iteration) aufgedeckt, ohne jedoch den Quellcode selbst zu verändern. S T A H L K N E C H T zählt zu den wesentlichen Bestandteilen des Reverse Engineering:970 - Redokumentation (Nachdokumentation): Nachträgliches Erstellen einer Programmdokumentation (im Sinne einer mit dem Programmtest vergleichbaren Programmanalyse), z.B. mit Hilfe von Programm-Analysatoren. - Redesign: Erstellen des System- bzw. Programmentwurfs aus dem Quellcode. - Respezifikation: Rekonstruieren der Anforderungsspezifikation aus dem System- bzw. Programmentwurf. Ein Teil der zur Konzeption eines ganzheitlichen Informationssystems erforderlichen Schritte wird also in umgekehrter Reihenfolge durchgeführt. Das Restructuring baut auf dem Reverse Engineering auf und umfasst die Transformation des Programms (oder des Programm- bzw. Systementwurfs) von einem unstrukturierten in einen strukturierten Zustand. Dazu werden bspw. Sprungbefehle durch Konstrukte der strukturierten Programmierung ersetzt. Spezialfälle dabei sind

968

Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 333 f.

9 6 9

V g l . SCHUMANN, M . ; SCHÜLE, H.; SCHUMANN, U . : E n t w i c k l u n g v o n A n w e n d u n g s s y s t e m e n ,

970

a.a.O., S. 213 f. Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 334.

4.3 Qualitätsmanagement von Software

411

-

die Reformatierung, durch die Programme lediglich lesbarer gestaltet werden (z.B. durch Einrücken von Zeilen oder Einfügen von Leerzeilen), und - die Modularisierung, mit der Programme in überschaubare Module zerlegt werden.977 Es kommt hierbei also zu einer Modifizierung des Quellcodes, ohne jedoch die Funktionalität des Softwaresystems zu verändern. Bei der Wiederverwendbarkeit wird versucht, einzelne Softwarekomponenten mit möglichst geringen Anpassungen in anderen Softwaresystemen einzusetzen. Da zum Wiederverwenden von Quellcode dessen Struktur bekannt sein muss und auch gewisse Mindestqualitätsansprüche an die wiederverwendeten Softwarekomponenten zu stellen sind, setzt die Wiederverwendbarkeit i.d.R. ein Reverse Engineering sowie eine Restrukturierung des Altsystems voraus.97^ In der Praxis werden seit einigen Jahren sog. CARE-Tools (Computer Aided Reengineering) zum Reengineering der vorhandenen Software eingesetzt.973 Diese Werkzeuge unterstützen u.a. die Restrukturierung, die Reformatierung und die Modularisierung bestehender Programme sowie die Redokumentation, z.B. durch Generierung von Programmablaufplänen und Struktogrammen aus dem Quellcode.974 4.3.5 Normen zum Qualitätsmanagement Im Bereich der Qualitätssicherung spielen nationale und internationale Normen traditionell eine große Rolle. Dabei werden Deutsche Normen vom DIN Deutschen Institut für Normung e.V. in Berlin herausgegeben. Zahlreiche Normen bestehen aus mehreren Teilen. Eine deutsche Norm, die einschließlich der Nummer mit der internationalen (ISO) oder einer europäischen (EN) Nummer identisch ist, trägt die offizielle Bezeichnung DIN ISO bzw. DIN EN.975 971 972

973

Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 334. V g l . SCHUMANN, M . ; SCHÜLE, H.; SCHUMANN, U . : E n t w i c k l u n g v o n A n w e n d u n g s s y s t e m e n ,

a.a.O., S. 214. Vgl. WEGMANN, B: DOMINO-CARE (Computer Aided Reverse Engineering) - Erfahrungen aus einem Pilotprojekt, in: Wirtschaftsinformatik. Vol 34, 2/1992, S. 147 (146-155). Eine Marktübersicht über CARE-Produkte liefern KRALLMANN, H.; WÖHRLE, G.: Marktübersicht C A R E - T o o l s , in: Wirtschaftsinformatikr.

974

V o l 3 4 , 2 / 1 9 9 2 , S. 1 8 1 - 1 8 9 ( 1 8 1 - 1 8 9 ) .

Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 336. 97 ·* Im folgenden wird aus dem Grunde der Lesbarkeit jeweils nur die Normenbezeichnung der höchsten Ebene genannt.

412 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung Es ist möglich, eine erstellte Software einer Qualitätsprüfung durch eine externe Instanz, einen unabhängigen und sachverständigen Dritten, zu unterziehen. Diese Prüfinstanz, bspw. der »Technische Überwachungsverein« (TÜV) oder die »Gütegemeinschaft Software e.V.« (GGS) vergeben dann, sofern alle Voraussetzungen erfüllt sind, ein Gütesiegel gemäß DIN-Norm für das geprüfte Softwareprodukt. Diese Produktzertifizierung hat jedoch in den letzten Jahren stark an Bedeutung verloren, da es wenig sinnvoll ist, eine einzelne Software zu zertifizieren, die eventuell schon nach kurzer Zeit in Form eines neuen Release wieder modifiziert wird. Insofern gewinnt die Prozesszertifizierung stark an Bedeutung. Dabei wird der Prozess der Softwareerstellung zertifiziert, nicht die Software selbst. Grundlage dieser Prozesszertifizierung bilden die im folgenden vorgestellten Normen ISO 8402 und ISO 9000 bis 9004. 4.3.5.1 Qualitätsmanagement gemäß ISO 8402 Um die Qualität der erstellten Software nachhaltig zu sichern, ist es erforderlich, ein »totales« Qualitätsmanagement im Unternehmen zu installieren, das durch ein Qualitätsmanagementsystem unterstützt wird. Im Rahmen dieses Qualitätsmanagements sind nicht nur geeignete Maßnahmen der Qualitätssicherung zu bestimmen. Zusätzlich muss deren Anwendung wie ein Projekt durch die Qualitätsplanung vorbereitet und durch die Qualitätslenkung überwacht und gesteuert werden. Zudem sollte die Effektivität der Maßnahmen durch eine Qualitätsverbesserung ständig gesteigert werden. Parallel dazu schreibt das Qualitätsmanagementsystem vor, wie die für die Durchführung von Qualitätssicherungsmaßnahmen erforderlichen Organisationsstrukturen, Verantwortlichkeiten, Arbeitsabläufe und Mittel (Personal, Sachmittel) festzulegen sind. 976 Die wesentlichen Begriffe des Qualitätsmanagements werden in ISO 8402 definiert. Bild 4-41 verdeutlicht den Zusammenhang im Überblick. Auf Basis der in ISO 8402 definierten Normen ist es möglich, im Unternehmen ein Total Quality Management (TQM) einzuführen. Dieses TQM sollte dabei nicht nur als ein Bestandteil des Unternehmensführungskonzeptes gesehen werden, sondern vielmehr als dominierendes Element.977 976 977

Vgl. STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 326. Vgl. DÖTTINGER, K . ; KLAIBER, E . : Realisierung eines wirksamen Qualitätsmanagementsystems im Sinne des Total Quality Managements, in: STAUSS, B. (Hrsg.): Qualitätsmanagement und Zertifizierung - Von DIN ISO 9000 zum Total-Quality-Management, Wiesbaden 1994, S. 2 5 8 ( 2 5 7 - 2 7 3 ) .

4.3 Qualitätsmanagement von Software

413

Die erfolgreiche Realisierung des TQM-Ansatzes ist eine Grundvoraussetzung für die Einführung eines wirksamen Qualitätsmanagementsystems, das TQM stellt gewissermaßen die Philosophie dar. Erst danach sollte ein zertifizierungsfahiges Qualitässicherungssystem nach ISO 9000 bis 9004 eingerichtet werden. 9 7 8

Bild 4-41: Begriffe des Qualitätsmanagements nach ISO 8402979

4.3.5.2 Zertifizierung gemäß ISO 9000 bis 9004 Gremien für eine Zertifizierung nach ISO 9000 bis 9004 sind bspw. der 1990 gegründete TÜV-CERT als gemeinsame Zertifizierungsstelle für Qualitätssicherungssysteme der Technischen Überwachungsvereine sowie die Deutsche Gesellschaft für Zertifizierung von Qualitätsmanagementsystemen mbH (DQS). 9Ä0 Dabei wird die Zertifizierung nach folgenden Normen vorgenommen:

978 Vgl. DÖTTINGER, K . ; KLAIBER, E.: Realisierung eines wirksamen Qualitätsmanagementsystems im Sinne des Total Quality Managements, a.a.O., S. 272 f. 979

STAHLKNECHT, P.: Einführung in die Wirtschaftsinformatik, a.a.O., S. 326.

980 YGI STAHLKNECHT, P.: Einfuhrung in die Wirtschaftsinformatik, a.a.O., S. 3 2 8 .

414 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung -

ISO 9000:

Qualitätsmanagement- und Qualitätssicherungsnormen Leitfaden zur Auswahl und Anwendung. - ISO 9001: Qualitätssicherungssysteme - Modell zur Darlegung der Qualitätssicherung in Design/Entwicklung, Produktion, Montage und Kundendienst. - ISO 9002: Qualitätssicherungssysteme - Modell zur Darlegung der Qualitätssicherung in Produktion und Montage. - ISO 9003: Qualitätssicherungssysteme - Modell zur Darlegung der Qualitätssicherung bei der Endprüfung. - ISO 9004: Qualitätsmanagement und Elemente eines Qualitätssicherungssystem - Leitfadens. Diese Normen sind zunächst sehr allgemein formuliert. Für die Entwicklung, Lieferung und Wartung von Software existiert jedoch ein Leitfaden ISO 9000-3, der seit 1992 als ISO 9000 Teil 3: »Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software« verfügbar ist. ps/ ISO 9000 Teil 3 kann damit als Zuschnitt von ISO 9001 auf die speziellen Belange der Software angesehen werden. Dieser Leitfaden schlägt Lenkungsund Prüfungsmethoden zur Erstellung von Software vor, welche die Forderungen des Abnehmers erfüllen soll. Es geht dabei primär um die Vorbeugung vor Softwarefehlern in allen Phasen der Entwicklung bis zur Wartung.9«2 Wesentliche Bestandteile von ISO 9000 Teil 3 sind: 983 - Kapitel 4: Qualitätssicherungssystem - Rahmen Dieses Kapitel regelt u.a. die Verantwortung der oberen Leitung, die Rahmenrichtlinien zur Gestaltung des Qualitätssicherungssystems, die Durchführung der internen Qualitätsaudits sowie die Durchführung von Korrekturmaßnahmen. - Kapitel 5: Qualitätssicherungssystem - Lebenszyklustätigkeiten Für jede einzelne Phase des Lebenszyklus existieren detaillierte Vorgaben, auch die Softwarewartung wird erfasst.

981

Vgl. DIN DEUTSCHES INSTITUT FÜR NORMUNG E.V. (Hrsg.): DIN ISO 9000 Teil 3: Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software, Berlin 1992. 982 v g i . PETRICK, K.: Auditierung und Zertifizierung von Qualitätsmanagementsystemen gemäß Normen DIN ISO 9000 bis 9004 mit Blick auf Europa, in: STAUSS, B. (Hrsg.): Qualitätsmanagement und Zertifizierung, Wiesbaden 1994., S. 97 f. (95-126). 983 Vgl. GRIESE, J.: Der Beitrag von ISO 9000 zur Software-Qualitätssicherung, in: Wirtschaftsinformatik: Vol. 35, 6/1993, S. 579 (575-585).

4.3 Qualitätsmanagement von Software

415

- Kapitel 6: Qualitätssicherungssystem - Unterstützende Tätigkeiten (phasenunabhängig) Hier werden u.a. die Dokumentationspflichten sowie das Konfigurationsmanagement und die Gestaltung von Schulungen festgelegt. Eine Zertifizierung gemäß ISO 9000 läuft typischerweise in vier Phasen ab:p

4.4 Serviceorientierter IT-Managementprozess (ITIL)

435

In Deutschland wurde 1991 das BSI (Bundesamt für Sicherheit in der Informationstechnik)7007 eingerichtet. Es handelt sich um eine Bundesbehörde, die beim Innenministerium angesiedelt ist und sich speziell um Fragen zur ITSicherheit in unserer Informationsgesellschaft kümmert. Das BSI ist eine unabhängige und neutrale Stelle und untersucht Sicherheitsrisiken bei Anwendern, formuliert Risiken und Gefahren und erarbeitet Lösungsstrategien. Vom BSI wurde ein umfangreiches IT-Grundschutzhandbuch (über 2900 Seiten) erarbeitet und in einer Studie der Zusammenhang zwischen ITIL und der Informationssicherheit dargestellt.7002 Während bei ITIL der Aufbau und die Prozesse, also die Abläufe im Vordergrund stehen, wird beim ITGrundschutzhandbuch großen Wert auf die Beschreibung von Maßnahmen und auf Umsetzungsaspekte gelegt. 4.4.4 Business Perspective Bei ITIL werden die Anforderungen an das Management im Teil ,Business Perspective" beschrieben. IT-Möglichkeiten sollten in geschäftliche Vorteile umgesetzt werden. Partnerschaften, Kundenbeziehungsmanagement, Outsourcing, Offshoring (Auslagern von IT-Aktivitäten in Länder mit niedrigeren Kosten), Insourcing, Assetmanagement oder Gebührenfestlegung sind Beispiele, mit denen man sich in diesem Bereich auseinandersetzt. Es gilt die IT-Dienste an den Geschäftsanforderungen auszurichten. Das nachfolgende Bild 4-50 zeigt die Wechselbeziehung zwischen Geschäftsprozessen, IT-Verfahren und IT-Services. Ändern sich einerseits Geschäftsprozesse, so hat dies zur Folge, dass Anforderungen an neue IT-Verfahren und IT-Services entstehen. Andererseits können auch technologische Entwicklungen zu neuen IT-Verfahren und besseren IT-Services führen, die dann wiederum die Geschäftsprozesse beeinflussen.

1001 Ygj

www.bsi.de

1002 V g l B S I : IT-Grundschutzhandbuch, 2004; Abruf am 7.3.2006 http://www.bsi.bund.de/gshb/deutsch/download/GSHB2004.pdf Vgl. BSI: ITIL und Informationssicherheit; 2005; Abruf am 7.3.2006 http://www.bsi.bund.de/literat/studien/ITinf7itil.pdf

436 4 Sichtenübergreifende Prinzipien und Vorgehensweisen der Softwareentwicklung

Änderungen

Änderungen

Änderungen

Bild 4-50: Wechselbeziehungen bei der Steuerung von Geschäftszielen

4.4.5 Application Management Beim Application Management wird der gesamte Lebenszyklus einer Applikation betrachtet. Dieser umfasst neben der Entwicklungsphase auch die Nutzungs- und Aussonderungsphase. Dadurch entsteht ein Zyklus zwischen der Entwicklung (Applikation Development Phasen) und den Service Management Phasen, wie sie in Bild 4-51 dargestellt werden.

4.4 Serviceorientierter IT-Managementprozess (ITIL)

r» Requirements

Optimise

—

—