Auffällige Diskrepanz zwischen Vielzahl und Einsatz von Tools, Teil 2

Ein Instrument zur Messung der Akzeptanz von Software-Tools

07.09.1990

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 ursprüngliche Absicht der Autoren war es, das Rosenberg-Modell der Untersuchung zugrunde zu legen. Die Anwendung dieses Ansatzes stieß freilich auf eine Reihe von praktischen Schwierigkeiten, wie dies Kroeber-Riel [5] auch vorausgesagt hat. Zunächst war unbekannt, welche beurteilungsrelevanten Motive Software-Entwickler überhaupt haben. Außerdem ist es möglich, daß mehrere Eigenschaften eines Produkts das gleiche Motiv befriedigen, beziehungsweise daß eine Eigenschaft mehrere Motive/Ziele anspricht. Die Eigenschaften "Benutzerhandbuch in einer Textdatei" und "Funktionstasten können benutzerspezifisch belegt werden" unterstützen beide das Motiv "Bequemlichkeit". Die zweite Eigenschaft unterstützt daneben auch das Motiv "Schnelligkeit der Arbeit".

Aus den genannten Gründen sind die Autoren in der Untersuchung einen Weg gegangen, der schon lange vorher in der Marketingpraxis gewählt wurde. Es wurde ein einfacherer Ansatz verwendet, und zwar ein Modell mit indirekter Motivgewichtung (Adequacy-Importance-Modell).

In diesem Ansatz wird nicht von den schwer zu ermittelnden Motiven ausgegangen, die ein Produkt mit seinen Eigenschaften befriedigt, sondern direkt von den Eigenschaften des Produkts, die ein Benutzer wahrnimmt. Den wahrgenommenen Produkteigenschaften ordnet der Benutzer dann Wichtigkeitswerte zu. Dadurch erfolgt eine Bewertung, die im Sinne des Rosenberg-Modells indirekt die Bedeutung der Konsumentenmotive wiedergeben soll.

Wenn zum Beispiel ein Benutzer angibt, daß die Eigenschaft, "das Benutzerhandbuch oder Teile davon können auf den Bildschirm geholt werden", sehr wichtig ist, so wird unterstellt, daß damit indirekt ein Motiv wie die Bequemlichkeit, die durch diese Eigenschaft befriedigt wird, stark betont wird.

Umgekehrt wird angenommen, daß bei einem schwach ausgeprägten Motiv auch den Programmeigenschaften, die dieses Motiv befriedigen, eine geringe Bedeutung zukommt (vergleiche Abbildung 2).

Das Adequacy-Importance-Modell hat folgende allgemeine Form:

n

Q= å Xk * Yk

k=1

Q: Qualitätsurteil eines Benutzers über das Produkt,

Xk: Gewicht/Wertwichtigkeit der Eigenschaft k für den Benutzer am Produkt,

Yk: Ausprägung der Eigenschaft k am Produkt, beurteilt durch den Benutzer (Realisationsgrad),

k aus {1,. . . . . n}, relevante Eigenschaften des Produktes.

Das kurz skizzierte Modell eignet sich nach Auffassung der Autoren nicht nur für die Beurteilung von Konsumgütern, sondern auch für die Beurteilung von Software. Seine Anwendung gibt dem Entwickler von Werkzeugen nicht nur wertvolle Informationen darüber, wie der Benutzer das jeweilige Werkzeug einschätzt, sondern zeigt ihm auch, für wie wichtig verschiedene Benutzergruppen die einzelnen Eigenschaften halten. Eine Benutzerbefragung, dem das Adequacy-Importance-Modell zugrunde liegt, kann somit wertvolle Hinweise für die Weiterentwicklung von Tools geben. Es ist zumindest in diesem Punkt dem schon kurz beschriebenen Ansatz von Weiderman et al. überlegen.

Das oben formulierte Modell ist linear-additiv, das heißt, es wird unterstellt, daß sich beim Befragten die Produkteindrücke zur Gesamtqualität summieren. Nach Kroeber-Riel [6] stützen vorliegende Untersuchungen - allerdings auf dem Konsumgütersektor - diese Hypothese. [7] weist freilich auf Schwächen eines linear-additiven Modells bei der Bewertung eines komplexen Hardware-Software-Systems hin. Besondere Mängel bei einer einzelnen Eigenschaft, zum Beispiel bei der Antwortzeit eines Dialogsystems, können ein Gesamtsystem inakzeptabel machen, obwohl diese Eigenschaft nicht höher gewichtet wird als viele andere.

Behält man das linear-additive Modell bei, so ist zu fordern, daß die einzelnen Produkteigenschaften gegenseitig unabhängig sind. Ist dies nämlich nicht der Fall und haben die Items gemeinsame Dimensionen, so sind diese Dimensionen bei der Summenbildung natürlich überrepräsentiert. Als Beispiel für eine solche Überrepräsentation nennt Trommsdorf den Fall, daß die Formulierungen für mehrere Produkteigenschaften semantisch gleich bedeutend sind. Die Modellkomponenten xk sind deshalb auf Unabhängigkeit zu prüfen.

Nach unserer Meinung bestehen allerdings in diesem Punkt erhebliche Unterschiede zwischen Eigenschaften, die für ein Software Werkzeug formuliert wurden, und Produkteigenschaften für Konsumgüter. Es dürfte im ersten Fall erheblich einfacher sein, semantisch gleichbedeutende oder sich überschneidende Aussagen zu vermeiden.

Eine weitere Annahme ist, daß die xk und yk miteinander multiplikativ verknüpft sind. Trommsdorf weist in diesem Zusammenhang darauf hin, daß Shet mit additiven Verknüpfungen genauso gute Voraussagen gemacht hat. Außerdem wurde in der Literatur [8] die Vermutung geäußert, daß bei der Messung der wahrgenommenen Instrumentalität durch Tendenzen zu Extremantworten die Wichtigkeit der Produkteigenschaft bereits implizit mitgemessen wird. Wenn dies zutrifft, ist natürlich eine zusätzliche explizite Gewichtung überflüssig.

Beide Annahmen können einem statistischen Test unterworfen werden.

Zunächst zur ersten Annahme. Trommsdorf empfiehlt hier zunächst eine KorrelationsanaIyse der einbezogenen Variablen. Werden in der Interkorrelationsmatrix größere Interdependenzen festgestellt, sollte weiterhin eine Faktorenanalyse durchgeführt werden, um redundante Faktoren aus der Befragung zu entfernen.

Die Annahme impliziter Gewichtung kann man testen, indem man errechnet, wie stark die Variablen xk und yk über die Menge der Befragten korrelieren. Falls keine derartige implizite Bewertung vorliegt, müßten die n (k {1,2....n}) Korrelationskoeffizienten normal um Null verteilt sein.

Da die aus ersten Pretests vorliegenden Daten nur einen geringen Stichprobenumfang ausmachen, wurden derartige Tests noch nicht durchgeführt.

In Übereinstimmung mit den Empfehlungen in der Literatur wurde bereits in den Pretests nicht nur die Produktbeurteilung additiv mit Hilfe des Modells ermittelt, sondern der Benutzer auch um ein Gesamturteil über das Toolpaket (Außenkriterium der Validierung) gebeten. Durch Korrelieren der beiden Maße für die Produktbeurteilung ist dann eine Validierung möglich.

In der Untersuchung wurden Ordinalskalen - auch Ratingskalen genannt - benutzt. Obwohl gegenwärtig noch nicht vollständig geklärt ist, wie die meßtheoretisch exakten Zusammenhänge zwischen der empirischen und der numerischen Seite bei der Messung der vorliegenden Fragestellung aussehen, und somit ein gewisses methodisches Unbehagen durchaus angebracht erscheint, glauben wir - bei hinreichend "vorsichtiger" Behandlung und Interpretation der Ergebnisse -, die Untersuchung durchaus auf die im folgenden beschriebene Art und Weise auswerten zu können.

Abbildung 3 zeigt Beispiele für Rating-Skalen und deren Anwendung auf eine Produkteigenschaft.

Es handelt sich also um zweipolige Skalen mit ordinalem Meßniveau. Obwohl Ratingskalen eine Reihe von Mängeln aufweisen - ein wesentlicher Nachteil ist zum Beispiel, daß die Befragten dazu neigen, mehr oder weniger extreme Positionen einzunehmen und entsprechend in der Skala anzukreuzen -, werden sie wegen ihrer einfachen Anwendung doch häufig benutzt.

Die Meßwerte beider Skalensätze werden paarweise multipliziert und linear auf Ausprägungen von 1 (schlechte Beurteilung des Programmpakets) bis 5 (gute Beurteilung des Programmpakets) transformiert, für n Eigenschaften ergibt sich somit als Gesamturteil eines Benutzers.

n

å Realisierungsgradk*Gewichtk

k =1

- - - - - - - - - - - - - - - -

5 * n

In unseren Versuchen wurden die Skalen also auf Intervall-Skalenniveau ausgewertet. Dies ist eine in der Praxis empirischer Forschung weit verbreitete Übung. Einige empirische Untersuchungen weisen darauf hin, daß das Rechenergebnis in bezug auf Unterschiede im Skalenniveau wenig sensitiv ist und daß man keinen allzu großen Fehler begeht [5].

Für die Anwendung des Adequacy-Importance-Modells sind relevante Eigenschaften zu formulieren. Das bedeutet in unserem Fall, die Formulierung von Eigenschaften "benutzerfreundlicher" Programmoberflächen. Hier wurden zwei Methoden kombiniert:

Zunächst wurde die einschlägige Literatur ausgewertet und eine vorläufige Itemliste erstellt. Diese Liste wurde dann auch ausgewählten, erfahrenen Software-Entwicklern zugänglich gemacht. Schließlich wurde dann in mehreren Gruppendiskussionen über den Katalog diskutiert und die Itemliste ergänzt.

Prinzipiell könnte auch ein Verfahren der multidimensionalen Skalierung benutzt werden, um Items zu sammeln. Der Vorteil dieser Verfahren besteht darin, daß man Eigenschaften erhält, die von den Befragten selbst nicht formuliert werden müssen. Da nach Ansicht verschiedener Autoren bei diesen Verfahren aber mindestens acht verschiedene Tools beziehungsweise Tool-Pakete miteinander verglichen werden müßten und kaum angenommen werden kann, daß der Anwender so viele ähnliche Softwarewerkzeuge aus eigener Anschauung kennt, scheidet dieses Vorgehen aus.

Auch die Methode des "Repertory Grid" wurde für die Item-Sammlung erwogen. Hier müßten den Befragten jeweils Dreiergruppen von Tools oder Tool-Paketen vorgelegt werden. Der Befragte müßte dann Eigenschaften nennen, nach denen sich zwei der Tools ähnlich sind wohingegen sie sich vom dritten Tool unterscheiden. Dieses Verfahren wird solange wiederholt, bis bei Vorlage neuer Tripel sich keine neuen Eigenschaften finden. Da die Entwickler im allgemeinen nur mit einer sehr begrenzten Anzahl Tools, die die gleiche Funktion haben, vertraut sind, scheidet auch dieser Ansatz aus.

Damit ist ein Problem angesprochen, das in der Literatur bisher nur unzureichend diskutiert wurde: Die Frage der Produktkenntnis. Einstellungsmessung wurde bisher fast ausschließlich bei Konsumgütern angewendet. Viele Beispiele zeigen, daß häufig gar nicht angenommen und vorausgesetzt wird, daß der Befragte die Produkte genau kennt, das heißt konsumiert oder genutzt hat, so zum Beispiel wenn Präferenzurteile für elf verschiedene Automodelle abgegeben werden müssen. Betrachtet man sehr "komplexe" Produkte wie Informationssysteme oder OR-Modelle, erscheint eine Befragung, die ja zumeist auch mit dem Ziel, Informationen für Weiterentwicklungen zu gewinnen, unternommen werden, sinnlos, wenn die Befragten die Objekte gar nicht kennen oder sich nur ein sehr oberflächliches Wissen, etwa aus Beschreibungen, erworben haben.

Dieses Problem wurde von einigen Autoren bei Untersuchungen der Akzeptanzbedingungen von OR-Modellen klar erkannt. So schreiben etwa Souder et al. [9]: "Accurate responses to such questionnaires may require the respondents to have certain level of knowledge about quantitative project selection model forms and their uses."

Bei Souder wurde versucht, das Problem dadurch zu lösen, daß man den Befragten in einigen Sitzungen ein Standardwissen über Projektselektions-Methoden und ihren Einsatz vermittelte. Außerdem konnten sie einige dieser Verfahren probeweise bei einigen Projekten einsetzen.

Eine derartige Vorgehensweise dürfte bei einem umfangreichen Toolpaket kaum zu befriedigenden Ergebnissen führen, insbesondere dann nicht, wenn explizit Fragen zur Benutzerfreundlichkeit gestellt werden.

Für ein umfangreiches Toolpaket stellt sich die Frage nach der umfassenden und detaillierten Produktkenntnis sowohl bei der Einsatzentscheidung als auch bei der Benutzung. Vor der Einsatzentscheidung können zeitliche und budgetäre Randbedingungen eine detaillierte Auswertung behindern, darüber hinaus verwenden viele Benutzer nur Teile eines umfangreichen Instrumentariums. Diese Vermutung wurde im Pretest des Fragebogens bestätigt.

Ein vielversprechender Ansatz für die Zukunft scheinen allerdings Experimente zu sein, wie sie zum Beispiel die Firma IBM [10] und auch Weiderman et al. durchgeführt haben. Bei IBM hat man ein aufwendiges Bewertungsverfahren entwickelt, das während eines kontrollierten Experiments eingesetzt wird. Repräsentanten verschiedener Benutzergruppen müssen ohne vorheriges Training mit den zu bewertenden konkurrierenden Softwarepaketen ein genau vorgegebenes Aufgabenpensum (Szenario) erledigen. Dabei werden sie von einem Bewertungsteam beobachtet, das eine Fülle von Eindrücken und Daten nach einem vorgegebenen Schema registriert. Aus den Beobachtungen könnten auch Produkteigenschaften für eine gesonderte Befragung abgeleitet werden [10].

Auch der Bau und Einsatz eines Prototypen kann während der Entwicklung eines Softwareprodukts frühzeitige Hinweise für die Akzeptanz des neuen Produkts bringen.

Wie schon erwähnt, wurden Beispiele für relevante Eigenschaften der Benutzeroberfläche zunächst aus der Literatur entnommen. Eine der wichtigsten Quellen war die GMD-Studie von Dzida et al. [11]. Die Beurteilung der Oberfläche wurde in sieben Eigenschaftskomplexe gegliedert:

- Fähigkeit, sich selbst zu erklären,

- Kontrolle durch den Benutzer,

- Leichtigkeit, die Handhabung des Systems zu lernen,

- Problemadäquate Benutzbarkeit,

- Übereinstimmung mit den Benutzererwartungen,

- Flexibilität in der Handhabung und

- Verhalten im Fehlerfall.

Diese Eigenschaftskomplexe wurden mit durchschnittlich zehn Produkteigenschaften zu erfassen versucht.

Wie schon mehrfach angedeutet, bezog sich unsere Untersuchung auf ein ganzes Toolpaket, das eine Fülle von Einzelfunktionen enthält. Die bisher diskutierte Frage der Benutzeroberfläche war nur ein Fragenkomplex der Studie. Untersuchungsgegenstand waren auch die Akzeptanzfaktoren "Merkmale des Anwenders" und "Organisatorisches Umfeld". Das bedeutet, daß zum Beispiel auch nach der Programmiererfahrung, nach der Größe und dem Organisationsgrad des Projekts, nach der Verbindlichkeit des Einsatzes bestimmter Werkzeuge und ähnlichem gefragt wurde. Zweck der Untersuchung wäre es nämlich auch herauszufinden, ob derartige Faktoren bei der Beurteilung einen signifikanten Einfluß haben.

Die folgende Gliederung soll einen ungefähren Eindruck von der Struktur des Fragebogens geben:

- Allgemeine Fragen zur Verwendung des Toolpakets,

- Verwendung von Einzelfunktionen,

- Beurteilung der Benutzeroberfläche,

- Bibliotheksverwaltung,

- Auswirkungen der Verwendung des Toolpakets im Urteil des Benutzers,

- Gesamtbewertung und Verbesserungsvorschläge sowie

- Fragen zur Person und zur Struktur des Projekts, in dem das Toolpaket verwendet wurde.

Bei der Befragung der Benutzer ergaben sich zwei Probleme: Es stellte sich heraus, daß das Toolpaket von verschiedenen Entwicklern sehr unterschiedlich genutzt wird. Keiner der Befragten nutzte alle angebotenen Einzelfunktionen, manche verwendeten überhaupt nur ein Tool, etwa den Editor. In jedem Fall war die Nutzungshäufigkeit der verschiedenen Werkzeuge ungleichmäßig.

Diese Besonderheiten führen in ihrer Konsequenz zu einer "natürlichen" Varianz der Untersuchungsergebnisse, die nur zum Teil durch einen umfangreicheren Fragebogen abzufangen ist. Das zweite Problem war der sehr umfangreiche Fragebogen selbst (zirka 34 Seiten mit einer Reihe von Tabellen zu jeder der 29 Einzelfunktionen). Die verschiedenen Pretests mit Entwicklern erbrachten keine Hinweise zur Kürzung, vielmehr erhöhte sich die Zahl der Fragen und der Umfang des Fragebogens noch. Generell bestand zwar der Wunsch nach einem kürzeren Fragebogen, gleichzeitig machten die Befragten in den Pretests aber zahlreiche Anregungen zur Präzisierung und Detaillierung bestimmter Teilbereiche. Ein Instrument zur Beantwortung von Akzeptanzfragen wurde damit selbst zum Akzeptanzhindernis: Ein Teil der befragten Entwickler weigerte sich, die Fragen zu beantworten, und zwar mit der Begründung, daß dies zu viel Zeit in Anspruch nehme.

Damit wird ein Problem sichtbar, das sich nicht nur bei Interviews, sondern auch beim Einsatz anderer Methoden auf dem Gebiet der Benutzerforschung etwa bei den schon erwähnten kontrollierten Experimenten, zeigt: Die Erforschung der Einstellung eines Benutzers zu komplexen Produkten, wie es Softwarewerkzeuge nun einmal sind, erfordert auch ein sehr komplexes Instrumentarium. Zum Beispiel enthält der vor einiger Zeit veröffentlichte Marktspiegel [12], in dem eine ganze Reihe von Softwarepaketen für das Projektmanagement beurteilt wird, etwa 600 Beurteilungskriterien. Diese Kriterien beziehen sich im wesentlichen nur auf die Funktionalität des jeweiligen Werkzeugs. Kriterien zur Beurteilung der Benutzerfreundlichkeit, deren Aufnahme den Katalog noch erheblich erweitern würde, sind noch kaum zu finden.

Möglicherweise erbringen statistische Tests bei größerem Stichprobenumfang Hinweise für eine gewisse Verringerung der Zahl der Items des von den Verfassern entwickelten Fragebogens. Eine wesentliche Verminderung ist aber kaum zu erwarten. Ganz im Gegenteil: Die Verfasser haben bislang darauf verzichtet, für die Einzelfunktionen, etwa den Editor oder ein Tool zur Erstellung von Struktogrammen ähnliche Item-Sammlungen zu erstellen, um den Fragebogen nicht zu überfrachten. Wie einige Beiträge aus der Literatur zeigen, etwa ein Kriterienkatalog zur Bewertung von Editoren [13], dürfte eine solche Erweiterung zu einer erheblichen Ausweitung der Item-Liste führen.

Analog zu den Eigenschaften der Strukturierung großer Systeme [14] scheint es unvermeidlich, mit zunehmender Größe eines Toolpakets vermehrt Kriterien zur Beurteilung der Eigenschaften des Gesamtpakets in die Befragung einzubringen, ergänzend zu Merkmalen einzelner Werkzeuge. Die Methode von Weiderman et al. hat gegenüber unserem Ansatz zweifellos den Vorteil, daß Benutzer, welche die untersuchten Tätigkeitssequenzen mit einem Toolpaket ausgeführt haben, im allgemeinen in der Lage sein werden, entsprechende Fragen zu beantworten. Allerdings müssen, wie schon ausgeführt, einige der veröffentlichten Fragen kritisch beurteilt werden.

Andererseits geben Fragen an die Benutzer eines Toolpakets, die auf der Grundlage der Adequacy-Importance-Modells entwickelt wurden, nach unserer Ansicht mehr Information, da sie nicht auf eine spezielle Aufgabe oder auf das Benutzermodell (Rollen, Aufgaben), welches der Definition der Experimente zugrunde liegt, eingeschränkt sind. Es liegt nahe, den Ansatz von Weideman et al. mit dem Adequacy-Importance-Ansatz und der Befragung einer größeren Stichprobe von Benutzern zu kombinieren, wobei das jeweilige Ziel (zum Beispiel Erhebung der Benutzerwünsche zur Weiterentwicklung eines Toolpakets oder vergleichende Bewertung mehrerer Entwicklungsumgebungen) die Art der Erhebung und Auswertung bestimmen wird.

Vorteil der besseren Vergleichbarkeit

Der hier beschriebene Ansatz der direkten Benutzerbefragung, der von der Einstellung der Befragten zu Produkteigenschaften ausgeht, ist komplementär zu kontrollierten Experimenten, die auch beim Vorgehen von Weideman et al. (eine Anzahl genau definierter Experimente, die verschiedene Projektphasen betreffen, werden von erfahrenen Benutzern ausgeführt) verwendet werden.

Zweifellos haben die auf Experimenten beruhende Evalualtionsmethoden den Vorteil der besseren Vergleichbarkeit. Benutzer, die die vorgegebenen Aufgaben in Tätigkeitsfolgen umgesetzt und ausgeführt haben, werden im allgemeinen in der Lage sein, alle Fragen zum Experiment zu beantworten.

*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.-lnf. 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.