Von Prof. Dr. Heinz Schelle, Dipl.-Ing. Reinhardt Schnopp und Dr. Andreas Schwald
Prof. Dr. Heinz Schelle lehrt an der Fakultät für Betriebswirtschaftslehre an der Universität der Bundeswehr München, Werner-Heisenberg-Weg 39, 8014 Neubiberg; Dipl. Inf. Reinhardt Schnopp war zum Zeitpunkt der in diesem Beitrag beschriebenen Arbeit Mitarbeiter von Schelle an der Universität der Bundeswehr München. Mittlerweile arbeitet er bei der Siemens AG, Otto-Hahn-Ring 6, 8000 München 83; Dr. Andreas Schwald ist freier Berater mit Spezialgebiet Software-Engineering. Adresse: Guardinistraße 73, 8000 München 70.
Zwischen der Zahl der angebotenen Software-Entwicklungs-Tools und ihrem tatsächlichen Einsatz besteht eine auffällige Diskrepanz. Es ist zu vermuten, daß die Entwickler der Werkzeuge nur eine eingeschränkte Vorstellung vom tatsächlichen Bedarf haben. Im Beitrag wird ein Instrument vorgestellt, mit dem man die Benutzerfreundlichkeit und Akzeptanz von Software-Entwicklungswerkzeugen messen kann.
Die Zahl der Software-Werkzeuge beziehungsweise Tools für die effiziente Entwicklung von Software ist kaum mehr zu übersehen. Es besteht allerdings eine merkwürdige Diskrepanz zwischen der Vielzahl der angebotenen Tools und ihrem tatsächlichen Einsatz festzustellen. Die Akzeptanz, in Anlehnung an Reichwald [1] die "Bereitschaft eines Anwenders, in einer konkreten Anwendungssituation das vom Tool oder Toolpaket angebotene Nutzungspotential aufgabenbezogen abzurufen, ist nach wie vor gering. Als wesentliche Akzeptanzfaktoren werden in der Literatur genannt:
- die Merkmale der Anwender (zum Beispiel Berufserfahrung, Ausbildungsstand),
- die Merkmale der Aufgabenstellung (zum Beispiel Projektgröße, Vorgaben der Einsatzumgebung für das Produkt),
- die Merkmale des organisatorischen Umfelds (zum Beispiel Formalisierungsgrad der Software-Entwicklung, Umfang der Arbeitsteilung) und
- die Merkmale des Toolpakets mit den beiden Merkmalsuntergruppen "Merkmale der technischen Eignung" und "Merkmale der Gestaltung" [1].
Nicht die Eigenschaften eines Produkts, sondern die (davon abhängige) Einstellung der Benutzer zu einem Produkt, in unserem Fall zu einem Toolpaket, wird als wesentliche Einflußgröße der Akzeptanz angesehen.
Die individuellen Einstellungen, hypothetische Konstrukte, sind Prozesse, die zwischen Stimuli (Beispiel: Softwarewerkzeuge) und Reaktionen (Beispiel: Anwendung der Tools) vermitteln. Als Argumentationsbeispiel sei hier ein Zitat von Shultz und Slevin [2] angeführt, das sich auf Modelle aus der Disziplin "Operations Research" bezieht, aber ohne weiteres auf andere Objekte, wie etwa Tools übertragen werden kann: ".... the quality of an OR-model (an independent variable) may influence individual attitudes toward the model (an intervening variable) which in turn influences individual use (a dependent variable)."
Es wird vermutet, daß die Akzeptanzchancen um so größer sind je positiver die Einstellung des Benutzers zum jeweiligen Produkt ist. Von dieser Vermutung geht auch die vorliegende Studie aus.
Die Empfehlung bei Akzeptanzstudien, sich der Methoden der Einstellungsmessung zu bedienen, die vorwiegend für den Marketingbereich entwickelt wurden, wurde schon relativ früh gegeben. Sie ist zum Beispiel in dem Programm enthalten, das Shultz und Slevin [2] für die Erforschung der Akzeptanzbedingungen von OR-Modellen entworfen haben. Die beiden Autoren empfehlen unter anderem die Anwendung des Osgood'schen Differentials.
Soweit bekannt wurde dieser Rat aber zumindest für Software-Werkzeuge und Programmierumgebungen bislang nicht beachtet.
Triviale Festlegung als Grundlage
Der Forschungsplan der Verfasser, die Einstellung von Benutzern zu Software-Werkzeugen zu messen, geht von der Einsicht aus, daß es keine Beurteilung von Software unabhängig vom jeweiligen Benutzer geben kann. Grundlage dieser Einsicht ist die triviale Feststellung, daß Software von Menschen benutzt wird. Die Qualität eines Tools oder eines Toolpakets kann deshalb nicht unabhängig von der Anwendungssituation des jeweiligen Benutzers sein (Abbildung 1).
Ähnlich unterscheidet Zuse [3] verschiedene Standpunkte bei der Messung der Komplexität von Programmen, die in der großen Zahl von publizierten Komplexitätsmaßen deutlich werden.
Eine andere Vorgehensweise schlagen Weiderman et al. [4] im Zusammenhang mit der Bewertung von Software-Entwicklungsumgebungen vor. Trotz aller Unterschiede enthält aber die in diesem Aufsatz beschriebene Methode gemeinsame Elemente mit dem hier beschriebenen Ansatz. Die Autoren lehnen Benchmarktests für Entwicklungsumgebungen ab, weil sie der Komplexität dieser Art von Software nicht gerecht werden. Sie konzentrieren sich im Gegensatz zum hier beschriebenen Vorgehen auf die Tätigkeiten des Benutzers und nicht auf die Werkzeuge. Für die Bewertung einer Entwicklungsumgebung wird ein Experiment entworfen, das unabhängig von einer speziellen Umgebung sein soll. Es besteht aus verschiedenen, logisch miteinander verknüpften Tätigkeiten, die während des Lebenszyklus eines Softwareprodukts auszufahren sind. An die Ausführung von derartigen Sequenzen schließen sich Fragen an die Benutzer an, wie etwa: "Wie informativ waren die Fehlermeldungen des Compilers?"
Weiderman et al. bezweifeln die Auffassung, "that one can make objective operational definitions for concepts (zum Beispiel für Konzepte wie "ease of use" oder "ease of learning") that are inherently subjective in nature".
Ihr methodischer Ansatz basiert auf folgender Überlegung: "lt is our observation that informed subjective judgement based on systematic use of a system is more valuable than batteries of controlled experiments which may give only the appearance of objectivity." Bei verschiedenen Fragen hat man freilich den Eindruck, daß die oben kurz erwähnten und verworfenen Konzepte sozusagen durch die Hintertür wieder hereinkommen, zum Beispiel bei- der Forderung nach einem "standardized benchmark of core functionality against which environments may be measured".
Im Gegensatz zu dieser Position steht die Ansicht von Vertretern der Disziplin "Software Metrics", wonach inhärente Eigenschaften von Softwareprodukten, die unabhängig vom Benutzer beziehungsweise der Anwendersituation sind, definiert und mit geeigneten Meßvorschriften quantifiziert werden sollen.
Nach unserer Ansicht ist dieses Vorgehen, beziehungsweise die damit zum Ausdruck gebrachte Auffassung methodisch unhaltbar, weil aufgrund der unvollständigen meßtheoretischen Fundierung nahezu aller Kenngrößen auf diesem Gebiet erhebliche Interpretationsunsicherheit bezüglich der Bedeutung der gemessenen Werte vorhanden ist.
In [3] werden zum Beispiel mehr als 50 verschiedene Vorschläge zur Messung der Programmkomplexität untersucht. Anhand einfacher Beispiele wird dort gezeigt, wie sehr sich die einzelnen Maße unterscheiden und wie wenig die zur Messung herangezogenen Merkmale miteinander zu tun haben. Insbesondere scheint es schwierig, verschiedenartige Merkmale (zum Beispiel Anzahl von Variablen oder , Verzweigungen, Programmlänge, Sichtbarkeitsbereiche von Namen) auf plausible Weise zu einem Komplexitätsmaß zusammenzufassen. Daher interpretiert Zuse ein Maß als Standpunkt des Messenden, der gewisse meßbare Merkmale für wichtig hält.
Diese meßtheoretische Durchdringung der Zusammenhänge im Bereich der "Software Metrics" hat gezeigt, daß ohne die Berücksichtigung der Anwender beziehungsweise deren Einstellung keine der Kenngrößen sinnvoll interpretiert ist, beziehungsweise weiterverarbeitet werden kann.
Die Messung der Einstellung von Benutzern wurde von den Autoren an einem konkreten Toolpaket, das eine Fülle von Einzelwerkzeugen enthält, erprobt. Ziel der Studie war es vor allem, durch Befragung von Benutzerinformationen für die Weiterentwicklung des Toolpakets zu erhalten. Dazu wurde ein umfangreicher Fragebogen entwickelt. Neben Fragen zu einzelnen Werkzeugen enthält er auch Fragen zur Kombination mehrerer Werkzeuge, zur Einsatzumgebung und zu einem Gesamturteil über die Benutzeroberfläche.
Fragen zur Messung der Einstellung des Users
Die weiteren Ausführungen beziehen sich im wesentlichen auf die Fragen zur Messung der Einstellung des Benutzers zur Benutzeroberfläche des gesamten Toolpakets, also nicht auf einzelne Werkzeuge.
Kroeber-Riel [5] geht von folgender (mathematisch freilich unsinnigen) Arbeitsdefinition des Begriffs "Einstellung" aus:
Einstellung = Motivation + kognitive Gegenstandsbeurteilung.
Grundlage für eine solche Begriffsbestimmung ist die sogenannte Ziel-Mittel-Analyse (means-end-analysis). "Danach kann man Einstellungen als subjektiv wahrgenommene Eignung eines Gegenstands zur Befriedigung einer Motivation umschreiben. Beachtenswert ist dabei, daß diese Gegenstandsbeurteilung auf verfestigte (gespeicherte) Ansichten zurückgeht." [5]
Kroeber-Riel erläutert den Einstellungsbegriff am Beispiel des Autokaufs. Dieses Beispiel kann ohne Schwierigkeiten auf die Benutzung eines Toolpakets übertragen werden:
Ein Software-Entwickler hat eine stark positive Einstellung zum Toolpaket "Oremus". Dies läßt sich darauf zurückführen, daß er ein benutzerfreundliches Werkzeugpaket anwenden will (Motivation) und aufgrund von Erfahrungsberichten und einer Präsentation der Ansicht ist, daß "Oremus" benutzerfreundlich ist (gespeicherte Produktbeurteilung; kognitive Komponente).
Die "means-and-end"-Analyse wurde von Rosenberg [6] und seinen Mitarbeitern entwickelt. Rosenberg formulierte die Hypothese, "daß Richtung und Intensität der Einstellung zu einen Objekt von seiner (des Subjekts; die Verfasser) kognitiven Struktur abhängt, das heißt davon, wie die Ziele des Subjekts nach seinem Empfinden durch das Objekt beeinträchtigt oder gefördert werden" [7].
Die Hypothese, die mehrfach empirisch bestätigt werden konnte, läßt sich formal folgendermaßen darstellen:
A=Summe von k=1 zu u ( Xk * Yk )
A: Einstellung einer Person zu einem Objekt (attitude),
k: Betrachtetes Motiv, beziehungsweise die Ziele charakterisierendes Maß (k = 1,... n).
x(k): Wichtigkeit eines Motivs/charakterisierenden Maßes, das die Person hat (value importance) deutsch: Wertwichtigkeit
y(k): Durch die Person empfundene subjektive Wahrscheinlichkeit, daß das Motiv/das charakterisierende Maß durch das Objekt gefördert/gesteigert beziehungsweise beeinträchtigt wird (perceived instrumentality, deutsch: wahrgenommene Instrumentalität des Objekts).
Zur Ermittlung der Werte der x(k) (subjektive Wertwichtigkeit) und y(k) dienen Ratingskalen, in die der Benutzer seine Einschätzungen einträgt, zum Beispiel: für x(k):1 (sehr unwichtig) ... 5 (sehr wichtig),
für y(k):1 (sehr hinderlich) .. 5 (sehr förderlich).
Die Ordinalwerte beider Skalen werden multipliziert. In einem letzten Schritt werden schließlich die Produkte wieder auf eine Skala, die von 1 bis 5 reicht, transformiert und über alle k summiert. Um ein normiertes Ergebnis zu erhalten, kann das Ergebnis durch die Zahl der Motive dividiert werden.
Analog zu extensiven Meßstrukturen wird angenommen, daß die Einstellung bezüglich verschiedener Motive eines Benutzers additiv ist, während die wahrgenommene Instrumentalität und die Wichtigkeit sich multiplikativ für die Einstellung auswirken. (wird fortgesetzt)
Literatur:
[1] Reichwald, R.: Zur Notwendigkeit der Akzeptanzforschung bei der Entwicklung neuer Systeme der Bürotechnik, Bd. 1 der Arbeitsberichte "Die Akzeptanz neuer Bürotechnologie", München 1978
[2] Shultz, R.L.; Slevin, D.P. (Eds.): Implementing operations Research Management Science. New York 1975
[3] Zuse, H.: Meßtheoretische Analyse von statischen Softwarekomplexitätsmaßen. TU Berlin Diss., 1986
[4] Weiderman, N.H., Habermann, A.N., Borger, M.W., Klein, M.H.: A Methodology for Evaluating Environments. Sigplan Notices,-Vol 22.1, January 1987, P. 100-107
[5] Kroeber-Riel, W.: Konsumentenverhalten 3. Aufl., München 1984
[6] Kroeber-Riel, W.: Konsumentenverhalten 2. Aufl., München 1980
[7] Boehm, B.W.: Software Engineering Economics, Prentice Hall, Englewood Cliffs, 1981