DOI Artikel:
Wahl, Hendrik: Prozeß und Bild
DOI Seite / Zitierlink: https://doi.org/10.11588/diglit.31840#0216
figurierbarkeit und Anpaßbarkeit an einen
beliebigen Einsatzzweck genannt. Als ein sehr
wichtiger Punkt in der Produktdarstellung
wurde das Aufzeigen von Referenzen ange-
sehen.
Erklärungsmodelle
(Nutzergruppen und Traditionen)
Schwieriger als das Festlegen von inhaltlichen
Anforderungen gestaltete sich der Umgang
mit der Struktur des Softwareproduktes. Die
Analyse der Produktbeschreibungen und
Handbücher zeigte nämlich, daß es kein
durchgängiges logisches Erklärungsmodell,
weder für die Gesamtstruktur noch für Teil-
bereiche des Softwarepaketes gibt, sondern
daß mehrere Beschreibungen parallel und
weitgehend unabhängig voneinander existie-
ren. Jede für sich repräsentiert die Nutzer-
und Denktraditionen der jeweiligen Spezia-
listen, die sich mit bestimmten Aspekten des
Produktes beschäftigen.
Das umfangreichste und am klarsten struk-
turierte Erklärungsmodell beschreibt den
modularen Aufbau der Softwarestruktur, die
aus sogenannten Grundmodulen besteht.
Jedes dieser Grundmodule für sich ist zur
Lösung von Teilaufgaben bestimmt. So gibt
es Basismodule, die zur Stammdatenverwal-
tung, Tabellenverwaltung und Herstellungs-
kostenberechnung dienen, Module, die die
verschiedenen Prozeduren bei der Prozeß-
und Produktionsplanung übernehmen, wie
zum Beispiel Chargen-, Stücklisten- und
Arbeitsplanverwaltung, finanztechnische
Module, die Funktionen wie Haupt-, Kredi-
toren- und Debitorenbuchhaltung sowie
Kostenstellenrechnung realisieren, Projekt-
verwaltungs- und transportlogistische Modu-
le, die oder deren Implementierungsfunk-
tionen miteinander teilweise oder vollstän-
dig kombiniert globale Prozesse in einem In-
dustrieunternehmen simulieren können und
so die Basis für eine genaue Planung im Un-
ternehmen bilden. Jedes Modul verfügt über
eine Anzahl von Implementierungs-
funktionen, die wie Subsysteme funktionie-
ren und zur Lösung bestimmter Aufgaben
benötigt werden .
Aber nicht nur die Primärfunktionen der Soft-
ware werden durch Module gewährleistet,
sondern die Struktur und Erscheinungsweise
der Software selber kann mit Hilfe spezieller
Module verändert werden. So können eige-
ne Masken erstellt werden, Prozeduren an-
gepaßt und Datenbanken konfiguriert wer-
den. Der vollständig modulare Aufbau der
hier vorliegenden Software erlaubt es, die
Funktionen ständig optimal an die Bedürf-
nisse der Produktion anzupassen. Es ist mög-
lich, die Software optimal zu konfigurieren
und sie bei einer Veränderung der Einsatz-
anforderungen schnell zu rekonfigurieren,
um ständig eine optimale Anpassung an den
Produktionsprozeß zu gewährleisten.
Das zweite Erklärungsmodell setzt bei den
Denktraditionen der „Entscheidungsträger"
an. Es ist das sogenannte Baukastenmodell.
Hier wird eine Struktur gezeigt, die von vor-
strukturierten Anwenderpaketen ausgeht,
die globale Problemlösungen in Unterneh-
men oder Teilbereichen darstellen. So gibt es
die Baukästen Industrie, Handel, Transport
und Rechnungswesen. Jeder dieser Baukä-
sten enthält eine Anzahl von vorkonfigu-
rierten Grundmodulen und stellt eine funk-
tionierende Komplettlösung für den entspre-
chenden Einsatzzweck dar, kann aber auch
mit anderen Baukästen kombiniert werden.
So ist der Anpassungsaufwand an Standard-
anforderungen geringer als bei einer kom-
pletten Neukonfigurierung.
Es gibt noch einen weiteren baukasten-
ähnlichen Komplex, der sich Tools nennt.Der
Komplex Tools besteht aus einer Anzahl von
Grundmodulen, die so strukturiert und kon-
figuriert sind, daß mit diesem Baukasten,
oder besser Werkzeugkasten, generelle Ver-
änderungen und Anpassungen im Software-
system vorgenommen werden können.
Während das Modulmodell von System-
administratoren und Softwarespezialisten
entwickelt worden ist und sich von seiner
Struktur an eine solches Klientel wendet, ist
das Baukastenmodell eher im Bereich des
Marketing verwurzelt und zeigt ein Bild, das
sich an Kaufleute und Marketingspezialisten
wendet. Dieses Erklärungsmodell istderVer-
such, die logischen Strukturen des Modul-
modells zu vereinfachen und auf die Ebene
des Managements zu projizieren. Dies gelingt
aber nur unvollständig, da, um das Erklä-
214
beliebigen Einsatzzweck genannt. Als ein sehr
wichtiger Punkt in der Produktdarstellung
wurde das Aufzeigen von Referenzen ange-
sehen.
Erklärungsmodelle
(Nutzergruppen und Traditionen)
Schwieriger als das Festlegen von inhaltlichen
Anforderungen gestaltete sich der Umgang
mit der Struktur des Softwareproduktes. Die
Analyse der Produktbeschreibungen und
Handbücher zeigte nämlich, daß es kein
durchgängiges logisches Erklärungsmodell,
weder für die Gesamtstruktur noch für Teil-
bereiche des Softwarepaketes gibt, sondern
daß mehrere Beschreibungen parallel und
weitgehend unabhängig voneinander existie-
ren. Jede für sich repräsentiert die Nutzer-
und Denktraditionen der jeweiligen Spezia-
listen, die sich mit bestimmten Aspekten des
Produktes beschäftigen.
Das umfangreichste und am klarsten struk-
turierte Erklärungsmodell beschreibt den
modularen Aufbau der Softwarestruktur, die
aus sogenannten Grundmodulen besteht.
Jedes dieser Grundmodule für sich ist zur
Lösung von Teilaufgaben bestimmt. So gibt
es Basismodule, die zur Stammdatenverwal-
tung, Tabellenverwaltung und Herstellungs-
kostenberechnung dienen, Module, die die
verschiedenen Prozeduren bei der Prozeß-
und Produktionsplanung übernehmen, wie
zum Beispiel Chargen-, Stücklisten- und
Arbeitsplanverwaltung, finanztechnische
Module, die Funktionen wie Haupt-, Kredi-
toren- und Debitorenbuchhaltung sowie
Kostenstellenrechnung realisieren, Projekt-
verwaltungs- und transportlogistische Modu-
le, die oder deren Implementierungsfunk-
tionen miteinander teilweise oder vollstän-
dig kombiniert globale Prozesse in einem In-
dustrieunternehmen simulieren können und
so die Basis für eine genaue Planung im Un-
ternehmen bilden. Jedes Modul verfügt über
eine Anzahl von Implementierungs-
funktionen, die wie Subsysteme funktionie-
ren und zur Lösung bestimmter Aufgaben
benötigt werden .
Aber nicht nur die Primärfunktionen der Soft-
ware werden durch Module gewährleistet,
sondern die Struktur und Erscheinungsweise
der Software selber kann mit Hilfe spezieller
Module verändert werden. So können eige-
ne Masken erstellt werden, Prozeduren an-
gepaßt und Datenbanken konfiguriert wer-
den. Der vollständig modulare Aufbau der
hier vorliegenden Software erlaubt es, die
Funktionen ständig optimal an die Bedürf-
nisse der Produktion anzupassen. Es ist mög-
lich, die Software optimal zu konfigurieren
und sie bei einer Veränderung der Einsatz-
anforderungen schnell zu rekonfigurieren,
um ständig eine optimale Anpassung an den
Produktionsprozeß zu gewährleisten.
Das zweite Erklärungsmodell setzt bei den
Denktraditionen der „Entscheidungsträger"
an. Es ist das sogenannte Baukastenmodell.
Hier wird eine Struktur gezeigt, die von vor-
strukturierten Anwenderpaketen ausgeht,
die globale Problemlösungen in Unterneh-
men oder Teilbereichen darstellen. So gibt es
die Baukästen Industrie, Handel, Transport
und Rechnungswesen. Jeder dieser Baukä-
sten enthält eine Anzahl von vorkonfigu-
rierten Grundmodulen und stellt eine funk-
tionierende Komplettlösung für den entspre-
chenden Einsatzzweck dar, kann aber auch
mit anderen Baukästen kombiniert werden.
So ist der Anpassungsaufwand an Standard-
anforderungen geringer als bei einer kom-
pletten Neukonfigurierung.
Es gibt noch einen weiteren baukasten-
ähnlichen Komplex, der sich Tools nennt.Der
Komplex Tools besteht aus einer Anzahl von
Grundmodulen, die so strukturiert und kon-
figuriert sind, daß mit diesem Baukasten,
oder besser Werkzeugkasten, generelle Ver-
änderungen und Anpassungen im Software-
system vorgenommen werden können.
Während das Modulmodell von System-
administratoren und Softwarespezialisten
entwickelt worden ist und sich von seiner
Struktur an eine solches Klientel wendet, ist
das Baukastenmodell eher im Bereich des
Marketing verwurzelt und zeigt ein Bild, das
sich an Kaufleute und Marketingspezialisten
wendet. Dieses Erklärungsmodell istderVer-
such, die logischen Strukturen des Modul-
modells zu vereinfachen und auf die Ebene
des Managements zu projizieren. Dies gelingt
aber nur unvollständig, da, um das Erklä-
214