|
|
Das Fallbeispiel,BASS II``
,,Die Arbeitgeber sind verpflichtet, sich über den neuesten Stand der Technik und der wissenschaftlichen Erkenntnisse auf dem Gebiet der Gestaltung der Arbeitsplätze zu informieren, um etwa erforderliche Änderungen vorzunehmen und damit eine bessere Sicherheit und einen besseren Gesundheitsschutz der Arbeitnehmer gewährleisten zu können.An Bildschirmarbeitsplätzen sind die ergonomischen Aspekte besonders wichtig. Diese Richtlinie leistet einen konkreten Beitrag zur Verwirklichung der sozialen Dimension des Binnenmarktes.`` (aus der Präambel von [EU 90/270])
,,3. MENSCH-MASCHINE-SCHNITTSTELLEBei Konzipierung, Auswahl, Erwerb und Änderung von Software sowie bei der Gestaltung von Tätigkeiten, bei denen Bildschirmgeräte zum Einsatz kommen, hat der Arbeitgeber folgenden Faktoren Rechnung zu tragen:
a) Die Software muß der auszuführenden Tätigkeit angepaßt sein.
b) Die Software muß benutzerfreundlich sein und gegebenenfalls dem Kenntnis- und Erfahrungsstand des Benutzers angepaßt werden können; ohne Wissen des Arbeitnehmers darf keinerlei Vorrichtung zur quantitativen oder qualitativen Kontrolle verwendet werden.
c) Die Systeme müssen den Arbeitnehmern Angaben über die jeweiligen Abläufe bieten.
d) Die Systeme müssen die Information in einem Format und in einem Tempo anzeigen, das den Benutzern angepaßt ist.
e) Die Grundsätze der Ergonomie sind insbesondere auf die Verarbeitung von Informationen durch den Menschen anzuwenden.`` (Anhang, 3. Teil [EU 90/270])
Die beiden obengenannten Auszüge aus der EU-Richtlinie zeigen, daß ergonomische Gestaltung von Software nicht länger ein nettes, aber ggf. überflüssiges Feature, sondern ein Muß darstellt. Ähnliche Formulierungen finden sich dann auch in weiteren Vorschriften wie zum Beispiel im Entwurf zur Unfallverhütungsvorschrift VBG104, deren Zukunft allerdings immer noch ungewiß scheint:
,,Software-Gestaltung (§ 29 - 37)§ 29 Allgemeine Anforderungen
Der Unternehmer hat dafür zu sorgen, daß bei der Gestaltung von Tätigkeiten mit Bildschirmgeräten sowie bei Entwicklung, Auswahl, Erwerb und wesentlicher Änderung von Software nach Maßgabe der jeweiligen Arbeitsaufgabe die Gestaltungsprinzipien nach dem Stand von Technik, Arbeitsmedizin und den sonstigen gesicherten arbeitswissenschaftlichen Erkenntnissen angewendet werden, um die Sicherheit und den Gesundheitsschutz der Versicherten am Arbeitsplatz zu gewährleisten.`` (§29 aus [VBG 104])
Es ist von der EU mit der Richtlinie 90-270 ([EU 90/270]) zwingend vorgeschrieben, diese Ziele verbindlich und damit auch einklagbar zu machen. Dabei sind aber einige Schwierigkeiten, die zumeist auf nicht ausreichend faßbaren Anforderungsspezifikationen beruhen, zu erwarten (vgl. [Rudlof & Dzida 97]).
Die Frage, ob und wie das Ziel, Software zu schreiben, die
diesen Richtlinien entspricht, erreicht werden kann, soll in dieser
Arbeit an einem Fallbeispiel untersucht werden. Genauer gesagt
untersuche ich zum einen die Möglichkeiten, Verstöße gegen diese
Richtlinien zu finden, zu bewerten und konstruktive Vorschläge daraus
abzuleiten und zum anderen die Möglichkeiten der Zertifizierung im
Sinne bestehender Normen. In Abbildung 
habe ich diese
Bewertungsphase, die Evaluation, einmal (provisorisch) in einen
möglichen Softwareentwicklungsablauf eingeordnet. Eine verfeinerte
Einordnung werde ich abschließend in Abschnitt
(Seite f.) vorschlagen.
Abbildung: Entwicklungsablauf (stark vereinfacht)
Für die vorhergehenden Entwicklungsphasen gibt es bereits eine Reihe von Hilfen und Werkzeugen, zum Beispiel MUSE & EXPOSE ([Qin 95]; [Gorny & Viereck 91]), welche den Softwareentwickler wissensbasiert schon bei der Entstehung des Prototypens durch Bereitstellung von möglichst relevanten Informationen unterstützen. In [Qin 95] werden auch andere ähnliche designunterstützende Systeme wie HyperSAM, SIERRA und IDA kurz vorgestellt.
In verwendeten Fallbeispiel war die Entwurfsphase aber bereits abgeschlossen, so daß ich mich auf den nächsten Schritt, die Überprüfung der getroffenen Entscheidungen konzentriere.
Ein wichtiger Punkt ist die Machbarkeit. Praktisch ist es schließlich so, daß ein Verfahren, welches entweder die Konformität von Software zu den genannten Richtlinien bestätigen (summative Evaluation) oder dem Entwickler Hinweise zu konformitätssteigernden Änderungen geben soll (formative Evaluation), auch mit einem vertretbaren Aufwand in einem realen Unternehmen mit realen Benutzern durchführbar sein sollte.
Nielsen stellt dar, daß schließlich auch die dem Entwickler an die Hand zu gebenden Verfahren ihrerseits wieder gebrauchstauglich sein müssen:
,,User interface professionals ought to take their own medicine some more. ...If we consider usability engineering as a system, a design, or a set of interfaces with which development managers have to interact, then it obviously becomes the usability professionals' responsibility to design that system to maximize its communication with its users. My claim is that any problems in getting usability results used more in development are more due to lack of usability of the usability methods and results than they are caused by evil development managers who deliberately want to torment their users.`` ([Nielsen 95] S.3)
Diese Arbeit beschränkt sich allerdings auf die Betrachtung eines Fallbeispieles, denn eine allgemeinere Abschätzung verlangt nach einer größer angelegten, statistischen Untersuchung in verschiedenen Unternehmen, mit verschiedenen Produkten und verschiedenen Benutzergruppen. Trotzdem hoffe ich, daß diese Arbeit dem Leser ein paar Indizien liefert, wie man es machen könnte oder warum man es anders vielleicht nicht machen sollte.
Der Bedarf für eine solche Überprüfung scheint gegeben zu sein:
,,Der Designer ist offensichtlich damit überfordert, solch komplexes, aber für die Gestaltung wichtiges Wissen zu beherrschen geschweige denn zu handhaben und in eine konkrete Anwendung umzusetzen.`` ([Qin 95] S. 30)
Es muß also gerade wegen dieser Unsicherheit immer wieder geprüft werden. Es entsteht aber die Frage, inwiefern sich diese Unsicherheit nicht auch bei der Überprüfung negativ bemerkbar machen wird. Dieses Fallbeispiel soll dazu Anhaltspunkte geben.
Zunächst beschreibe ich das Fallbeispiel, um so in den folgenden Abschnitten über Normen und Evaluationsmethoden sofort den Bezug zum Fallbeispiel herstellen zu können.
Das Fallbeispiel,BASS II``
