Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.08.1989 - 

Software auf spezielle betriebliche Anforderungen hin entwickelt:

Das Handwerk fordert den ganzen Softwerker

Der verstärkte DV-Einsatz in Handwerksbetrieben stellt zunehmend spezifischere Anforderungen an Softwarelösungen. Die Entwicklung eines Handwerksinformationssystems (HWIS) und dessen praktische Erprobung in Schlosser-, Steinmetz- und Installateurbetrieben zeigt, welche Leistungen branchen- und objektorientierte Software erbringen muß.

Handwerksbetriebe können ihre Anforderungen an EDV-Systeme gar nicht detailliert formulieren und ihre Organisation ist in den meisten Fällen eher als chaotisch zu bezeichnen. Deshalb muß man ihnen mit einer, ihrer Branche angemessenen Software ins Zeitalter der neuen Technik und zu einer vernünftigen Organisation verhelfen - solche und ähnliche Behauptungen kann man immer wieder von Softwareherstellern hören.

Ist es nicht im Gegenteil wünschenswert, diese "chaotischen" Organisationsstrukturen und die zugrundeliegenden, weitgehend ganzheitlichen Aufgaben zur Basis der Softwareentwicklung zu machen? Warum kann die Software nicht so flexibel gestaltet werden, daß sie sich in die betrieblichen Abläufe einfügt?

Im Handwerk ist eine erhebliche Zunahme des EDV-Einsatzes zu verzeichnen. Gerne wird die steigende Tendenz alleine auf ein bedarfsorientiertes Angebot an Branchensoftware und auf die dann folgende bedürfnisorientierte Anwendung im Einzelbetrieb zurückgeführt. Übernimmt ein möglicher Interessent diese Sicht, wird er von alleine nicht mehr darauf kommen, über den Zusammenhang zwischen heute verfügbarer Softwaretechnik und deren Nutzbarkeit für eine im besten Sinne moderne Branchensoftware nachzudenken.

Ein vom Bundesministerium für Forschung und Technologie (BMFT) gefördertes Projekt der Handwerkskammer Rheinhessen beschäftigt sich mit dieser Frage. Mit Unterstützung des BMFT und des Wirtschaftsministeriums Rheinland-Pfalz arbeiten die Handwerkskammer, das im Handwerksmarkt tätige Softwarehaus nova data und die Forschungsinstitute awfi, Berlin, sowie ibek, Karlsruhe, gemeinsam an der Gewerben der Elektroinstallateure, der Schlosser und der Steinmetze erprobt und eingesetzt werden.

Im Verkauf der Untersuchungen in den Betrieben und der Erarbeitung des Pflichtenheftes bildeten sich vor allem vier Schwerpunkte für die dann folgende Gestaltungsarbeit heraus:

In Abwägung zwischen den üblicherweise vorausgesetzten Zielmarken "Individualsoftware und individueller Benutzer" beziehungsweise "Branchensoftware und typischer Durchschnittsbenutzer" wurde rasch deutlich, daß beide Ansätze dem Forschungsvorhaben nicht weiterhelfen würden. Dem durchschnittlichen Benutzer müssen die wirklichen individuellen (heutigen und zukünftigen) Benutzer gegenübergestellt werden. Für deren Berücksichtigung, ohne vorschnelle Ausgrenzungen vorzunehmen, mußte ein Adaptionskonzept entworfen werden.

Weiterhin wurde die These untersucht, inwieweit eine objektorientierte Gestaltung der Branchensoftware eher dem Denken und Handeln der Benutzer im Handwerk entspricht als eine funktionsorientierte und ob bestehende Handwerkssoftware als Basis eingebunden werden kann. Objektorientierte Gestaltung setzt auch eine objektorientierte Anforderungsdefinition voraus. Hierfür waren neue Wege der Ist-Analyse zu beschreiten.

Schließlich galt es, die Dialogschnittstelle einerseits an die Anforderungen der Benutzer und andererseits an die sich am Markt abzeichnenden Entwicklungsstandards anzupassen.

Die Adaptierbarkeit ist eines der wichtigsten Themen bei der Gestaltung eines menschengerechten Handwerksinformationssystems.

Der Gestalter einer Individualsoftware ist in einer ganz anderen Situation, denn er kennt die späteren Benutzer, ihre Aufgaben, ihren Arbeitsstil, ihre Qualifikationen und so weiter. Er kennt auch die spezifischen Eigenarten des Auftragsbetriebes. Die Gestaltung des Handwerksinformationssystems richtet sich nicht an "den Benutzer" in "dem" Betrieb. Das Systemdesign folgt einem dreifachen Abstraktionsprozeß (siehe Tabelle):

Bei diesem dreifachen Modellierungsversuch wird wesentlich stärker als bei einer Individualsoftwareentwicklung von den realen Anforderungen der Aufgaben und der Benutzer abstrahiert. Deshalb müssen konzeptionell Adaptionsinstrumente vorgesehen werden, die eine aufgaben- und benutzergerechte Systemgestaltung im Sinne der differentiellen und dynamischen Arbeitsgestaltung ermöglichen.

Folgende Anpassungen sollten demnach in einem Handwerksinformationssystem möglich sein:

- gewerbespezifische Anpassungen,

- Anpassung an existierende und sich entwickelnde Arbeitsabläufe und Datenstrukturen,

- Anpassung an gegebene und sich entwickelnde Benutzerbedingungen (Qualifikationen, Arbeitsstelle).

Ziel der Anpassungen soll, neben der Erfüllung der DIN-Kriterien und allgemeiner Software-ergonomischer Anforderungen wie der Benutzbarkeit (usability) und der Nützlichkeit (utility), die Schaffung einer menschengerechten Arbeitssituation sein.

Die Realisierung eines solchen Adaptionskonzeptes muß durch eine geeignete Softwarearchitektur unterstützt werden. Dabei ist eine möglichst weitgehende Trennung von

- Interaktionssystem und Anwendungssystem,

- Daten und Funktionen,

- Daten und Datendarstellung vorgesehen. Fehlt sie, hat dies gravierende Nachteile, was Entwicklungsaufwand, Speicheraufwand, Portabilität und Änderbarkeit betrifft.

Ein gutes Adaptionskonzept bewährt sich bereits in der Phase der Systementwicklung. Nach einem partizipativen und zyklischen Entwicklungsansatz wird das Handwerksinformationssystem auf der Grundlage früher Prototypen beurteilt und verbessert. Dazu wird dieser mit einem anwendungsunabhängigen Interaktionssystem erstellte Prototyp potentiellen späteren Nutzern sowie Vertretern von Fachverbänden in mehreren aufeinander folgenden Workshops zur Beurteilung vorgelegt. Die konkreten Problemsichten einzelner Betriebe sowie gewerbespezifische Belange (1. und 2. Abstraktionsebene) können so in die noch laufende Entwicklung eingebracht werden. Anderungsvorschläge, die sich nur auf ein Teilsystem beziehen, können ohne Nebenwirkungen aufgegriffen und Nebenarbeiten am anderen Teilsystem umgesetzt werden.

Die Entwicklung des Handwerksinformationssystems geschieht auf der Basis einer bereits bestehenden Handwerkssoftware von nova data. Ziel ist es, diese vorhandene Software an die funktionalen Anforderungen der Benutzer der verschiedenen Gewerbe (Elektroinstallation, Schlosser und Steinmetz) anzupassen und dabei auch den Stand der Technik, insbesondere auf dem Gebiet der Gestaltung der Benutzeroberfläche, möglichst umfassend einzubeziehen.

Auf dem Gebiet der Gestaltung der Benutzeroberfläche zeichnet sich ein aus der Sicht des Benutzers weitgehend einheitlicher Gestaltungsstandard durch Systeme wie MS-Windows für MS-DOS, Presentation Manager von OS/2 oder OSF/Motif für Unix und Beschreibungen wie etwa die von IBM im Rahmen ihrer SAA-Konzeption (System Application Architecture) entwickelte Definition einer Benutzeroberfläche (CUA = Common User Access), ab.

Allen diesen Ansätzen liegt als wesentliches Gestaltungsmerkmal das Objekt-Aktions-Prinzip zugrunde. Es besagt, daß erst das Objekt der Bearbeitung bestimmt wird und dann die gewünschte Aktion, die auf dem Objekt ausgeführt werden soll. Dies entspricht dem Denken und Handeln der Benutzer im Handwerk. Objekte sind "erinnerungsstabiler" als Funktionen und können daher im EDV-Alltag vor allem den gelegentlichen Benutzer unterstützen.

Die Einbeziehung eines solchen Standards bei der Entwicklung des Handwerksinformationssystems bedarf einiger wichtiger Voraussetzungen:

Soll ein bestehendes Anwendungssystem weitgehend in eine Neuentwicklung übernommen werden, müssen softwaretechnische Voraussetzungen vorhanden sein, die den Austausch der Benutzeroberfläche ermöglichen. Das heißt, schon die vorhandene Software muß die Trennung von Anwendung und Bildschirmverwaltung in getrennten Programm-Moduln mit definierten Schnittstellen bieten.

Eine objektorientierte Benutzeroberfläche kann nur realisiert werden, wenn auch die dahinterliegende Anwendung objektorientiert konzipiert wurde. Der Entwurf des Systems muß das Objekt - und nicht die Funktionen - in den Vordergrund der Betrachtung stellen. Hier bestehen die größten Probleme, vorhandene Software für eine Neugestaltung weiterzuverwenden, da sie selten unter dem Aspekt der Objektorientierung entworfen wurde.

Auch sind durch die bisher verwendeten Programmiersprachen, wie etwa Cobol, der Umsetzung der Objektorientierung auf der Programmierebene Grenzen gesetzt.

Der Umsetzung

sind Grenzen gesetzt

Objektorientierte Programmierung, etwa mit Programmiersprachen wie Smalltalk, ist bei Verwendung bestehender Software in der Regel nicht möglich, von einer völligen Neuprogrammierung einmal abgesehen.

Hier spielen auch die erheblichen Kosten eine Rolle, die neben einer

Neuprogrammierung einem Softwarehaus zusätzlich entstehen würden. Dies wären neben den Kosten für die Umschulung der Programmierer, die Ausstattung mit entsprechenden Entwicklungswerkzeugen (Compiler, Debugger und so weiter) auch der notwendige Zeitaufwand, um entsprechendes Know-how im Umgang mit diesen Werkzeugen zu erhalten.

Da die Umsetzung eines objektorientierten Entwurfs mit Einschränkungen auch mit "herkömmlichen" Programmiersprachen prinzipiell realisierbar ist, lassen sich bestehende Anwendungen - wenn sie entsprechend entworfen sind - als Basis für Neuentwicklungen verwenden.

Wichtig ist hierbei nur, daß die bestehenden Einschränkungen aus der Sicht des Benutzers keine beziehungsweise nur unerhebliche Auswirkungen auf die Benutzung haben.

Die Basissoftware der nova data erfüllt im wesentlichen diese Anforderungen, so daß hier die Möglichkeit gegeben ist, eine Benutzeroberfläche zu entwickeln, die sich an den beschriebenen Standard anlehnt.

Ein objektorientierter Entwurf läßt sich nur mühsam entwickeln, wenn die zugrundeliegenden Anforderungen nur funktionsorientiert vorliegen. Hier sind insbesondere Probleme bei der Kontrolle der Übereinstimmung von Anforderungsdefinition und Entwurf zu nennen. Von daher sollte die Objektorientierung schon in der Analysephase im Vordergrund der Betrachtung stehen.

Um diese Probleme zu minimieren, wurde im Projekt eine besondere Form der Ist-Analyse (Grob- und Feinanalyse) durchgeführt. Während der Feinanalyse wurden, ausgehend von den am Arbeitsplatz anfallenden Daten (Formulare, Notizen, mündliche Informationen, Karteien und so weiter), detailliert deren Strukturen und die dazugehörigen

Funktionen ermittelt. Die Grobanalyse erbrachte sowohl wichtige Betriebsdaten als auch die Arbeitsabläufe.

Die Anforderungsdefinition wurde so angelegt, daß die Beschreibung der Anforderungen ebenfalls objektorientiert erfolgt. Damit lassen sich auch die Ergebnisse der Ist-Analyse relativ einfach übertragen. Hierbei ist allerdings anzumerken, daß die Anforderungen in der Anforderungsdefinition eine mehrfache Abstraktion des realen Handwerksbetriebs darstellen (vergleiche Adaptionskonzept).

Für die Benutzeroberfläche wird der Einsatz folgender Gestaltungselemente angestrebt:

- grafikorientierte Bildschirmgestaltung,

- Fenstertechnik (Pop-up-Fenster und ähnliches),

- Mausbedienung,

- Menütechnik (Pull-down-Menüs und ähnliches) und direkte Kommandoeingabe über Funktionstasten und alphanumerische Tastatureingabe (für gelegentliche und regelmäßige, geübte Benutzer),

- Aktionszeile (als eine Art der Menüdarbietung),

- Hilfefunktion, mit unterschiedlichen Modi und der Möglichkeit von benutzergestaltbaren Hilfetexten,

- Infofunktion, mit der Möglichkeit der Anzeige der aktuellen Werte eines Eingabefeldes (zum Beispiel für das Feld Mehrwertsteuer 7 Prozent und 14 Prozent).

Die Umsetzung aller Anforderungen wird allerdings erst mit der Entwicklung der zweiten beziehungsweise dritten Version des HWIS möglich sein. Schon in der ersten Version sollen in einer charakterorientierten Bildschirmgestaltung alle wesentlichen Merkmale realisiert werden, so daß für den Benutzer keine wesentlichen Änderungen bezüglich des Dialogs bei der Umstellung auf Folgeversionen erfolgen.

Werkzeugcharakter eines EDV-Systems erhöhen

Es zeigt sich innerhalb des Projektes, daß auch eingeschränkte Umsetzungen der beschriebenen Anforderungen den Werkzeugcharakter eines EDV-Systems erhöhen können. So hat die erste Demonstration eines Prototypen vor späteren Anwendern weitere wichtige Anregungen sowohl in funktionaler Hinsicht als auch hinsichtlich der Wünsche an die Handhabbarkeit des Systems gebracht, obwohl dieser Prototyp bereits als textlicher Anforderungskatalog vorhanden und besprochen war. Auch des Ziel, Objekte und nicht die Funktionen als Entwicklungsgrundlage zu betrachten, hat sich während der Demonstration des Prototypen als richtiger Weg erwiesen. Zudem ist es verblüffend, wieviel interne Programmorganisation aus der Vergangenheit der DV-Technik (zum Beispiel numerische Codes) dem Benutzer zugemutet werden. Die Frage von künftigen Anwendern "wozu ist dieses Feld notwendig?", zeigte häufig den Weg dahin.

Projekt im Spannungsfeld

zwischen Theorie und Praxis

Dieses Projekt steht im Spannungsfeld zwischen der Formulierung theoretischer Ansätze und deren Umsetzung in die Praxis. Der vorgegebene finanzielle Rahmen und die Erwartung, in einer bestimmten Zeit ein lauffähiges Produkt vorzuweisen, zwingen immer wieder zu Kompromissen. Es kann durchaus von einem Kraftakt gesprochen werden, Vorstellungen der in der Forschung tätigen Institute mit den Zwängen, denen ein am Markt operierendes Softwarehaus unterliegt, auszubalancieren. Ein Handwerksbetrieb dürfte damit überfordert sein. Insoweit kommt der Vermittlung der Interessen durch eine mit dem nötigen Vertrauen ausgestatteten Institution, wie hier der Handwerkskammer, bei der Entwicklung eine wichtige Funktion zu.