Qualitätssicherung bei Computer-Maschinen

In 2.1.2 wurden Visionen der Computernutzung vorgestellt, wie sie von Charles Babbage, Helmut Hollerith, Konrad Zuse, Alan Turing und John von Neumann geäußert wurden. Die Ähnlichkeiten dieser Nutzungsvisionen wurden aufgezeigt und alle diese Ideen sowie einige ihrer Realisierungen (vom Difference Engine über den Colossus zum ENIAC) der übergeord-neten Maschinen-Metapher der Computernutzung zugeordnet. Es gilt nun zu zeigen, welchen Einfluss die Idee der Maschinennutzung des Computers auf den Prozess hatte, in dem die je-weiligen Artefakte entwickelt wurden und in dem die Maschinen-Vision der Computernut-zung sich realisierte:

Man konzentrierte sich vor allem auf die Überprüfung der Machbarkeit (Feasability) und Ef-fektivität der Artefakte am Ende des Entwicklungsprozesses. Von Babbage bis hin zu von Neumann starteten alle vorgestellten Entwickler mit einem klar definierten, zumeist ihrem eigenen wissenschaftlichen Arbeitsprozess entsprungenen Problem, wie etwa der Fehlerhaf-tigkeit von Rechentabellen (Babbage), der wachsenden statistischen Datenflut (Hollerith) oder der nicht ausreichenden Geschwindigkeit menschlicher Rechenfertigkeit zur Ermittlung der Flugbahn von Projektilen (von Neumann). Diese Probleme betrafen stets nur eine sehr kleine, elitäre Gruppe, zumeist von mathematisch-technisch ausgerichteten Wissenschaftlern.

Es stand nicht im Mittelpunkt, wie die Lösung dieser Probleme mit einem Artefakt durch ir-gendeinen beliebigen oder außenstehenden Nutzer in einem speziellen, situativen und

sozia-len Kontext erfolgen könnte, sondern es sollte zunächst der Nachweis geführt werden, dass die jeweiligen Probleme überhaupt durch den Einsatz von Technik gelöst werden können.

Allein weil die Prototypen von Babbages Analytical Engine bereits Schwächen in Bezug auf ihre Funktionalität hatten, nicht zuverlässig arbeiteten und somit ihre Effektivität¹²⁶ nicht ge-währleistet war, wurde die Förderung von Babbages Projekten durch die britische Regierung bald eingestellt und Babbages Vision niemals vollständig verwirklicht. Konrad Zuses Z1 wur-de als Rechenmaschine noch belächelt, weil er ebenfalls nicht zuverlässig funktionierte. Die aus Blech gefertigten Schaltglieder des Z1 verhakten sich regelmäßig. Auch für die Bewer-tung des Colossus war allein die Frage entscheidend, ob der Code deutscher Funkmeldungen entschlüsselt werden konnte.

Ein weiteres wichtiges Kriterium neben Machbarkeit (Feasability) und Effektivität war für die genannten Artefakte die Nützlichkeit (Utility). Nachdem mit verschiedenen großen Re-chenanlagen vom Harvard MARK I über den ENIAC bis hin zum UNIVAC der Nachweis er-bracht war, dass mathematische Rechnungen von technischen Artefakten gelöst werden kön-nen, rückte die Frage nach der Nützlichkeit dieser Artefakte in den Mittelpunkt. Bei der Frage nach der Nützlichkeit musste der Nachweis erbracht werden, dass die eingesetzte Maschine eine bestimmte Aufgabe schneller und zuverlässiger als der Mensch ausführen kann und sich ihre Anschaffung und die Ablösung des Menschen durch diese lohnt.

Diesen Nachweis führte Helmut Hollerith sehr nachdrücklich. Die Datenmengen des 1890er Zensus, dessen Erfassung, Aufbereitung und Auswertung durch Menschenhand schätzungs-weise nicht vor Erhebung des 1900er Zensus abgeschlossen gewesen wäre, wurde durch den Einsatz der Lochkartenmaschine innerhalb von sechs Wochen realisiert. Doch musste Holle-rith den Auftraggebern des US-Zensus-Büros die Effektivität und größere Nützlichkeit seines Artefakts gegenüber anderen Artefakten bereits vor Beginn des 1890er Zensus in einem soge-nannten Acceptance Test nachweisen. Im Herbst 1889 fanden er und zwei Kontrahenten, die ebenfalls an jeweils einer Maschine zur Automatisierung der Datenauswertung gearbeitet hat-ten, sich in der Behörde ein, um an einer Stichprobe aus dem 1880er Zensus, den 10.491 Fra-gebögen aus der Stadt St. Louis, die größere Effektivität und Nützlichkeit ihrer Artefakte im Vergleich zu denen ihrer Konkurrenten zu demonstrieren. Es wurden sowohl Fragebögen ein-gelesen (im Falle Holleriths also durch das Stanzen der Lochkarten) als auch einfache Daten-auswertungen durchgeführt (Kreuztabellierungen) und die Verarbeitungszeit gestoppt. Beim

126 Wie in 1.4.3 ausgeführt, ist Zuverlässigkeit eines der Subkonzepte der in ISO/IEC 9126-1 definierten techni-schen Qualität Effektivität.

Einlesen war Holleriths Lochkartensystem den Artefakten seiner Kontrahenten nur geringfü-gig überlegen, die Datenauswertung hingegen erledigte es mehr als zehnmal so schnell (Cambell-Kelly & Aspray 1996: 23). Abgesehen von den dadurch eingesparten Kosten durch die Erhöhung der Bearbeitungsgeschwindigkeit erhöhte Holleriths Erfindung gleichzeitig die Menge der zu verarbeitenden Daten und die Güte der Auswertung (Cambell-Kelly & Aspray 1996: 26).

Hollerith erhielt daraufhin den Auftrag, für den 1890er Zensus ausreichend Maschinen bereit zu stellen. Da, wie in 2.1.2.2 erwähnt, Uneinigkeit über die durch den Einsatz der Lochkar-tenmaschine erzielten Einsparungen besteht, kann die Nützlichkeit des Artefakts nachträglich nicht quantifiziert werden. Allein die durch diese erzielte Zeiteinsparung von mehreren Jahren deutet jedoch auf eine extrem hohe Nützlichkeit der Lochkartenmaschine für den Zweck der Zensus-Auswertung hin.

Auch der ENIAC konnte die Flugbahn von Geschossen nachweislich schneller berechnen als ein menschlicher Computer. Berechnungen, für die mehrere emeritierte Professoren und ande-re Angestellte Stunden gebraucht hatten, konnten mit Hilfe des ENIAC in wenigen Sekunden ermittelt werden. Auf diese Weise konnte die Anzahl der für die Berechnung der Firing Tables benötigten Mitarbeiter minimiert werden. Jedoch bestand die Nützlichkeit des ENIAC nicht in erster Linie in der Einsparung von Personal, sondern in der Einsparung von Zeit. Als erste Rechenmaschine konnte der ENIAC die Flugbahn von Projektilen in einer Zeit berech-nen, die die Zeit vom Abschuss des Projektils bis zu dessen Einschlag im Ziel unterschritt, wodurch erstmals die Möglichkeit bestand, den Einschlag eines Projektils theoretisch vorher-zubestimmen, bevor er praktisch eintrat. Die Betonung sowohl der Einsparung von menschli-chen Computern als auch von Remenschli-chenzeit weisen darauf hin, dass die Frage nach der Nütz-lichkeit des ENIAC bei dessen Beurteilung eine zentrale Qualität darstellte. Dennoch kann auch die Nützlichkeit des ENIAC nicht quantifiziert werden, weil weder die erzielten Einspa-rungen noch die diesen gegenüberstehenden Kosten klar beziffert werden können. Der ENIAC wurde außerdem in einer Zeit entwickelt, in der jede Forschung, die auch nur einen entfernten militärischen Nutzen versprach, großzügige Unterstützung genoss. Dabei wurden selbst sol-che Projekte als nützlich für die USA betrachtet, bei denen mehr Kosten aufgewendet als ein-gespart wurden, solange sie als erfolgsversprechend für den Einsatz im Krieg angesehen wur-den. Die Qualität der Nützlichkeit derartiger Projekte mit nationaler Bedeutung für die USA allein in Zeit oder Geld auszudrücken, greift folglich zu kurz. Es muss hier stattdessen immer die militärische Nützlichkeit, also eine Art idealistischer Faktor oder irrationaler Kosten im Sinn von Prestige mitberücksichtigt werden, wenn man die Nützlichkeit eines Artefakts wie

des ENIAC bestimmen wollte. Die in die Bestimmung der Nützlichkeit eingehende Größe der rationalen Kosten des Artefakts müsste demnach um die nicht bezifferbare Größe der irratio-nalen Kosten ergänzt werden.

Auch der Nachfolger des ENIAC, der von Remington Rand produzierte UNIVAC¹²⁷, der vom US-Zensus-Büro eingesetzt werden sollte, musste sich am 31. März 1951 zahlreichen soge-nannten Acceptance Tests unterziehen, in denen seine Effektivität und Nützlichkeit überprüft wurden. Bei diesen Tests rechnete der UNIVAC 17 Stunden ununterbrochen, ohne einen Feh-ler zu produzieren, womit der Nachweis seiner Effektivität und Nützlichkeit als erbracht galt, da er nicht nur korrekt, sondern auch schneller und vor allem zuverlässiger als der Mensch rechnen konnte (Cambell-Kelly & Aspray 1996: 121).

Diese Konzentration auf die Machbarkeit (Feasability), Effektivität und Nützlichkeit (Utility) eines technischen Artefakts ist ein zentrales Merkmal der Entwicklung von Computer-Maschinen. Das wichtigste Merkmal der Qualitätssicherung bei Computer-Maschinen ist je-doch die Abstinenz anderer Qualitätsvorstellungen, die erst mit der Werkzeugidee der Com-puternutzung historisch an Bedeutung gewannen, wie etwa jener der Benutzbarkeit und Gebrauchstauglichkeit (Usability).

Da die von Babbage über Zuse bis zu von Neumann zu lösenden Probleme stets ingenieurwis-senschaftlichen bzw. mathematischen Ursprungs waren, konnte vorausgesetzt werden, dass die späteren Benutzer aus dem ingenieurwissenschaftlichen und mathematischen Bereich die Funktionsweise des technischen Artefakts prinzipiell verstehen oder bereits kennen würden.

Die Zielgruppe, für die ein solches Artefakt produziert wurde, war so klein und homogen, dass eine detaillierte Analyse, wer ein Artefakt in welcher Situation zu welchem Zweck benö-tigte und wie er mit der Steuerung desselben zurechtkam, schlicht überflüssig war. Entwickler wie Babbage, Hollerith, Zuse oder von Neumann, Mauchly und Eckert entwickelten haupt-sächlich für sich selbst und ihresgleichen. Die Identität von Entwicklern und Bedienern eines Artefakts wurde in 2.1.1 als zentrale Eigenschaft von Computer-Maschinen definiert.

Das bedeutet, dass diejenigen, die ein Artefakt nutzen wollten, und jene, die es entwickelten, entweder dieselben Personen waren oder zumindest aus denselben Bereichen kamen, dieselbe Vorbildung besaßen und ähnliche Aufgaben zu erledigen hatten. Die Auswirkung dieser

127 Durch eine Art öffentlichen Acceptance Test errang der UNIVAC auch unter Computerlaien große Popularität, als einige Wissenschaftler der Universität Pennsylvania auf Basis seiner an den Wahlergebnissen von 1944 und 1948 orientierten Berechnungen im Jahr 1952 in einer Fernsehsendung des CBS das Wahlergebnis der anstehen-den Präsianstehen-dentschaftswahlen zwischen Stevenson und Eisenhower sehr exakt voraussagen konnten (Campbell-Kelly & Aspray 1996: 122).

sache auf den Entwicklungsprozess der Artefakte darf nicht unterschätzt werden. So war schließlich garantiert, dass das mit dem Artefakt zu lösende Problem (z.B. die Ermittlung von Gezeitentabellen oder Firing Tables) vom Entwickler von vornherein vollständig verstanden wurde. Es musste keinerlei Energie aufgebracht werden, um zu ermitteln, was der Nutzer auf welche Art und Weise erledigen wollte. Stattdessen konnte man sich sofort der Realisierung verschiedener technischer Lösungsansätze widmen und diese gegeneinander testen, um schließlich die beste auszuwählen. Die zu entwickelnde Maschine war die Repräsentation der Denk- und Arbeitsweise der Entwickler, die gewissermaßen als zukünftige Nutzer vollständig in den Entwicklungsprozess integriert waren. Diese Art des Entwickelns wurde in 1.4.3 als experimentelles Prototyping beschrieben, das allein der Ermittlung der besten Lösung für gut bekannte Probleme diente.

Da die Entwickler ihren eigenen Arbeitsprozess sehr genau kannten, mussten sie diesen nicht detailliert analysieren, um zu verstehen, wo er durch den Einsatz von Technik unterstützt werden könnte. Die Art, wie sie sich die Bedienung der von ihnen entwickelten Artefakte dachten, setzte voraus, dass ein Bediener ihnen selbst ähnlich war, dass er ein gewisses Ver-ständnis für die technische Funktionsweise des Artefakts aufbrachte oder zumindest die Be-reitschaft besaß, sich dieses anzueignen. Die Idee, der Mensch bediene das Artefakt, führte zu der Auffassung, der Mensch müsse sich dem Artefakt anpassen und nicht das Artefakt müsse an den Menschen angepasst werden. Wurster brachte diese Feststellung mit seiner Beobach-tung an den großen Wissenschafts- und Militärrechner der 1940er und 1950er Jahre vom Z3 über den Harvard Mark I, den ENIAC und EDSAC hin zum Whirlwind auf den Punkt:

„Die einzige Benutzergruppe, die Zugang zu einem Computer hat, sind hochspe-zialisierte Mathematiker und Wissenschaftler, die die Rechenprogramme entwer-fen und stecken, die Daten vorbereiten, den Prozess des Rechnens überwachen und die Ergebnisse auswerten. [...] Stecken, Stanzen und Schalten sind die hand-werklichen Interaktionsstile dieser hardwarezentrierten Mensch-Computer-Schnittstelle, bei der sich der Mensch weitestgehend nach der Arbeitsweise seiner Maschine richten muss.“ (Wurster 2002: 25)

Solange die Machbarkeit (Feasability), Effektivität und Nützlichkeit die zentralen Qualitäten darstellten, nach denen ein Artefakt beurteilt wurde, konnte die Entwicklung einer techni-schen Lösung linear, ausschließlich auf dem Papier und von Anfang bis Ende in der Werkstatt des Entwicklers allein durch den Entwickler stattfinden. Wenn es gelang, das zu lösende Problem (z.B. die Berechnung einer Firing Table) im Turing’schen Sinn zu formalisieren und

genau zu spezifizieren, welche Operation welche Daten voraussetzte, konnte das Artefakt nach dem Verfahren entwickelt werden, das später, bezogen auf Software, als das „Wasser-fallmodell“ bekannt wurde (Preim 1999: 221)¹²⁸. Entscheidend dabei war, dass allein das Ar-tefakt die Beobachtungseinheit der Qualitätstests darstellte. Eine Einbeziehung von menschli-chen Testnutzern und eine Untersuchung des Umgangs dieser Nutzer mit dem Artefakt war solange nicht notwendig, wie Entwickler für ihresgleichen produzierten und somit ihre eige-nen Testnutzer waren.

Auch wenn auf den ersten Blick die Vorstellung des Computers als Maschine und der hieraus resultierende lineare Entwicklungsprozess als historisch überlebt anmutet, so muss konstatiert werden, dass vielerorts immer noch Computer verwendet und benötigt werden, die wie Ma-schinen genutzt werden sollen und dementsprechend wie MaMa-schinen entwickelt werden kön-nen. Es ist häufig sinnvoll, die Nutzung eines zu entwickelnden Computers als Maschine im oben definierten Sinn zu denken und entsprechend zu produzieren, also linear, ohne Einbezie-hung von Testnutzern, ohne Berücksichtigung solcher Qualitäten wie Benutzbarkeit oder Gebrauchstauglichkeit. Beispiele für derartige Artefakte sind etwa solche Hochleistungsrech-ner wie die Connections Machine, die Cray-Computer oder der schachspielende Big Blue, mit denen in erster Linie die Machbarkeit des technisch Möglichen ausgereizt werden soll. Ein Werkzeugverständnis der Computernutzung wäre hier in vielen Fällen hinderlich oder öko-nomisch unvernünftig, wie etwa bei Großrechnern, die für die Durchführung sehr spezieller Aufgaben oder die Steuerung sehr spezieller Maschinen oder Abläufe eingesetzt und nur von einigen wenigen Technikern bedient werden, jene Artefakte etwa, die mit dem Ziel der Me-chanisierung der Fabrik bis hin zum Ideal der „menschenleeren Fabrik“ oder positiv formu-liert: „der bedienerarmen Fabrik“ (Coy 1985: 106) entwickelt wurden. Solche Artefakte sind in keiner Weise zur Unterstützung des individuellen Nutzers bei der Erledigung einer breiten Palette alltäglicher Aufgaben gedacht. Sie sollen den Nutzer nicht in seinen Fähigkeiten er-weitern, sondern ersetzen und werden dementsprechend nicht von einer Vielzahl heterogener Nutzer, sondern einer elitären, homogenen Gemeinschaft von Spezialisten bedient. Von die-sen Spezialisten kann verlangt werden, dass sie die Funktionsweise ihrer Maschine im Detail kennen oder erlernen, ihre eigene Arbeitsweise optimal an jene der Maschine anpassen oder gar selbst die Entwickler der entsprechenden Maschine sind. Jeder externe Versuch, eine sol-che Identität zwissol-chen Entwickler und Benutzer des Computers zu trennen, muss vom Nutzer

128 Bei diesem endet die Erstellung jeder Komponente der Maschine mit dem Test ihrer Effektivität. Nach einem positiven Test kann mit der Entwicklung der nächsten Komponente begonnen werden bis die Maschine oder das Programm wie gewünscht funktioniert und das interessierende Problem lösen kann.

als Arbeitsbehinderung angesehen werden. Ökonomisch unvernünftig ist ein solcher Versuch, Maschinennutzung eines Computers in Werkzeugnutzung zu transformieren, überall dort, wo der von allen potentiellen Nutzern aufzubringende Aufwand, die Funktionsweise einer Com-puter-Maschine zu erlernen, geringer ist als der Aufwand, eine angemessene Benutzungs-schnittstelle zu entwickeln.