Zusammenfassung
Die benötigten Begriffe zur Diskussion von Vorgehensmodellen wurden in Kapitel 2.3.1 eingeführt. Für die folgenden Darstellungen sind die Begriffe Phase, Sprache, Dokument und Person von zentraler Bedeutung. Sie werden in der ERM-Notation als Metamodell wie in Abbildung 54 dargestellt angeordnet.1 Die vier Begriffe werden als Grundbegriffe in das Modell aufgenommen und entsprechend als Entitytypen dargestellt. Phasen können Phasenfolgen definieren, was durch den entsprechenden rekursiven Relationshiptypen ausgedrückt wird. Die (0,n):(0,n)-Kardinalitäten legen fest, daß jede Phase mehrere direkte Nachfolger und Vorgänger haben kann. Dokumente werden in Phasen als Input verwendet und von Phasen als Output produziert. In das Modell werden beide Fälle getrennt in Form der Relationshiptypen Dokument wird produziert in Phase und Dokument wird verwendet in Phase aufgenommen. Die (0,l):(l,n)-Kardinalitäten des ersten Relationshiptypen sind aus Sicht des Dokuments zu lesen. Sie legen fest, daß ein Dokument existieren kann, ohne in einer Phase produziert zu werden. Dies ist beispielsweise bei Dokumenten der Fall, die im Rahmen einer Ist-Analyse gesammelt werden, um darauf aufbauend das entsprechende Analysedokument zu erstellen. Falls Dokumente jedoch durch die Tätigkeiten in einer Phase produziert werden, muß die entsprechende Zuordnung zu einer Phase immer eindeutig sein. Aus Sicht der Phase gilt, daß jede Phase wenigstens ein Dokument produzieren muß. Bezüglich des zweiten Relationshiptypen gilt, daß jedes Dokument, das im Rahmen der Entwicklung betrachtet oder produziert wird, in wenigstens einer Phase verwendet werden muß und daß jede Phase wenigstens ein Dokument verwenden muß. Dies wird durch die (l,n):(l,n)-Kardinalitäten ausgedrückt. Der betriebliche Einsatz eines Systems ist in diesem Sinne als Phase zu begreifen. Alle Dokumentationen des Systems stellen Dokumente im hier verstandenen Sinne dar. Außerdem dienen die (zu dokumentierenden) Erfahrungen, die während der Betriebsphase gemacht werden, als Grundlage für die Weiterentwicklung und Fehlerbeseitigung des Systems.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsPreview
Unable to display preview. Download preview PDF.
Literatur
Vgl. zum folgenden Holten et al. (Vergleich) (1997), S. 259 ff.; Holten et al. (Entwicklung) (1997), S. 4 ff. In dem dargestellten Metamodell werden Aktivitäten des Projektmanagements nicht berücksichtigt. Entsprechend fehlen Komponenten zur Charakterisierung von Ressourcen und Ressourcenverbräuchen.
Vgl. Holten et al. (Vergleich) (1997), S. 260; Holten et al. (Entwicklung) (1997), S. 6.
Vgl. Fritz (1993), S. 333; Meyer (1994), S. 65-115; Horváth (1996), S. 555; Gabriel, Gluchowski (1997), S. 22 f. Da in dieser Arbeit fachkonzeptuelle Überlegungen im Vordergrund stehen, wird auf Angaben zu den Integratoren, insbesondere die Quellen der in das FIS aufzunehmenden Daten, nicht eingegangen.
Die Angaben zu den Berichtserstellern stellen Stammdaten eines Berichtes dar. Sie können nicht unter den Begriff Aufgabeträger des Aufgaben-Clusters gefaßt werden, da dieser Begriff die Träger von Regelungsaufgaben im Sinne des Modells des Lebensfähigen Systems abdeckt. Zur sauberen Erfassung der Erstellerdaten für die Berichte und zur Definition eines Datenbankschemas in der 3. Normalform, sind weitere Begriffe, nämlich ein Entitytyp Berichtsersteller und ein Relationshiptyp B-E-Zuo, zur Abbildung der Zuordnung von Berichtserstellern zu Berichten, mit den Kardinalitäten (l,l):(l,n) aus Sicht des Berichtes erforderlich. Gemäß dieser Kardinalitäten ist der Ersteller eines Berichtes immer eindeutig definiert. Jeder Ersteller kann aber mehrere Berichte erstellen. Diese Zusammenhänge werden hier nicht als ERM dargestellt, da die fachkonzeptuelle Spezifikation des Führungsinformationssystems im Sinne der Erstellung des Soll-Konzeptes im Vordergrund steht.
Zusätzlich ist für die Erfassung der Ist-Daten ein Relationshiptyp zwischen dem umdefinierten Relations-hiptypen BO-Fakt und dem Entitytyp Bericht erforderlich. Die Kardinalitäten dieses neuen Relationship-typs werden als (l,n):(l,n) definiert.
Vgl. zum Begriff Repository die Ausführungen in Abschnitt 6.2.1.
Dimensions-Bezugsobjekte selbst werden auch anhand ihrer Koordinaten als Elemente des Begriffs Kombiniertes-Bezugsobjekt dargestellt. Die entsprechende Spezialisierung des Begriffs Bezugsobjekt im Bezugsobjekt-Cluster des Metamodells ist daher als nicht-disjunkt, total definiert (vgl. Abschnitt 4.2.5).
Der angegebene Algorithmus soll lediglich verdeutlichen, wie die Bestimmung der Menge aller Bezugsobjekte eines Führungsinformationssystems unter Verwendung der hier definierten Begriffe automatisiert werden kann. Für alle im Rahmen dieser Arbeit betrachteten Algorithmen gilt, daß komplexitätstheoretische Überlegungen, die insbesondere die Laufzeit oder den für die Berechnung erforderlichen Speicher betreffen, gänzlich ausgeklammert werden. Hinweise zu diesem in der Informatik gut untersuchten Gebiet finden sich bei Knuth (Fundamental) (1973), S. 94 ff.; Knuth (Sorting) (1973), S. 170, S. 179 ff., S. 304 ff., S. 357 ff., S. 371 ff., S. 386 ff., S. 433 ff., S. 532 ff; Wirth (1986); Sedgewick (1992). Die Algorithmen in dieser Arbeit sollen lediglich die Umsetzbarkeit der vorgeschlagenen Methode zur FIS-Entwicklung demonstrieren. Sie werden angegeben, um zu zeigen, wie die zum Teil sehr abstrakten Ausführungen opera-tionalisiert werden können. Der Verständlichkeit für eine Operationalisierung wird bei der Darstellung Vorrang vor komplexitätstheoretischen Überlegungen eingeräumt. Zu allen hier algorithmisch betrachteten Handlungsanweisungen sind in der Literatur effiziente Standard-Algorithmen bekannt.
Vgl. Wedekind (1981), S. 144.
Vgl. Wedekind (1981), S. 142.
Vgl. Wedekind (1981), S. 142.
Vgl. Wedekind (1981), S. 140 ff.
Wedekind (1981), S. 140. Mit Hervorhebung des Originals.
Vgl. Wedekind (1981), S. 140.
Vgl. Wedekind (1981), S. 140, S. 144.
Vgl. Wedekind (1981), S. 140. Vgl. die Ausführungen zur Orthosprache in Fußnote 52 in Kapitel 2.3.1.
In der Literatur werden Struktogramme zum Entwurf der Anweisungen von Modulen (vgl. Nassi, Shnei-derman (1973); Schönthaler, Németh (1990), S. 225) und der Ansatz der Strukturierten Programmierung (vgl. Dijkstra (1967)) diskutiert. Die hier vorgeschlagene Technik wird für die Darstellung von Algorithmen auf der Fachkonzeptebene als geeigneter empfunden. Sie lehnt sich an den zur Darstellung von Mini-Specifications häufig verwendeten Pseudocode (vgl. Schönthaler, Németh (1990), S. 219) an. Pseudocode wird jedoch üblicherweise zur Spezifikation von Programmfunktionen auf der Implementierungsebene verwendet.
Die Einführung der Hilfsprozeduren ist als Konstruktion komplexer Anweisungen zu verstehen.
Als Basis-Kennzahlen werden im folgenden solche Kennzahlen bezeichnet, die aus Sicht des FIS nicht anhand einer Formel zu berechnen sind sondern als Basis-Bausteine gegeben sind. Sie dienen als grundlegende Elemente der Berechnung weiterer Kennzahlen (berechnete Kennzahlen).
Vgl. zur Definition adressatenspezifischer Berichte und deren Instantiierung die Ausführungen in Abschnitt 6.1.7.
Die Informationsbasis ist aus fachkonzeptueller Sicht zu verstehen als die Gesamtheit aller Fakten bzw. Informationsobjekte.
Vgl. die Ausführungen in Kapitel 4.3.1.
Vgl. zum Begriff der Aggregation die Ausführungen in Kapitel 4.3.2.
Die Tätigkeiten sind jedoch für die Entwicklung eines FIS zwingend notwendig.
Vgl. zur FIS-Architektur die Ausführungen in Abschnitt 3.1.6.
Vgl. zur Einzelwertphilosophie Riebels die Ausführungen in Kapitel 4.3.1.
Relationshiptypen, die der reinen Zuordnung verschiedener Entitytypen dienen, werden im folgenden der Übersichtlichkeit wegen nicht mit aufgezählt. Bei Bedarf wird im weiteren Verlauf auf diese Begriffe explizit verwiesen.
System 5 ist für die FIS-Gestaltung von nachrangiger Bedeutung. Vgl. die Ausführungen in Kapitel 5.3.5.
Es wird hier unterstellt, daß es jeweils genau eine Instanz für jede Klasse von Regelungsaufgaben für jede Management Unit gibt. Auf dieser Annahme basieren die Algorithmen zur Generierung der Informationskanäle. Falls dies nicht gesichert werden kann, müssen zur Anwendbarkeit der folgenden Algorithmen weitere Unterklassen der Regelungsaufgaben definiert werden, die eine Eindeutigkeit für die zu generierenden Informationskanäle in der benötigten Form sicherstellen.
Vgl. die Ausführungen in Abschnitt 6.1.3.
Vgl. die Ausführungen in Abschnitt 5.3.5, insbesondere Tabelle 2.
Vgl. zu den Anfragearten die Ausführungen in den Kapitelen 3.1.2 und 3.1.5.1.
Vgl. Eicker (1991), S. 3 f.; Eicker (1994), S. 9 ff.
Vgl. Chen (1995), S. 39; Haid, Weber (1991), S. 56; Mucksch et al. (1996), S. 426; Ljubojevic (1991), S. 36.; Dechent (1991), S. 71; von Stülpnagel (1991), S. 11.
Vgl. Eicker (1994), S. 9, S. 17; Eicker (1991), S. 3 f.; von Stülpnagel (1991), S. 11.
Vgl. von Stülpnagel (1991), S. 11. Repositories werden in diesem Zusammenhang als eine Zusammenfassung von Data-Dictionary-Systemen, CASE-Enzyklopädien und Bibliothekssystemen zur Dokumentation bezeichnet (vgl. von Stülpnagel (1991), S. 11). Data-Dictionary-Systeme sind Verzeichnisse über alle zur Verfügung stehenden Daten des Datenbanksystems (vgl. Biethan, Mucksch, Ruf (1996), S. 67). Vgl. zu Ursprung und Zweck der Data Dictionaries Habermann, Leymann (1993), insbesondere S. 15-20.
Vgl.Hofinger(1991),S.47.
Ein FIS-Repository fördert ebenfalls die Durchsetzung vereinheitlichter und standardisierter Begriffe, die ein wesentliches Instrument zur Vermeidung von Mißverständnissen darstellt (vgl. Eicker (1994), S. 20; Seitz, Seidl (1993), S. 137; Kaske (1992), S. 46 f.).
Vgl. Chen (1995), S. 37 f.
Der IRDS wurde 1988 als Standard der Ansi mit der Referenznummer X3.138 verabschiedet (vgl. von Stülpnagel (1991), S. 20). Einen Alternativvorschlag zur Darstellung der Modellierungsebenen von Repositories unterbreitete die ISO (vgl. ISO 1990). Den Vorschlag der ISO diskutieren Habermann, Leymann (1993), S. 77 ff.
Vgl. Chen (1995), S. 42; von Stülpnagel (1991), S. 20.
Die Bezeichnung der logischen Ebenen wird in Quellen, die sich an die Ebenen des IRDS anlehnen in der Regel ohne eine differenzierte Unterscheidung der Prinzipien der Metaisierung oder der modellierten Aspekte (Dokumente versus Prozesse) eingeführt. Vgl. beispielsweise Chen (1995), S. 42; von Stülpnagel (1991), S. 21; Nauer (1991), S. 28; Hbermann, Leymann (1993), S. 77 f.; Pohl (1996), S. 78 ff.
Repository-Objekte werden häufig unter Verwendung der Sprache ERM dargestellt (vgl. Haid, Webere (1991), S. 56; von Stülpnagel (1991), S. 14 f.; Chen (1995), S. 42).
Diese Ebene wird in der Literatur teilweise unglücklich als Informationsmodell bezeichnet (vgl. von Stülpnagel (1991), S. 18 f.; Hofinger (1991), S. 50). Diese Begriffsbildung wird hier abgelehnt, da mit Informationsmodell unabhängig von der relativen Ordnung logischer Modellierungsebenen die Modelle der fachkonzeptuellen Beschreibung von Informationssystemen im Rahmen der Unternehmensmodellierung bezeichnet werden (vgl. Becker, Schütte (1996), S. 20).
Vgl. die Ausführungen in Abschnitt 6.1.1.
Verwendet werden für diese Alternative Produkte, deren Schnittstellen-Standardisierung in ausreichendem Maße dokumentiert ist (vgl. zu OLE DB for OLAP: Microsoft (1998); zum SQL Server 7.0 Parkes (1998)).
Die Ergebnisse zu dieser Realisierungsalternative eines FIS-Repository-Prototypen sind bei Püttmann (1998) dokumentiert. Aufgrund der Standardisierungsbemühungen der Softwarehersteller stehen dieser Alternative keine prinzipiellen Probleme entgegen.
Die Integration des Meta-FIS wird mit der Standardsoftware NA VISION Financials realisiert (vgl. Müller (1998), S. 65-92). Vgl. zu NAVISION Financials Adolphi (1997); Uerkevitz (1997).
Die Ergebnisse zu dieser Realisierungsalternative eines FIS-Repositories sind bei Müller (1998) dokumentiert. Zur Entwicklung der FIS-Informationsbasis wird die SIF-Technologie von NAVISION verwendet (vgl. zur SIFT von NAVISION Adolphi (1997), S. 42; Uerkvitz (1997), S. 14).
Vgl. zum Star-Schema beispielsweise Inmon et al. (Manageing) (1997), S. 213 ff.
Rights and permissions
Copyright information
© 1999 Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden
About this chapter
Cite this chapter
Holten, R. (1999). Vorgehensmodell zur Entwicklung von Führungsinformationssystemen und Toolsupport. In: Entwicklung von Führungsinformationssystemen. Informationsmanagement und Controlling. Deutscher Universitätsverlag. https://doi.org/10.1007/978-3-322-92349-3_6
Download citation
DOI: https://doi.org/10.1007/978-3-322-92349-3_6
Publisher Name: Deutscher Universitätsverlag
Print ISBN: 978-3-8244-6950-5
Online ISBN: 978-3-322-92349-3
eBook Packages: Springer Book Archive