Entwicklung computergestützter Werkzeuge kommt nicht voran

Die Software-Entwicklung ist auf bessere Methoden angewiesen

08.03.1991

In den letzten 20 Jahren ist eine Vielzahl von Methoden zur Unterstützung des Software-Entwicklungs-Prozesses entstanden. Diese Vielzahl hat zu einer hohen Unübersichtlichkeit geführt und die Entwicklung von computergestützten Werkzeugen eher behindert. Deshalb besteht das Bestreben, so August-Wilhelm Scheer* eine Methodologie (Lehre von den Methoden) für die Entwicklungsmethoden in Angriff zu nehmen.

Typische Fragen, die eine Methodologie als Rahmenkonzept beantworten helfen soll, sind:

1. Gibt es wirklich so viele grundsätzlich unterschiedliche Wege, um ein computergestütztes Informationssystem zu entwerfen?

2. Wenn nicht, wie ähnlich sind diese Wege, wenn ja, warum sind die Wege so unterschiedlich?

3. Gibt es einen besten Weg, um ein Informationssystem zu entwickeln?

4. Wo beginnt der Entwicklungsprozeß und wo endet er?

5. Wie sieht das Endprodukt eines Design-Prozesses aus?

6. Wieviel Stufen sind erforderlich, um ein Entwicklungsergebnis zu erreichen?

7. Soll lediglich eine Methodologie für eine bestimmte Art von Informationssystemen eingesetzt werden oder sind mehrere Methoden für unterschiedliche Systeme notwendig? Wenn ja, nach welchen Kriterien sollen die einzusetzenden Methoden ausgewählt werden?

Neben der Beantwortung dieser Fragen, deren Zielsetzung die Einordbarkeit und Bewertung von Methoden ist, gibt es eine weitere Gruppe von Gründen, sich mit ISDN (Information System Design Methodologies) zu beschäftigen. Diese Gründe resultieren aus dem Tatbestand, daß an komplexen Entwicklungsprojekten in der Regel mehrere Partner beteiligt sind, die unterschiedliche Entwicklungsmethoden einsetzen können und deren Arbeitsergebnisse sich überlappen.

Hier kann nur ein Rahmenkonzept, in das sich die unterschiedlichen Methoden einordnen lassen und somit ihre Übereinstimmungen und Unterschiedlichkeiten zeigen, zu einem gegenseitigem Verstehen führen. Daß darüber hinaus ein solches Rahmenkonzept auch zu einer Vereinheitlichung des Methodeneinsatzes führen kann und soll, liegt nahe.

Gerade betriebswirtschaftliche computergestützte Informationssysteme zeichnen sich zunehmend durch einen hohen

Komplexitätsgrad aus. Durch die integrierte Datenverarbeitung, bei der die gemeinsame Nutzung von Daten durch verschiedene Anwendungen unterstützt wird, sowie die Realisierung umfassender EDV-orientierter Gesamtkonzepte für Unternehmungen (CIM für Industriebetriebe, EDV-gestützte Warenwirtschaftssysteme für Handelsbetriebe, Electronic Banking für Bankbetriebe) sind viele interne und externe Partner an der Entwicklung eines Informationssystems beteiligt. Um eine abgestimmte arbeitsteilige Realisierung solcher Projekte zu ermöglichen, ist ein Rahmenkonzept oder eine Architektur erforderlich.

Unter Architektur wird allgemein die Baukunst verstanden. Im übertragenen Sinne auf Informationssysteme bezogen bedeutet dieses, daß die einzelnen Bausteine, aus denen ein Informationssystem besteht, hinsichtlich ihrer

- Art,

- funktionalen Eigenschaften und

- ihres Zusammenwirkens beschrieben werden müssen.

Die Übertragung des Begriffes Architektur auf Konzepte der Informationsverarbeitung ist gebräuchlich. Hier werden mit dem Begriff Architektur Begriffe wie Planung, Verfolgung von Regeln, Strukturierung oder Koordination mehrerer Partner assoziiert, die Problemen von Informationssystemen entsprechen.

Neben dem Teil der Architektur, der die Komponenten und ihre Zusammenwirkungen definiert, also das "Was" der Beschreibung eines Informationssystems festlegt, ist auch das "Wie, also das Vorgehensmodell zur Erstellung eines Informationssystems, zu bestimmen.

Eine Architektur für Informationssysteme ermöglicht den leichteren Einsatz von Werkzeugen zur Automatisierung des Entwicklungsprozesses. Es ist allgemein bekannt, daß die Entwicklung großer Softwaresysteme mit erheblichen Kosten und Risiken verbunden ist. Es werden deshalb Anstrengungen unternommen, durch Entwicklung umfassender Werkzeuge die Softwareproduktion zu automatisieren.

Viele der gegenwärtig gebräuchlichen Methoden zur Entwicklung von Informationssystemen entstammen eher empirischen Erkenntnissen als theoretischen Konzeptionen. Auch einige Ansätze zur Bildung einer Methodologie versuchen eher, die bestehenden Methoden in ein Rahmenkonzept zu integrieren als die Methodologie theoretisch abzuleiten.

Aus diesem Grunde wird im folgenden die Architektur integrierter betriebswirtschaftlicher Informationssysteme aus einem allgemeinen betriebswirtschaftlichen Vorgangskettenmodell abgeleitet.

Die Betonung des betriebswirtschaftlichen Anwendungshintergrundes bedeutet keine allzugroße Einschränkung. Sie betont die hohe Bedeutung des Integrationsgedankens von Informationssystemen, wie er bei betriebswirtschaftlichen Anwendungen typisch ist. Die entwickelte Architektur integrierter Informationssysteme (Aris) sollte deshalb durchaus als allgemeingültiger Vorschlag verstanden werden.

Die Aris-Architektur bildet den Rahmen, in dem integrierte Anwendungssysteme entwickelt, optimiert und in die EDV-technische Realisierung umgesetzt werden können. Sie zeigt damit gleichzeitig der Betriebswirtschaftslehre, wie sie Informationssysteme betrachten und analysieren kann, um eine EDV-gerechte Umsetzung ihrer Inhalte zu erreichen.

I. Vorgangskettenmodell als Ausgang der Architekturentwicklung Wesentlicher Unterstützungsgegenstand betriebswirtschaftlicher Informationssysteme sind Vorgangsketten. Beispiele für Vorgangsketten sind eine geschlossene Auftragsbearbeitung von der Auftragsannahme über Materialwirtschaft, Produktion bis zum Versand oder die Entwicklung eines Produktes von der ersten Idee bis zur Übergabe des ausgetesteten Produktes an die Produktion.

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 Beginn und Ende des Vorgangs (vergleiche Abbildung 1).

Gegenstand der Vorgangsbearbeitung kann die Transformation eingesetzter Werkstoffe zu Produkten (ausgehenden Werkstoffen) sein. Hierzu sind als weitere Produktionsfaktoren entsprechend der Produktionstheorie nach Gutenberg der Einsatz menschlicher Arbeitsleistung sowie Betriebsmittel in Form von Produktionsmaschinen oder Geräten der Informationstechnologie notwendig. Die Regeln der Kombination der Elementarfaktoren wird in Bearbeitungsregeln zur Beschreibung des Vorgangs festgelegt.

Parallel mit dem Prozeß der Werkstofftransformation und mit ihm eng verbunden vollzieht sich der Prozeß der Informationstransformation. Das Ergebnis als zeitpunktbezogenes Geschehen startet (zum Beispiel in Form eines Fertigungsauftrages) den Vorgang Produktion. Ein Ereignis verbraucht im Gegensatz zu einem Vorgang weder Zeit noch Ressourcen. Ergebnis ist die Fertigstellung des Auftrages als Ergebnisereignis sowie das erstellte Teil S5.

Erst mehrere Ereignisse leisen einen Vorgang aus

Ein Ergebnisereignis kann dabei auch eine Statusänderung eines bereits bekannten Objektes sein. Die Fertigungsmeldung des Auftrages ist damit die Statusänderung des Fertigungsauftrages. Es ist durchaus möglich, daß erst das Zusammentreffen mehrerer Ereignisse einen Vorgang auslösen oder auch mehrere Ereignisse Ergebnis eines Vorgangs sind.

Zur Steuerung des Vorgangs werden Zustände des Aufgabenumfeldes einbezogen, die zum Beispiel Parameter für die Bearbeitungsregeln liefern. Im Falle der Produktion können diese Beschreibungen des zu erstellenden Produktes oder benötigter Komponenten sein. Während der Bearbeitung können dabei diese Daten verändert werden, beispielsweise der Lagerbestand durch Zuordnung von Komponenten zu dem Kundenauftrag verringert werden.

Die Änderung von Zuständen des Umfeldes aus einer Bearbeitungsfunktion heraus geschieht jeweils durch von der Vorgangsbearbeitung erzeugte Ereignisse. Diese ist zum Beispiel die Anlage eines neuen Entities (Kunde, Artikel und so weiter) oder Veränderung eines Attributwertes. Dieser Tatbestand kennzeichnet die gebräuchliche Definition eines Vorgangs als Prozeß zur Transformation von Inputdaten zu Outputdaten.

Die einzelnen Ereignisse und darauf aufbauenden Änderungen werden erst bei einer detaillierten Beschreibung der Vorgänge sichtbar. Die in Abbildung 1 als gegenläufige Pfeile dargestellte Änderung ist somit eine grobe Darstellung des Transformationsprozesses. Es sind lediglich zwei besondere Ereignisse herausgestellt, die einen Vorgang starten beziehungsweise Ergebnis eines Vorgangs sind. Je nach Art des Vorganges kann die Werkstoff- oder die Informationstransformation im Vordergrund stehen. Bei Betrachtung von Fertigungsvorgängen, wie sie im Rahmen der Produktionstheorie untersucht werden, dominiert die Werkstofftransformation.

Bei stärker verwaltungsorientierten Vorgängen, zum Beispiel Auftragsbearbeitung, Buchführung, Planung und Disposition dominieren dagegen die Informationstransformationsprozesse.

Es ist aber zu betonen, daß beide Partner ineinander verwoben sind, das heißt, bei der Werkstofftransformation werden auch Informationen transformiert und die Veränderung von Informationen kann auch zur Werkstoffveränderung führen.

Diese Zusammenhänge werden insbesondere durch den Einsatz moderner technischer Produktionsverfahren deutlich, bei denen die Maschinen durch Steuerungsprogramme (NC-Programme) gesteuert werden und Rückmeldungen über die Ausführung der Vorgänge automatisch von Informationssystemen aufgenommen werden.

Deshalb wird auf die gleichgewichtige Bedeutung von produktionsorientierten Betriebsmitteln wie auch informationsverarbeitenden Betriebsmitteln hingewiesen.

Informationssysteme dienen zur Unterstützung konkreter Anwendungen. Diese können auf unterschiedlichen Abstraktionsebenen betrachtet werden. Wird von dem speziellen Anwendungsbezug, ob eine Auftragsbearbeitung oder ein Buchführungsablauf beschrieben wird, abstrahiert, so ergibt sich ein allgemeines Vorgangskettenmodell (siehe Abbildung 2).

Hier wird somit der Anwendungsbezug verlassen und damit eine Ebene erreicht, in der die grundsätzliche Struktur einer Vorgangskettenbearbeitung beschrieben wird.

Die zeitpunktbezogenen Tatbestände wie Auftragserteilung, Auftragsbestätigung werden zu der Klasse Ereignis zusammengefaßt. Alle zeitverbrauchenden Geschehen zu Klasse Vorgang, alle Beschreibungen des Umfeldes zu Klasse Umweltzustände, alle Materialien (Hilfs-, Betriebs- und Werkstoffe) zu Klasse Werkstoff und so weiter.

Die Grafik der Ebene 3 zeigt dabei nicht alle denkbaren Beziehungen zwischen den Komponenten. So können bestimmten Mitarbeitern Organisationseinheiten und Betriebsmittel zugeordnet sein oder ein Ereignis kann durch Beziehungen zwischen Umweltzuständen erklärt werden. Beispielsweise kann das Ereignis "Auftragserstellung" als Beziehung zwischen einem bestimmten Kunden als Element der Umwelt und der Zeit definiert werden. Die Darstellung bildet aber eine anschauliche Grundlage der weiteren Betrachtungen.

Da diese Ebene Informationen über die eigentliche Beschreibungsebene betriebswirtschaftlicher Informationssysteme enthält, wird sie als Metaebene bezeichnet. In dieser Ebene wird festgelegt, anhand welcher Schichten, Verfahren und Begriffe die darunterliegenden Fachebenen beschrieben werden. Hier können dabei unterschiedliche Beschreibungsverfahren eingesetzt werden. Auf der Metaebene werden aber die mit diesen Verfahren zu beschreibenden Elemente festgelegt.

Im folgenden wird aus diesem Ausgangsmodell eine Architektur abgeleitet, nach der Informationssysteme, die primär zur Unterstützung von Vorgangsketten eingesetzt werden, beschrieben werden können. Dazu wird das Ausgangsmodell weiter strukturiert, um den Beschreibungsgegenstand zu vereinfachen. Anschließend wird eine einheitliche Beschreibungssprache festgelegt. Die Architektur bildet den Rahmen zur Speicherung von Modellen der Anwendungsebene. Diese werden in einer Meta-Datenbank, einem Repository, abgelegt. Die Metaebene besteht somit aus - dem allgemeinen Vorgangsmodell zur Ableitung der Architektur,

- den Blöcken und Bausteinen der Beschreibung (Architektur),

- der Beschreibungssprache für eine detaillierte Beschreibung der Blöcke und Bausteine,

- Modelle zur Abbildung der Elemente einer Beschreibungssicht (Meta-Modelle),

- Datenbank zur Speicherung der nach der Architektur beschriebenen Modelle (Repository).

II. Ableitung der Aris-Architektur durch Strukturierung des Vorgangskettenmodells

Die aus betriebswirtschaftlicher Sicht zu beschreibenden Komponenten eines Informationssystems einschließlich ihrer Beziehungen untereinander sind somit Zustände, Ereignisse, Vorgänge sowie die Produktionsfaktoren Werkstoffe, menschliche Arbeitsleistung (Mitarbeiter), Betriebsmittel (unterschieden nach Produktionsbetriebsmitteln und Betriebsmitteln der Informationstechnologie) und Organisationseinheiten zu ihrer Strukturierung.

Da jedes Element mit jedem anderen in Beziehung stehen kann, ergibt sich eine komplexe Struktur. Dabei können auch multiple Beziehungen bestehen. Beispielsweise ist die Beziehung zwischen Vorgang und menschlicher Arbeitsleistung auch davon abhängig, welche Betriebsmittelunterstützung bei der Ausführung des Vorgangs gewährt wird. Weiterhin können auch innerhalb der Elemente Beziehungen bestehen, die zum Beispiel angeben, wie Zustände voneinander abhängen oder wie Ereignisse untereinander verbunden sind.

Um deshalb die Komplexität zu reduzieren, werden drei Schritte durchgeführt:

1. Abstraktion von für die Informationsverarbeitung nicht relevanten Tatbeständen.

2. Zusammenfassung von Elementen zu gröberen Beschreibungssichten,

3. Reduktion von Beziehungen durch ein Phasen- beziehungsweise Vorgehensmodell.

II.1 Konzentration auf Informationstransformation

Der güterliche Transformationsprozeß von Werkstoffen wird, zur Verringerung der zu betrachtenden Komponenten und damit zur Vereinfachung nicht weiter als eigenständige Beschreibungskomponente der Architektur behandelt.

Er ist vielmehr Bestandteil des Umfeldes der Vorgangskette, das durch Zustände beschrieben wird. Das gleiche gilt für die an der Werkstoffumsetzung beteiligten Produktionsbetriebsmittel.

Auch sie gehen als informatorisches Abbild in dem Begriff des Umfeldzustands auf. Wegen der engen Verbindung zwischen der Güter- und Informationstransformation werden aber Informationen über den Materialumwandlungsprozeß in der Zustandsbeschreibung des Umfeldes weiterhin einbezogen.

In einem PPS-System wird zum Beispiel durch die Stücklisten und Arbeitspläne ein Vorgangskettenmodell der Materialtransformation erfaßt. In ihm werden die anzuführenden Arbeitsgänge (zum Beispiel Sägen, Bohren, Drehen), die einzusetzenden Produktionsbetriebsmittel und benötigten Materialien beschrieben. Dieses wird aber in einem PPS-System als Umfeldbeschreibung (in der Datenbasis) abgelegt. Die Vorgänge des Informationstransformationsprozesses, bei denen diese Daten als Umfeldzustände benutzt werden, sind vielmehr zum Beispiel Arbeitsplanung, Arbeitsvorbereitung, Fertigungssteuerung oder Betriebsdatenerfassung.

Der weite Begriff "Umfeldzustand" dient also dazu, alle Komponenten eines Informationssystems aufzunehmen, die nicht in einer eigenen Beschreibungssicht behandelt werden sollen. Die menschliche Arbeitsleistung beziehungsweise die Arbeitskräfte werden aufgeteilt in die am Produktionsprozeß beteiligten Mitarbeiter, die ebenfalls als Teil des Umfeldes betrachtet werden sowie die direkt mit Informationssystemen befaßten Benutzer.

In Abbildung 3 wird diese veränderte Sicht durch Einrahmung der betreffenden Elemente deutlich gemacht. Die Betrachtungsweise bedeutet, daß aus Sicht der Informationsverarbeitung bei der Betrachtung eines Produktionsvorgangs nicht die physische Sicht des Einsatzes von Werkstoffen, menschlicher Arbeitsleistung und Betriebsmittel Gegenstand der Betrachtung ist, sondern lediglich die durch den physischen Produktionsprozeß verursachte Veränderung von Daten. Es wird somit lediglich das datenmäßige Abbild betrachtet.

Die Betriebsmittel der Informationstechnologie bleiben aber als Träger des Informationssystems weiterhin relevant. Das gleiche gilt auch für die menschliche Arbeitsleistung, die direkt mit dem Informationssystem als Benutzer verbunden ist. Die Zusammenfassung von Mitarbeitern oder Betriebsmitteln zu Organisationseinheiten bleibt ebenfalls eine weiterhin gültige Komponente.

II.2 Bildung von Sichten

Das nach der Konzentration auf informationsrelevante Tatbestände sich ergebende Vorgangskettenmodell ist weiterhin komplex. Deshalb werden einzelne Beschreibungselemente weiter zusammengefaßt. Auch führt die vorgangsbezogene Sicht zu erheblichen Redundanzen. So können für mehrere Vorgänge die gleichen Umfeldzustände, Ereignisse, Benutzer und so weiter zuständig sein, wie es in Abbildung 2 bezüglich der Kunden- und Artikelbeschreibungen für die detaillierte Auftragsannahme und Auftragsverfolgung gezeigt wurde.

Um diese Redundanzen zu vermeiden, wird das Vorgangskettenmodell in einzelne Sichten zerlegt, die dann unabhängig voneinander und damit redundanzärmer beschrieben werden (vergleiche Abbildung 4).

Zunächst werden Ereignisse und Umfeldzustände durch Daten abgebildet. Sie werden als Informationsobjekte durch eine einheitliche Datensicht abgebildet. Die Erfassung von Ereignissen als Teil einer Datensicht ist bei vielen Software-Entwicklungs-Methoden gebräuchlich.

Die Beschreibung der Vorgangsregeln sowie der Vorgangsstruktur bildet die Vorgangs- oder Funktionssicht. Der Begriff "Funktion" wird deshalb mit den Begriffen "Vorgang" oder "Vorgangskette" häufig gleichbedeutend verwendet, weil er im Zusammenhang mit dem funktionsorientierten Systementwurf in der Literatur viel verwendet wird.

Die Komponenten Benutzer und Organisationseinheiten werden wegen ihres engen Zusammenhangs zu einem Element zusammengefaßt. Benutzer sind Organisationseinheiten zugeordnet und diese werden nach Kriterien wie "gleiche Funktion" oder "gleiches Arbeitsobjekt" gebildet. Diese Sicht wird als Organisationssicht bezeichnet.

Die Betriebsmittel der Informationstechnik bilden den vierten Beschreibungskreis, die Ressourcensicht. Damit sind die sechs Beschreibungselemente auf vier reduziert worden, wobei eine weitere Vereinfachung durch die Konzentration der Begriffe Betriebsmittel und Benutzer auf den Zusammenhang zur Informationstransformation erreicht wird.

Mit der Bildung der Sichten gehen aber Zusammenhänge zwischen den Sichten verloren. Deshalb wird später eine zusätzliche Sicht mit der Bezeichnung "Steuerung" eingeführt, die Zusammenhänge zwischen den Sichten erfaßt.

Neben der Reduktion von Komplexität und Redundanzen des Beschreibungsgegenstands besitzt die Bildung von Sichten den Vorteil, daß eine Komponente (also eine Sicht) bereits entwickelt werden kann, ohne daß die anderen Sichten vorliegen. Dieses führt zum Beispiel später dazu, daß das Datenmodell eines Systems erstellt werden kann, ohne daß die Funktionen umfassend definiert sind.

Sofern also zur Beschreibung einer Sicht unbedingt Angaben einer anderen Sicht erforderlich sind, so können die in allgemeiner Form von der betrachteten Sicht selbst festgelegt und später von der eigentlich zuständigen Sicht weiter spezifiziert werden.

Trennung in Sichten nicht immer möglich

Die Trennung in Sichten kann wegen der zwischen ihnen bestehenden Beziehungen nicht immer ganz konsequent eingehalten werden. Beispielsweise kann es für die Beschreibung von Vorgängen innerhalb der Funktionssicht sinnvoll sein, auch Ereignisse, die Vorgänge auslösen oder ihr Ergebnis sind, anzuführen, obwohl diese zum Teil im Datenmodell erfaßt werden.

Es müssen aber dann nicht die strengen Anforderungen der Definition der Informationsobjekte im Sinne der Datenmodellierung eingehalten werden.