Entwicklung eines Expertensystems zur Zuordnung von Assistierenden Technologien für körperbehinderte Jugendliche im Virtual Office des FAB

Magisterarbeit von Siegfried Kreutzer

Einleitung:

Bei der 4. Tagung des Österreichischen Arbeitskreises für Transpersonale Psychologie und Psychotherapie (ÖATP) ‘Von Herz zu Herz’, hielt Leo Prothmann einen Vortrag mit dem Thema ‘Leben heißt sich mitteilen’. Dieser Titel sei Inspiration, um darüber nachzudenken, dass es ein wichtiges Bedürfnis des Menschen ist, sich mitzuteilen. Körperbehinderten Menschen ist dies durch ihre oftmals multiplen Einschränkungen nicht möglich. Einerseits sind sie vielfach in ihrer Mobilität beschränkt und können in den seltensten Fällen selbständig weite Distanzen mittels Auto oder Zug zurücklegen, um Freunde zu treffen oder neue Kulturen kennen zu lernen. Andererseits sind nicht selten nur mangelhafte Ausdrucksmöglichkeiten durch sprachliche Behinderung oder Einschränkung der Gestik gegeben.

Moderne Kommunikationsmittel wie Computer und Internet sind daher häufig die einzige Möglichkeit für diese Menschen, sich aktiv ihrer Umwelt mitzuteilen. Spezielle Hilfsmittel, sogenannte ‘Assistierende Technologien’ (AT), helfen diesen Menschen bei der Bedienung des Computers. Das Virtual Office des Vereins zur Förderung von Arbeit und Beschäftigung (FAB) ist eine Einrichtung für körperbehinderte Jugendliche, welche den Schwerpunkt auf Computerarbeit legt und in Kapitel 1.1 vorgestellt wird.

Das Virtual Office des FAB:

Im Virtual Office des FAB werden Jugendliche mit mehrfachen Beeinträchtigungen im Umgang mit dem Computer geschult. Mit dem Einsatz individuell angepasster Hilfsmittel erhalten die Jugendlichen im IT-Bereich eine weitere schulische Förderung und eine berufliche Qualifizierung. Das Ziel der dreijährigen Ausbildung ist es, die Jugendlichen auf den ersten Arbeitsmarkt vorzubereiten und nach Möglichkeit auch eine geeignete Arbeitsstelle zu finden. Den Jugendlichen eröffnen sich neue Möglichkeiten, ihre Gedanken und Ideen zu konkretisieren, umzusetzen und mit anderen zu kommunizieren. Mit dem Computer können Potentiale geweckt und gefördert werden, weshalb Computer und Assistierende Technologien zentrale Werkzeuge darstellen. Im Virtual Office stehen 24 Ausbildungsplätze sowie drei weitere Plätze für Jugendliche aus anderen Bundesländern zur Verfügung. Derzeit betreuen zehn hauptberufliche Mitarbeiter, sowie ca. acht nebenberufliche Trainer die Jugendlichen. Das Ausbildungsspektrum umfasst:

fachliche Schwerpunkte wie:

Textverarbeitung, Präsentationen, Tabellenkalkulation, Bild-, Audio- und Videobearbeitung, Internet, Erstellen von Websites, Digitalisierung von Dokumenten, Bürotätigkeiten.

Allgemeinbildende Schwerpunkte wie:

Alltagsmathematik, Deutsch und Schriftverkehr, Kulturtechniken.

Individuelle Förderungen im Bereich:

Selbstkompetenz, Soziale Kompetenz, Teamfähigkeit, Kognitiver Leistung.

Die Finanzierung wird durch die Sozialabteilung des Landes Oberösterreich sichergestellt.

Relevanz der Thematik:

Die Anpassung und Auswahl von Assistierenden Technologien an Menschen mit körperlichen Einschränkungen ist ein langwieriger Prozess. Eine Vielzahl von Gerätschaften muss am Klienten ‘erprobt’ werden. Dieser iterative Prozess aus Versuch und Irrtum kann sich über Monate des Beobachtens hinziehen und benötigt viel Erfahrung. Es wäre daher im Interesse aller Betroffenen diesen Prozess zu beschleunigen und damit nicht nur Geld und Zeit zu sparen, sondern vor allem die Nerven der beteiligten Personen zu schonen. Die Notwendigkeit eines solchen Systems wäre nicht nur für das Virtual Office gegeben, sondern auch für alle Organisationen die sich mit dem Problemfeld körperbehinderter Menschen und IT beschäftigen. Die Recherchen des Autors ergaben, dass eine geeignete Möglichkeit, diesen Prozess automationsunterstützt zu beschleunigen, derzeit nicht existiert.

Problemstellung:

Die Ende 2008 erstellte Diplomarbeit von Arkadiusz Marcin Frydyada de Piotrowski mit dem Titel ‘Heuristik zur Anpassung der Ein- und Ausgabeschnittstellen für Menschen mit Einschränkungen’ stellt den theoretischen Hintergrund für die aktuelle Arbeit dar. Frydyada de Piotrowski beschreibt in seiner Arbeit, wie die Fähigkeiten und Unfähigkeiten betroffener Personen die Mensch-Computer-Interaktion beeinflussen. Die Einschränkungen der Betroffenen reichen ‘[…] von Behinderungen der Sinnesorgane oder der Motorik über kognitive und psychologische Einschränkungen bis hin zu Sprachbehinderungen’. Einschränkungen weisen unterschiedliche Ausprägungen und Schweregrade auf und die Auswahl einer guten Kombination an Assistierenden Technologien ist oft ein langwieriger Prozess des Beobachtens und Probierens. Frydyada de Piotrowski beschreibt nicht nur die einzelnen Ausprägungen von Behinderungen und die Mindestanforderungen von Assistierenden Technologien, sondern auch Heuristiken zur Verwendung dieser Technologien für körperbehinderte Menschen mit bestimmten Fähigkeiten, basierend auf systematischen Beobachtungen, Forschungsergebnissen und Befragungen von Experten. Er hat zudem einen Entscheidungsprozess entwickelt, welcher zu einem auf den Benutzer zugeschnittenen Vorschlag von Assistierenden Technologien führt. Mit diesem Entscheidungsprozess soll es gelingen, die oft langwierigen Anpassungen, welche Erfahrung und Expertise voraussetzt, zu verkürzen und eine systematische Vorgehensweise zu etablieren. Profile, Mindestanforderungen, Regeln und Heuristiken wurden von Frydyada de Piotrowski theoretisch beschrieben, jedoch keine Informationstechnologische Umsetzung durchgeführt.

Textprobe:

Kapitel 5., Test und Validierung:

Dieses Kapitel beschreibt den Test des Prototyps. Tan benennt drei Phasen des Tests seines Expertensystems, ‘Preliminary Testing’, ‘Informal Validation Testing’ und ‘Field Testing’. In der ‘Preliminary’-Phase wird die gesamte Wissensbasis getestet und beinhaltet das Prüfen von Ergebnissen aufgrund unterschiedlicher Beantwortung der Fragen. Die zweite ‘Informal Validating’-Phase dient dazu, das System gegen echte Probleme aus der Domäne zu testen. Dabei werden die Parameter alter Fälle in das Expertensystem eingespeist und das Ergebnis des Expertensystems mit den tatsächlichen Lösungen verglichen. In der letzten ‘Field Test’-Phase wird das System in die Echtumgebung eingebunden und versucht, neue Fälle damit zu lösen.

Baumeister beschreibt ‘Validation’ als einen Test, der überprüft, ”if [sic] the right system is built’. Eine sehr häufig benutzte Teilaufgabe dieser Validierung ist die ‘empirical Validation’, welche mittels Testfällen die Qualität der Implementierung testet. Dabei wird überprüft, ob das Eingabe-Ausgabeverhalten des Systems mit den Erwartungen des Benutzers übereinstimmt. Baumeister führt weiter die ‘Verification’ an, welche überprüft, ”if [sic] the system was built right’. Dabei wird das System auf bekannte Schwachstellen und mangelhaftes oder falsches Wissen hin überprüft. Eine typische Teilaufgabe wäre die ‘static verification’, welche auf logische Anomalien wie Redundanzen und Inkonsistenzen testet.

Angelehnt an die drei Testphasen die Tan, und die zwei Testkonzepte, die Baumeister beschrieben haben, wird ein ähnliches Testmodell angewendet. Zunächst soll die Funktionalität des Prototyps getestet werden. Dies beinhaltet vor allem die Validierung der Regeln, ob diese ‘feuern’ und ob das System die Ergebnisse aufgrund der Antworten wie gewünscht liefert. Dieser Test dient vor allem dazu, Programmierfehler sowie syntaktische Fehler zu finden und zu prüfen, ob der Prototyp funktional wie gewünscht läuft. Dies entspräche der ‘Verification’ wie von Baumeister beschrieben. Anschließend soll ein retrospektiver Test im Virtual Office anhand alter Fälle erfolgen. Damit soll die Praxistauglichkeit der von Frydyada de Piotrowski beschrieben Heuristiken geprüft werden. Dies würde der von Baumeister beschriebenen ‘Validation’ entsprechen. Zum Abschluss soll die Zeit gemessen werden, die ein Mitarbeiter des Virtual Office benötigt, um den Fragebogen auszufüllen. Dieser Test soll einerseits qualitativ feststellen, ob sich der Mitarbeiter nach einer kurzen Einschulung mit dem User-Interface (UI) zurechtfindet und andererseits, welches Zeitersparnispotential ESAT besitzt.

Eine Erprobung an neuen Fällen kann im Rahmen dieser Arbeit nicht durchgeführt werden, da neue Klienten meist nur einmal im Jahr aufgenommen werden und die Feststellung, ob die vorgeschlagenen Hilfsmittel wirklich die Richtigen sind, oft erst nach einer monatelangen Beobachtung möglich ist.

5.1, Test auf Funktionalität:

Es gibt mehrere Methoden, welche jeweils unterschiedliche Bereiche eines Expertensystems testen. Baumeister et al. klassifizieren diese Tests in Methoden zur Überprüfung der korrekten Ausführung von Funktionen, Feststellen von Anomalien, Überprüfen der Robustheit und Verifizieren der Verständlichkeit. All diese Methoden sind in Summe ein sehr großer Themenkomplex und es ließe sich alleine mit dem ausführlichen Testen eines Expertensystems eine umfangreiche Arbeit schreiben. In der aktuellen Arbeit soll es genügen, die Funktionalität zu überprüfen und exemplarisch vorzustellen. Baumeister et al. nennen die Überprüfung mit Testfällen ‘empirical testing’, welche zu den populärsten Methoden gehört, um die korrekte Ausführung der Funktionen zu testen. Dazu ist es notwendig, dass der Domänenexperte zuvor bereits die erwarteten Ergebnisse kennt, um entsprechende Testfälle zur automatisierten Ausführung zu implementieren. Die Ergebnisse der durchgeführten Tests werden mit den zuvor definierten erwarteten Ergebnissen verglichen. Eine Abweichung kann ebenso visuell signalisiert werden wie das korrekte Abarbeiten der Testfälle ohne Abweichung.

‘Continuous Integration’ (CI) als eine Sammlung von Praktiken und Tools, welche den Entwicklungsprozess unterstützen, wurde am Lehrstuhl für Informatik VI der Universität Würzburg für KnowWE adaptiert. Dabei wurde ein CI-Tool entwickelt, welches die Idee des CI von allgemeinem Softwareengineering auf Knowledge-Engineering übernimmt. Die Idee des Terms ‘Continuous Integration’ wird von Fowler wie folgt zusammengefasst:

‘Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly”.

Welche Relevanz hat CI nun für die aktuelle Arbeit? Der Testautomatismus, den das CI-Tool für KnowWE bietet, ist nicht nur für einen einmaligen Test gedacht, sondern für eine kontinuierliche (continuous) Überprüfung der bestehenden Wissensbasis. Damit soll die Stabilität des Expertensystems respektive der Wissensbasis bei späterer Weiterentwicklung des Prototyps gewährleistet werden.

Das ‘CI-Dashboard’ bietet dem Knowledge-Engineer einen Überblick über den aktuellen Zustand der Wissensbasis. Dieses Dashboard kombiniert alle Aspekte von CI in einem einzelnen User-Interface, wie z.B. einem Report über die automatisierten Tests, die Generierung neuer Builds oder Zugriff auf vorhergehende funktionierende Builds.

Das CI-Dashboard des Prototyps zeigt in Sektion A den Zustand des letzten Builds, markiert durch eine Anzeige in Form eines Bullet. Wenn Fehler auftraten, so ist der Bullet rot, keine Fehler werden durch einen grünen Bullet signalisiert. Die ‘Wetteranzeige’ daneben zeigt den Trend von erfolgreichen und fehlgeschlagenen Builds an. Sonne bedeutet, dass alle letzten Builds erfolgreich waren, Gewitter bedeutet, die letzten Builds schlugen alle fehl. Die Anzahl der Builds und ob sie erfolgreich oder nicht erfolgreich waren, lässt sich in Sektion B ablesen. Hier ist es auch möglich, zwischen den Builds hin- und herzuwechseln und in der Detailsektion C die Gründe für einen Fehlschlag nachzuprüfen.