Auswertung

Bewerten der Aufgaben und Erstellen der Prüfaufgabe(n)

Hier folgte ich dem Leitfadenvorschlag, realitätsbezogene Aufgaben zu erstellen. Es gab auch die Möglichkeit, vordefinierte Aufgaben aus dem Bereich ,,Datenbanken`` oder ,,Textverarbeitung`` zu benutzen. Diese waren für BASS II aber nicht anwendbar.

Bewerten der Aufgabe

Hier wurde auf den Abschnitt ,,Prüffragen zur Untersuchung der Mensch-Maschine-Funktionsverteilung und der Arbeitsabläufe`` im Anhang verwiesen. Viele dieser Prüffragen erschienen für dieses Beispiel irrelevant. Beispiel:

,,Werden den Arbeitenden berufliche Entwicklungsmöglichkeiten geboten (z.B. höheres Einkommen)?``

Die Interpretationsvorschrift ([Oppermann 92] S. 137) ergibt dann Hinweise auf ,,Verletzungen von Forderungen der Organisations-Ergonomie``. Diese Einschränkungen sollen dann bei der Evaluation des Systems berücksichtigt werden.Die Frage nach der allgemeinen Gebrauchstauglichkeit von BASS II zum Einsatz in Betrieben wurde hier aber nicht gestellt, so daß ich diese Art der Aufgabenbewertung nicht weiter berücksichtigt habe. Es scheint mir aber wichtig anzumerken, daß eine solche Überprüfung für das spätere Gesamtsystem unerläßlich ist, da sonst wieder nur ,,Oberflächenkosmetik`` betrieben würde!

Erstellen der Prüfaufgaben(n)

Um die Prüfaufgaben einzuschränken, nachdem dies mehrere Schritte vorher aufgrund mangelnder Detailkenntnisse aller Prüffragen noch nicht möglich war, werden im Leitfaden verschiedene grundlegende Bereiche untersucht. Ich habe diese Fragen gemäß der Leitfadenvorgaben anhand von Gesprächen mit jeweils einem Benutzer bzw. einer Benutzerin gewonnen. Die Angaben der anderen Benutzer konnten aus praktischen Gründen (Zeitmangel bei den Benutzern) erst später erhoben werden, unterschieden sich aber nicht maßgeblich von den ersten Aussagen. Als weitere Informationsquelle dienten Gespräche mit Herrn Prof. Nachreiner, der als Auftraggeber für BASS II fungierte. Diese Angaben konnten ähnlich der Angaben von Vorgesetzten bewertet werden, da er die Aufgaben am Anfang des Projektes festgelegt hatte.

Bestimmung des zu untersuchenden Arbeitsplatzes

Der Arbeitsplatz war durch die Verwaltungsstruktur vorgegeben. Schichtplaner sind in der Regel mittlere Führungspersonen. Eine andere Einordnung hätte aber anscheinend auch keine Auswirkungen auf die Evaluation gehabt, da sie im Leitfaden nicht weiter berücksichtigt wurde.

Prüfen der Qualifikation des zu Befragenden

(Gemeint ist hier die Qualifikation bezüglich der Arbeitsaufgabe) Die zu ,,Befragenden`` sind in diesem Fall die späteren Benutzer einer Software. Im Fallbeispiel wurden stellvertretend die Benutzerinnen aus einer Schichtplanberatungsfirma und eine Gruppe von mit Schichtplänen befaßten Abteilungsleitern eines Flughafens betrachtet.

Gemäß dem Leitfaden waren alle betrachteten potentiellen Benutzer in der Aufgabe ,,Organisation von Schichtplänen`` hinreichend geübt. Bei EVADIS II heißt das konkret, daß alle Benutzer mindestens drei Monate an einer solchen Aufgabe beschäftigt sind und die vom Betrieb geforderten Ausbildungsvoraussetzungen erfüllen.

Für die Gruppe der Benutzerinnen aus der Schichtplanberatungsfirma, die BASS II bereits professionell einsetzen, galt der Sonderfall, daß sie sich mehr als einen Monat damit befaßt hatten. Die Flughafengruppe hingegen kennt BASS II noch nicht, erarbeitet aber schon mehrere Jahre Schichtpläne.

Orientierung über die Aufgaben - Analyse und Auswahl bzgl. der zu evaluierenden Anwendung(en) Hier werden nun die zu erledigenden Aufgaben des Arbeitsplatzes erfaßt. Da nur eine bestimmte Aufgabe (Optimierung von Schichtplänen) mit dem zu evaluierenden Teil der Software bewältigt werden kann, mußte ich dies als gegebene Aufgabe nehmen. Natürlich müßte eine Gesamtbewertung von BASS II zunächst klären, inwieweit dies überhaupt innerhalb der Aufgaben der Benutzer liegt. Dieser wichtige Punkt hätte normalerweise schon vor Projektbeginn hinreichend geklärt werden müssen. Für dieses Beispiel nehmen wir nun an, daß dies gegeben wäre. Interessant blieb die Frage das Anteils dieser Aufgabe am Gesamtarbeitsaufkommen dieses Arbeitsplatzes. Aus den Gesprächen entnahm ich einen Anteil von unter 25% bei beiden Gruppen.

Detailliertere Orientierung über die von der(den) zu evaluierenden Anwendung(en) unterstützen Aufgabe - Arbeitsablauf und anzuwendende Funktionen der zu evaluierenden Anwendung(en)   Hier werden die vorher gewonnenen Teilaufgaben in den Organisationsablauf zunächst eingeordnet. Da in diesem Beispiel kein innerbetrieblicher Informationsfluß relevant ist, wurde dieser Punkt übersprungen. Auch hier bleibt anzumerken, daß dies für eine Gesamtbewertung von BASS II natürlich erfolgen müßte. Schichtpläne zum Beispiel hängen sehr stark von Informationen innerhalb des Betriebes (z.B. Schichtregelungen) und außerhalb (z.B. Schichtbedarf) ab! Für den untersuchten Fall der Schichtplanoptimierung stehen aber alle Daten innerhalb des Programmes bereit.

Der andere untersuchte Punkt sind die benötigten Funktionen der Anwendung und eine Einschätzung ihres Gewichtes für die Gesamtaufgabe. Dieser Punkt ist auch für das Fallbeispiel relevant. Allerdings ist der Entwickler hier auch wieder auf sich selbst gestellt, da es nur Beispielfunktionen für Textverarbeitungen o.ä. innerhalb des Leifadens gab. Für alle anderen Fälle stellt EVADIS II eine ,,abstrakte Musterprüfaufgabe`` bereit, die der Entwickler selber anpassen muß. Aus dieser Musteraufgabe habe ich dann die Prüfaufgaben entnommen. Da die Beschreibung der benötigten Funktionalitäten innerhalb dieser abstrakten Musteraufgabe recht grob war, konnte auf eine Feinanalyse der durchzuführenden Tätigkeiten zum Optimieren eines Schichtplanes zunächst verzichtet werden. Die folgenden Funktionen aus der gegebenen Musterprüfaufgabe habe ich dann weiter untersucht:

• ,,Eingabe von Texten und Daten. Löschung von (absichtlich) fehlerhaften Eingaben``(aus [Oppermann 92]). Dies ist zum Beispiel für die Eingabe der Parameter zu den Kriterien interessant. Zu testende Funktionen sind gemäß Leitfaden also Markieren, Einfügen, Verschieben, Suchen, Löschen.
• ,,Änderung`` (ebenda) s.o.
• ,,Spezifizierung`` (ebenda). Dieser Punkt ist für das Fallbeispiel besonders interessant, da er die Funktionen ,,Selektion von Objekten``,,,Formatierung und Anzeige am Bildschirm`` beinhaltet.
• ,,Verarbeitung`` (ebenda). Hier wird der Punkt ,,Bewerten`` von BASS II berührt. Dieser (oder alternativ dazu das wiederholte Anwählen eines Bewertungskriteriums) führen zu einer Neudarstellung des Schichtplanes und der dargestellten Regelverletzungen.
• ,,Stabilitätstest`` (ebenda). Da BASS II unter bestimmten Bedingungen zu einem Absturz des Programms führte, war dieser Punkt zu berücksichtigen.
• ,,Beendigung des Dialogs`` (ebenda). Auch diese Funktion sollte in dieser Teilaufgabe sicherlich zur Verfügung stehen.

Unter Berücksichtigung dieser noch zu prüfenden Funktionalität des Teilsystems blieben zunächst 198 (!) Prüfungsfragen. Der Aufwand ist also immer noch beträchtlich.

Während der eigentlichen Fragenbearbeitung entfielen Fragen , die erst dann als für dieses Fallbeispiel nicht zutreffend erkannt wurden. Dadurch reduzierte sich die Anzahl der Fragen erheblich. Genaueres dazu findet sich in der Bewertung dieses Verfahrens in (S. ).

Charakterisierung der Benutzer des Anwendungssystems

Unter diesem Punkt werden Benutzereigenschaften erhoben. Ziel dieser Fragebögen, die beim Benutzer ausgefüllt werden sollen, ist eine Einteilung der Benutzer in eine der vier folgenden Kategorien, die in Abbildung dargestellt werden.

   

geübt ungeübt regelmäßig sporadisch

Die Einordnung erfolgt nach den Kriterien

• fachliche Kenntnisse: Aufgaben-Jobalter und Selbsteinschätzung der Ausbildungsqualität
• EDV-Kenntnisse: EDV-Jobalter, vermittelte EDV-Ausbildungsinhalte und Selbsteinschätzung dieser Ausbildung
• Nutzung von EDV: Zeit am Tag in Stunden

In diesem Fallbeispiel handelte es sich um ungeübte und sporadische Benutzer (gemäß [Oppermann 92] Abb. 1 S. 109), denn keiner der Benutzer gab an, über eine gute EDV-Ausbildung oder weitergehende Kenntnisse (z.B. Programmiersprachen) zu verfügen.

Rangfolge und Gewichtung der Kriterien

Daraus ergibt sich die folgende Gewichtung der Kriterien:

 

Rang Gewicht Kriterium

1 hoch Kooperations- und Kommunikationsförderlichkeit

2 hoch Datenschutz/Datensicherheit

3 hoch Nützlichkeit

4 hoch Komfort

5 hoch Erlernbarkeit

6 hoch Fehlerrobustheit

7 hoch Selbstbeschreibungsfähigkeit

8 hoch Erwartungskonformität

9 hoch Übersichtlichkeit

10 gering Individualisierbarkeit

11 gering Steuerbarkeit

12 gering Verfügbarkeit

Damit ist nach EVADIS II-Durchführungsvorschrift die Vorbereitung abgeschlossen. Bereits hier fällt auf, daß einige Entscheidungen für oder gegen bestimmte Prüffragen aufgrund relativ ungesicherter Einschätzungen erfolgte.

Auswertung