Content

11 Entwicklung der Applikationen für kommunikativ-pragmatische Aphasietherapie (AKOPRA) in:

Cornelia Zeller

Softwarebasierte Aphasietherapie, page 133 - 143

Entwicklung und Erprobung des kommunikativ-pragmatischen Übungsprogramms AKOPRA

1. Edition 2018, ISBN print: 978-3-8288-4167-3, ISBN online: 978-3-8288-7034-5, https://doi.org/10.5771/9783828870345-133

Tectum, Baden-Baden
Bibliographic information
11 Entwicklung der Applikationen für kommunikativ pragmatische Aphasietherapie (AKOPRA) Die folgenden Abschnitte beziehen sich auf die Entwicklung des Therapiepro gramms AKOPRA. Zunächst werden die Zielvorgaben für die Konzeption (Kapi tel 11.1) und die Auswahl der Therapiem odule (Kapitel 11.2) thematisiert, be vor es um die Beschreibung der Softwareentwicklung (Kapitel 11.3), die Erstel lung des für die Applikationen benötigten Materials (Kapitel 11.4) und die D urchführung des Pretests (Kapitel 11.5) geht. 11.1 Zielsetzung Das Ziel bestand darin, in Anlehnung an das Kommunikativ-pragmatische Scree ning fü r Patienten m it Aphasie (KOPS) (G lindem ann & Ziegler, 2 011)26 ein softwarebasiertes Therapieprogramm zur D urchführung kom m unikativ pragmatischer Aphasietherapie zu erstellen. Die kommunikativ-pragmatische Ausrichtung des Programms war vorgege ben durch die Zielsetzung von K O PS , die komm unikativen Fähigkeiten bei Aphasie einzuschätzen. D enn das Screening umfasst viele differenzierte und am Alltag orientierte rezeptive sowie expressive Aufgabentypen, die sich auch für die Entwicklung eines korrespondierenden Therapiematerials eignen. Darüber hinaus bietet aufeinander abgestimmtes Diagnostik- und Therapiem a terial verschiedene Vorteile: So ist bei derartigem Material anhand des Tester gebnisses direkt ersichtlich, welche Aufgaben des Therapieprogramms sich für die sprachtherapeutische Intervention eignen. W eiterhin ergibt sich die M ög lichkeit zur Ü berprüfung, ob sich die trainierten kom m unikativen Fähigkeiten im Verlauf verändert haben. Auch über die Anlehnung an K O P S hinaus spricht vieles für eine kom m uni kativ-pragmatische Vorgehensweise: So wird von der IC F allgemein und dam it auch für die Behandlung von Aphasien gefordert, dass jede Intervention die Teilhabe an der Gesellschaft verbessern soll (vgl. Kapitel 7.1). Diese Vorgabe legt 26 Eine Beschreibung dieses D iagnostikum s findet sich in Kapitel 8.3.1. 133 den Einsatz kommunikativ-pragmatischer Ansätze nahe, da sich diese direkt auf das Kommunikationsverhalten beziehen (Schneider, 2014j). Dahingegen gestal tet sich der Transfer in die Alltagskommunikation bei Anwendung sprachsystematischer Ansätze häufig schwierig (Schneider, 2014k). Zudem ist davon auszugehen, dass aufgrund der ansteigenden Lebenserwar tung und der Senkung der M ortalitätsrate nach einem Schlaganfall in Zukunft m ehr M enschen von einer Aphasie betroffen sein werden (Schindelmeiser, 2008), wobei m it gleichbleibenden oder sogar geringer werdenden finanziellen M itteln zu rechnen ist (Bilda, 2017). Aufgrund der folglich erwartbaren Versor gungsschwierigkeiten besteht die Annahme, dass die Effektivität rehabilitativer M aßnahm en in Zukunft m it strengeren M aßstäben gemessen wird (Bilda, 2017; de Langen, 2003). U m eine kommunikativ-pragmatische Ausrichtung des Programms zu erreichen, sollten sowohl die Aufgabentypen, auf die in Kapitel 11.2 detaillierter eingegan gen wird, als auch die Items über eine hohe Alltagsrelevanz verfügen, da so im Vergleich zu abstrakten Inhalten größere Verbesserungen erzielt werden können (Grötzbach, 2015). Eine weitere Anforderung stellte die Integration verbaler und nonverbaler M odalitäten in das Programm dar. D am it soll die maximale kommunikative Handlungsfähigkeit unterstützt werden, bei der eine erfolgreiche Inhaltsverm itt lung im Fokus steht (Schütz, 2013). D enn durch die M odalitätenvielfalt können Betroffene zur Verwendung bisher wenig oder ungenutzter Kom m unikationska näle motiviert werden. W eiterhin zielt deren Einsatz darauf ab, blockierte verba le Fähigkeiten zu unterstützen, zu ergänzen oder zu kompensieren und so die Kom m unikation zu verbessern. D a sich die kommunikativ-pragmatische Aphasietherapie derzeit noch in der Entwicklung befindet (vgl. Kapitel 9.2.3), bestand eine weitere Herausforderung darin, für die einzelnen Aufgabentypen adäquate Hilfsstufen und Schwierig keitsparameter zu erarbeiten. Die zweite übergeordnete Zielvorgabe war es, das zu KO PS korrespondierende Therapiematerial als Softwareprogramm zu konzipieren. Das stellte eine beson dere Herausforderung dieser Arbeit dar: So ist zunächst hinsichtlich der Kombi nation von K om m unikation und Software zu bedenken, dass Kom m unikation gemäß ihrer Definition eine Beteiligung von mindestens zwei Personen erfordert (Ehrhardt & Heringer, 2011). Die Therapie m it einem Softwareprogramm sieht hingegen für den Nutzer keinen realen Konversationspartner vor. Folglich galt es, diesen in seinen verschiedenen Rollen durch das Programm so weit wie m ög lich zu ersetzen. 134 Doch die Im plem entierung in eine Software bringt neben dieser Herausfor derung eine Vielzahl an Vorteilen m it sich (vgl. Kapitel 10.3): Hiervon ist be sonders hervorzuheben, dass die Frequenz von Sprachtherapieeinheiten ohne großen personellen und finanziellen M ehraufwand erhöht werden kann. D enn wie bereits in Kapitel 7.2 im Rahm en der DGN -Leitlinien erwähnt, ist Sprachtherapie ab einer Intensität von fün f bis zehn Stunden pro W oche nach weisbar wirksam, was derzeit in Praxen und Kliniken oftmals nicht erreicht wer den kann (vgl. Kapitel 7.4). D arüber hinaus eignen sich Softwareprogramme besonders gut für hochrepetitive Trainingseinheiten, die sich ebenfalls positiv auf den Therapieerfolg auswirken können. Die häufige W iederholung von Items ist zwar auch in der Face-to-Face-Therapie möglich. D ennoch ist zu verm uten, dass repetierendes Lernen m it einem Softwareprogramm konsequenter umgesetzt wird, da Thera peuten eher zu m ehr Abwechslung neigen, um dem Betroffenen eine interessante und kurzweilige Sitzung zu bieten. D arüber hinaus kann durch die Kom bination von kom m unikativ pragmatischer und softwarebasierter Therapie die derzeitige Auswahl an Soft ware für die Aphasietherapie ergänzt werden. D enn wie in Kapitel 10.2 deutlich wurde, ist das aktuelle Angebot insgesamt begrenzt und es liegen kaum Pro gramme vor, die ein kommunikativ-pragmatisches Ü ben ermöglichen. 11.2 Zusam m enstellung derTherapiemodule Für die Zusamm enstellung der Therapiem odule von AKOPRA w urden die ein zelnen Untertests von KO PS zunächst dahingehend analysiert, welche kom m u nikativen Fähigkeiten jeweils überprüft werden, um so das diagnostische Ziel zu ermitteln. Anschließend galt es zu überlegen, wie diese kom m unikativen Fähigkeiten in einem softwarebasierten Therapieprogram m geübt werden können. V on beson derer Bedeutung hierfür war, welche Lösungsart die einzelnen Aufgabentypen evozieren: So lässt sich zwischen Aufgaben m it festgelegter, überwiegend festge legter, individuell festgelegter und teilweise festgelegter Antwort unterscheiden. Bei Aufgaben m it festgelegter Antwort gibt es nur eine zulässige Antwort, bei jenen m it überwiegend festgelegter A ntw ort wird in der Regel eine typische Antwort gegeben, wobei vereinzelt Abweichungen auftreten können. Bei Aufga ben m it individuell festgelegter bzw. wählbarer A ntw ort liegt zum Teil eine gro ße Menge potenzieller Antwortmöglichkeiten vor, die sich je nach Fragestellung und ohne Kenntnis der Anwender nicht im Voraus erm ittelt lässt. Bei Aufgaben m it teilweise festgelegter Antwort ist das Ziel vorgegeben, welches m it der kom munikativen H andlung erreicht werden soll, wobei die verbale oder nonverbale Umsetzung frei wählbar ist. Diese Antwortarten spielten für die Entwicklung des Therapieprogramms eine besondere Rolle, da das Programm so konstruiert werden sollte, dass für die 135 Lösungen spezifische Hilfsstufen zur Verfügung stehen und den N utzern eine Kontrolle ihrer produzierten Lösung ermöglicht wird. In den folgenden Abschnitten wird nun erläutert, über welche Antwortarten die einzelnen Untertests von KO PS verfügen: Ein festgelegtes Antwortform at findet sich sowohl in U ntertest 1 Rezeptive Aufgaben zum traditionellen PACE Setting als auch in U ntertest 3 Basale kommu nikative Handlungen: Zustimmung/Ablehnung und in U ntertest 8 Rekonstruktion von Wegbeschreibungen. So handelt es sich in U ntertest 1 nur bei einem der prä sentierten Zeichnungen um das Zielobjekt, nach welchem gefragt wird. Die Fra gen in U ntertest 3 weisen ein geschlossenes Antwortform at auf und werden m it einer der beiden Antwortpartikeln beantwortet. W eiterhin besteht die Aufgabe des Nutzers in U ntertest 8 darin, den beschriebenen W eg exakt nachzufahren, sodass auch hier nur eine richtige Lösung existiert. U ntertest 2 Expressive Aufgaben zum traditionellen PACE Setting verfügt als einziger Aufgabentyp über ein überwiegend festgelegtes Antwortformat, indem die N utzer dazu aufgefordert werden, auf verschiedene vorgegebene Objekte zu referieren. Es handelt sich hierbei deshalb um ein überwiegend festgelegtes A nt wortformat, da es beispielsweise auch zur N ennung von Synonymen oder H y ponym en kom m en kann. Aufgabentypen m it individuell festgelegten/wählbaren Antworten liegen bei U ntertest 4 Vermitteln personenbezogener Angaben und bei U ntertest 5 Vermitteln von Inhalten aus allgemeinen Bereichen vor. Die Besonderheit dieser Aufgabenty pen besteht darin, dass die Antworten von den unterschiedlichen Anwendern abhängig sind. D ennoch können sich einzelne Antworten bei N utzern auch überschneiden. W erden die Items dieser Aufgabentypen häufiger bearbeitet, be steht außerdem die Möglichkeit, dass die Anwender unterschiedliche Antworten geben. Die Untertests 6 Komplexe kommunikative Handlungen: Einzelhandlungen, 7 Komplexe kommunikative Handlungen: Rollenspiele und 9 Wegbeschreibungen ex pressiv können der Aufgabengruppe m it teilweise festgelegter A ntw ort zugeord net werden. D enn sowohl bei den Einzelhandlungen als auch bei den Rollen spielen ist die auszuführende komm unikative H andlung vorgegeben und bei der zu produzierenden Wegbeschreibung sind nicht nur Start und Ziel angegeben, sondern der gesamte Weg. D urch diese Vorgaben sind die Antworten teilweise festgelegt, wobei die verbale bzw. nonverbale Gestaltung variabel ist. Anhand dieser Erm ittlung der Antwortarten der einzelnen Untertests ist zu er kennen, dass sich der Aufgabentyp von U ntertest 4 Vermitteln personenbezogener Angaben und derjenige von U ntertest 5 Vermitteln von Inhalten aus allgemeinen Bereichen nicht für die Gestaltung einer Therapiesoftware eignen, da sich auf grund der hohen Individualität der Antworten weder allgemeingültige Hilfen 136 noch eine generalisierte Lösungskontrolle entwickeln lassen. Bei allen anderen Aufgabentypen ist hingegen in Bezug auf die Anforderung an die Antwortarten eine Im plem entierung in eine Software grundsätzlich möglich. Im Rahmen dieser Arbeit wurde schließlich Therapiesoftware für die Aufgaben typen Rezeptive Aufgaben zum traditionellen PACE Setting (Untertest 1), Ex pressive Aufgaben zum traditionellen PACE Setting (Untertest 2), Basale kom munikative H andlungen: Zustim m ung/A blehnung (Untertest 3) und Komplexe komm unikative Handlungen: Einzelhandlungen (Untertest 6) entwickelt. D enn zum einen ist es durch diese Zusamm enstellung gelungen, Software sowohl für die rezeptive als auch für die produktive Sprachverarbeitung zu erstellen. Zum anderen können von dieser Kom bination N utzer m it unterschiedlich ausgepräg ten Störungsbildern und Schweregraden profitieren. Darüber hinaus wurden ein Therapiekonzept sowie das Audio- und Bildma terial für den Aufgabentyp des KOPS U ntertest 8 Rekonstruktion von Wegbe schreibungen entwickelt. Die Im plem entierung konnte jedoch für diesen Proto typen nicht fertiggestellt werden, da für die Programmierung ein zu hoher Mehraufwand nötig gewesen wäre, der im Rahm en dieser Arbeit nicht umsetz bar war. 11.3 Methodische Softwareentwicklung und Programmierung Im Folgenden soll die Entwicklung der Software beschrieben werden. Das Ziel dieser Entwicklung war die Herstellung einer Software, welche über die zum Er reichen der (Therapie-)Ziele wesentlichen Merkmale verfügt (Herzwurm, Schockert & Mellis, 1997). Die technische Umsetzung erfolgte in Zusamm enarbeit m it einem U nternehm en für Softwareentwicklung. Die an der Entwicklung beteiligten Personen stam m ten aus unterschiedli chen fachlichen Disziplinen, sodass die Schaffung eines gemeinsamen Begriffs verständnisses von besonderer Bedeutung war. Das förderte einerseits das Ver ständnis der Softwareentwickler für die Ansprüche, die von der A utorin dieser Arbeit an die Software gestellt wurden. Andererseits ermöglichte dies eine Erwei terung der technischen Gestaltungsoptionen (Herzwurm et al., 1997). Eine Möglichkeit, ein solches allgemeines Verständnis zu erreichen, ist das Formulieren sogenannter Anforderungen an ein Produkt. Eine Anforderung be schreibt, was von einem Produkt erwartet wird (Ebert, 2014). Diese Anforde rungen sind kurze und prägnante Aussagen über Vorteile, die durch die N u t zung des Produkts erzielt werden können (Herzwurm et al., 1997). Die Anfor derungen beantworten also die Frage, Was entwickelt werden soll (Ebert, 2014) Davon abzugrenzen ist die tatsächliche technische Lösung, also die Antwort, Wie etwas entwickelt werden soll (Herzwurm et al., 1997). 137 N ach der Festlegung der Aufgabentypen, für die Therapiesoftware entwi ckelt werden sollte (vgl. Kapitel 11.2), w urden gemeinsam m it den beteiligten Softwareentwicklern Anforderungen an die Software form uliert und diesen bestmöglich entsprechende Lösungen gegenübergestellt. Aufgrund der begrenzten zeitlichen Ressourcen wurde die Entwicklung be reits vor der endgültigen Definition der Anforderungen an die Software begon nen. Ein solches Vorgehen ist insbesondere in der Softwareentwicklung häufig zu beobachten und führte u. a. zur Etablierung des Konzepts der Agilen Soft wareentwicklung (Highsm ith & Cockburn, 2001). Z u dessen Prinzipien gehören beispielsweise die Akzeptanz von Anforderungsänderungen auch in späten Stadi en der Entwicklung, das regelmäßige Ausliefern funktionsfähiger Prototypen so wie eine enge Zusamm enarbeit zwischen den Softwareentwicklern und der Fachabteilung (in diesem Falle der Autorin) (Fowler & Highsm ith, 2001). Diese Vorgehensweise sollte außerdem dazu beitragen, dass die formulierten Anforderungen an die Software von den Entwicklern korrekt umgesetzt werden konnten. Das war besonders relevant, da die Entwickler über keine therapeuti schen Fachkenntnisse verfügten. Insbesondere das regelmäßige Ausliefern funk tionsfähiger Prototypen an die A utorin half bei Evaluation der Ergebnisse und der Konkretisierung vorhandener bzw. der Form ulierung weiterer A nforderun gen. Tabelle 20 bis Tabelle 22 zeigen eine Gegenüberstellung der formulierten An forderungen (in den Zeilen) und Lösungen (in den Spalten). In der durch diese Dim ensionen aufgespannten M atrix sind Zusamm enhänge zwischen einzelnen Anforderungen und Lösungen jeweils m it einem „X“ markiert. Diese Zusam menhänge bezeichnen den Unterstützungsgrad der jeweiligen Anforderung durch die betrachtete Lösung (Cohen, 1995; Herzwurm et al., 1997). 138 139 O rts unabhängige Therapie erm ög lichen A nsprechende G estaltung er reichen P lattform unab hängigkeit ge w ährleisten Z uverlässige B edienung ge w ährleisten S elbständige Item bearbeitung erm öglichen E infache und sichere B edie nung erm ögli chen Leichte V e rfü g barkeit gew ähr leisten H ochfrequente Therapie erm ög lichen A nforderungen Lösungen X X X Gerät mit Touchscreen X X X Große Buttons X X X reduzierte Benutzeroberfläche X X X Hohe Ähnlichkeit der einzelnen Module X X Automatische oder selbständige Lösungskontrolle X X X X Native Applikation (ohne Internetverbindung lauffähig) X Verwendung von Programmiersprache Java Kompatibilität mit KOPS Integration verschiedener Medien X X X Rückmeldungen durch das Programm X X Gestaltung von aufgabentypspezifischen Schwierigkeitsstufen Übernahme der Aufgabentypen von KOPS Trainieren mit alltagsnahen Items X X Anbieten verschiedener Modalitäten X X Integration von kleinschrittigen Hilfsstufen Anbieten vereinfachter/verkürzter Lösungen X X X X Android-Softwareplattform X Entwicklung mit Android Studio Tabelle 20: Anforderungs-Lösungs-M atrix. Zusammenhänge zwischen einzelnen Anforderungen und Lösungen sind jeweils mit einem „X“ markiert. 140 Effektivitäts kontrolle erm ög lichen G eringe fin an zi elle B elastung bei E rstellung der S oftw are G eringe fin an zi elle B elastung für den N utzer K leinschrittiges Üben erm ögli chen Trainieren einer m axim alen K om m unika tionsfähigkeit M ultim odale A ktivierung er m öglichen Trainieren von alltäglichen kom m unikativ en F ähigkeiten Therapie ab w echslungs reich gestalten | A nforderungen Lösungen Gerät mit Touchscreen Große Buttons Reduzierte Benutzeroberfläche Hohe Ähnlichkeit der einzelnen Module Automatische oder selbständige Lösungskontrolle X Native Applikation (ohne Internetverbindung lauffähig) Verwendung von Programmiersprache Java X X Kompatibilität mit KOPS X Integration verschiedener Medien X Rückmeldungen durch das Programm X X Gestaltung von aufgabentypspezifischen Schwierigkeitsstufen X X Übernahme der Aufgabentypen von KOPS X Trainieren mit alltagsnahen Items X X X X Anbieten verschiedener Modalitäten X X Integration von kleinschrittigen Hilfsstufen X X Anbieten vereinfachter/verkürzter Lösungen X X Android-Softwareplattform X Entwicklung mit Android Studio Tabelle 21: Anforderungs-Lösungs-M atrix (Fortsetzung 1). Zusammenhänge zwischen einzelnen Anforderungen und Lösungen sind mit einem „X“ markiert. T abelle 22: A nforderungs-L ösungs-M atrix (Fortsetzung 2). Z usam m enhänge zwischen einzelnen A nforderungen u n d Lösungen s in d m it e inem „X“ m arkiert. Lö su ng en G er ät m it T ou ch sc re en G ro ße B ut to ns R ed uz ie rte B en ut ze ro be rf lä ch e Ho he Ä hn lic hk ei t de r ei nz el ne n M od ul e A ut om at is ch e od er se lb st än di ge Lö su ng sk on tr ol le N at ive A pp lik at io n (o hn e In te rn et ve rb in du ng la uf fä hi g) V er w en du ng vo n P ro gr am m ie rs pr ac he Ja va K om pa tib ili tä t m it K O P S In te gr at io n ve rs ch ie de ne r M ed ie n R üc km el du ng en du rc h da s P ro gr am m G es ta ltu ng vo n au fg ab en ty ps pe zi fis ch en S ch w ie rig ke its st uf en Ü be rn ah m e de rA uf ga be nt yp en vo n K O P S Tr ai ni er en m it al lta gs na he n Ite m s A nb ie te n ve rs ch ie de ne r M od al itä te n In te gr at io n vo n kl ei ns ch rit tig en H ilf ss tu fe n A nb ie te n ve re in fa ch te r/ ve rk ür zt er Lö su ng en A nd ro id -S of tw ar ep la ttf or m E nt w ic kl un g m it A nd ro id S tu di o Anforderungen Therapie planung erleich tern X X W iedergabe heterogener Daten erm ög lichen X W iedergabe großer Daten mengen erm ög lichen X In Bezug auf die Lösungskontrolle ist zu beachten, dass die Implem entierung einer vollumfänglichen automatischen Lösungskontrolle aus verschiedenen G ründen nicht möglich war. Zwar sind Spracherkennungssysteme wie Siri (Apple, 2017) mittlerweile weit verbreitet, eignen sich allerdings nur einge schränkt für den therapeutischen Einsatz. G ründe hierfür sind insbesondere die N otwendigkeit einer ständigen Internetverbindung und allgemeine Probleme bei der Erkennung nicht-schriftgetreuer Sprache. Ähnliche Herausforderungen stel len sich bei der Erkennung von H andschrift ein. Vorgelagerte Tests ergaben, dass die für die App-Entwicklung geeignete H andschrifterkennung nur bei sehr sorgfältigem Schreiben zuverlässig funktioniert. Bei der Texterkennung erwies sich die Umsetzung einer adäquaten Fehlertoleranz als Schwierigkeit. Bild- und 141 Gestenerkennung erfordern wiederum m ehr Rechenleistung als das verwendete Tablet aufbringen kann. N ach der dargestellten Z uordnung der form ulierten Anforderungen zu den entsprechenden Lösungen soll exemplarisch ein solcher Zusam m enhang erläutert werden: So stellte es eine Anforderung dar, m it der Software hochfrequente T he rapien zu ermöglichen. Dieser Anforderung wurde m it den Lösungen automati sche oder selbständige Lösungskontrolle, Rückmeldung durch das Programm, Gestal tung von aufgabentypspezifischen Schwierigkeitsstufen, Anbieten verschiedener M o dalitäten und Integration kleinschrittiger Hilfsstufen begegnet. So spielt es für eine hohe Therapiefrequenz eine wichtige Rolle, auch außer halb der Face-to-Face-Therapie m it der Software üben zu können. D a dann kei ne Kontrolle durch einen Therapeuten möglich ist, ist es wichtig, entweder eine Rückmeldung über das Programm zu bieten, oder dem Nutzer eine selbständige Lösungskontrolle bereitzustellen. W eiterhin ist auch die Rückmeldung durch das Programm von zentraler Be deutung. Diese impliziert beispielsweise, dass visuell angezeigt wird, wann But tons angetippt werden können, und erleichtert so die Arbeit m it dem Pro gramm. Die Gestaltung von aufgabentypspezifischen Schwierigkeitsstufen ist eben falls relevant, da diese den Anwender längerfristig fördern können. Auch durch das Anbieten verschiedener M odalitäten kann eine hochfre quente Therapie unterstützt werden, da hierdurch ein abwechslungsreiches Üben möglich wird. Außerdem können im V erlauf der Therapie verschiedene Schwer punkte gewählt werden. Eine weitere Lösung stellt die Integration kleinschrittiger Hilfsstufen dar. Diese sollen es dem Anwender ermöglichen, die Items selbständig bearbeiten und die Hilfen langfristig reduzieren zu können. Die technische Umsetzung erfolgte m it der Programmiersprache Java innerhalb der Entwicklungsumgebung Android Studio. Diese integrierte Entwicklungsum gebung (IDE) enthält Programmierschnittstellen zu den Hardwarefunktionen des verwendeten Android-Tablets (z. B. Ansteuerung der Buttons zur Lautstär keregelung, Abrufen von Audio-, Bild- und Videodateien). W eiterhin beinhaltet die Um gebung einen M odus zum Testen der Applikationen auf dem zur Ent wicklung genutzten C om puter und eine Anzeige für gefundene Fehler im Pro grammcode (Google, 2017). M ithilfe dieser ID E entwickelte A ndroid Applikationen sind prinzipiell auf jedem Gerät m it dem Betriebssystem Android lauffähig. Die Verwendung der weit verbreiteten Programmiersprache Java ließe m it einigen Anpassungen auch eine N utzung auf anderen Softwareplattformen wie Microsoft Windows zu. Dies wird durch ein breites Angebot an sogenannten 142 Laufzeitumgebungen für Java ermöglicht (Oracle, 2017) und bringt den Vorteil der Lauffähigkeit auf den meisten genutzten Endgeräten m it sich. 11.4 Erstellung des Materials Ein weiterer Aufgabenbereich bestand in der Entwicklung des für AKOPRA be nötigten Materials. H ierfür wurde zunächst der Gesam tbedarf ermittelt, bevor es darum ging, Anforderungen an die Gestaltung des Materials zu erarbeiten und es schließlich gemäß dieser Kriterien zu produzieren. Das Material besteht aus Tonaufnahm en für die Instruktionen, die Aufgabenstellungen, die Hilfen und die Lösungspräsentationen. Außerdem waren pro Item ein oder mehrere Fotos erforderlich sowie in Abhängigkeit des M odalitäten- und Hilfsangebots korres pondierende Zeichnungen und Gestenvideos. D er Umfang des entwickelten Materials umfasst insgesamt 2000 Audioaufnahm en, 350 Fotos von Objekten, Personen und Situationen, 210 Objektzeich nungen und 28 Gestenvideos. Die Audioaufnahmen wurden m it einer semiprofessionellen Sprecherin und einem semiprofessionellen Sprecher aufgenommen. Das Ziel hierbei war es, AKOPRA auch auditiv abwechslungsreich zu gestalten und beispielsweise In struktionen deutlich von Aufgabenstellungen abzugrenzen. Z ur Reduktion von Störgeräuschen fanden die Aufnahm en in der H örkam m er des Klinikums M ün chen Bogenhausen statt. Anschließend wurde das aufgenommene Material m it der Phonetiksoftware P R A A T bearbeitet und geschnitten. Bei der Erstellung der Fotos wurde darauf geachtet, dass es sich bei den ab gebildeten O bjekten und Situationen um möglichst prototypische Darstellungen handelt, um die Erkennbarkeit zu unterstützen. Es wurde unterschieden, ob es sich um eine Objektabbildung vor neutralem H intergrund isoliert oder m it einer Person, um eine Objektabbildung in einem objekttypischen Kontext oder um die Darstellung einer Situation handelt, bei welcher eine oder mehrere Personen eine spezifische H andlung meist in einem typischen Kontext ausführen. Welche Arten dieser Fotos jeweils in die einzelnen M odule integriert wurden, wird im Rahm en der Beschreibungen der einzelnen Therapiem odule in Kapitel 12 erläu tert. Die Zeichnungen wurden gemeinsam m it einem professionellen Zeichner und einer Laienzeichnerin erstellt. Dabei standen eine möglichst gute Erkenn barkeit der gezeichneten Objekte und Sachverhalte sowie eine möglichst einfache zeichnerische Umsetzung im Vordergrund. D enn zum einen ist es wichtig, dass die N utzer von AKOPRA erkennen, auf welches O bjekt bzw. auf welchen Sach verhalt die Zeichnungen referieren. Z um anderen dienen begonnene Zeichnun gen als Hilfe, indem diese präsentiert und vom N utzer kom plettiert werden sol len. D a viele Laienzeichner nur über ein eingeschränktes Zeichenrepertoire ver fügen (vgl. Kapitel 6.2.1) und zusätzlich davon auszugehen ist, dass einige An wender aufgrund einer Hemiparese der dom inanten H and diese nur einge 143

Chapter Preview

References

Zusammenfassung

Software für Kommunikativ-pragmatische Aphasietherapie – passt das wirklich zusammen? Dieser Frage geht Cornelia Zeller im vorliegenden Buch nach. In diesem Buch erhalten Sie zunächst fundiertes Wissen über das Krankheitsbild und die Behandlung von Aphasien. Anschließend geht Cornelia Zeller auf die theoriebasierte Entwicklung der Applikationen für kommunikativ-pragmatische Aphasietherapie (AKOPRA) ein, die an das Kommunikativ-pragmatische Screening für Patienten mit Aphasie (KOPS) angelehnt sind. Daraufhin wird die Therapiestudie dargestellt, in der das Übungsprogramm auf seine Praktikabilität hin überprüft wurde. In diesen Kapiteln werden u.a. die Ergebnisse zur Anwendbarkeit von AKOPRA sowie zur Effektivität geschildert. Von diesem Buch können in Praxis oder Klinik tätige Sprachtherapeutinnen und Sprachtherapeuten profitieren, da neben der theoretischen Fundierung viele praktische Hinweise zur Anwendung von AKOPRA gegeben werden. Darüber hinaus können Wissenschaftlerinnen und Wissenschaftler sowie Studierende Anknüpfungspunkte für weitere Forschungsarbeiten finden.